Изпечатай

[abadon]

Здравейте,

Не знам как точно да си формулирам въпроса и може би затова и не мога да намеря адекватна информация в google. Ето какво искам да направя пускам примерно ping от лаптопа си, който е закачен за рутера ми вкъщи, към google и получавам следния отговор:

ping google.com
PING google.com (209.85.148.103) 56(84) bytes of data.
64 bytes from fra07s07-in-f103.1e100.net (209.85.148.103): icmp_seq=1 ttl=56 time=45.5 ms
64 bytes from fra07s07-in-f103.1e100.net (209.85.148.103): icmp_seq=2 ttl=56 time=45.1 ms
64 bytes from fra07s07-in-f103.1e100.net (209.85.148.103): icmp_seq=3 ttl=56 time=46.2 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 45.169/45.630/46.212/0.434 ms

Въпроса ми е мога ли по някакъв начин да направя специална конфигурация на рутера си когато пусна ping от лаптопа да получавам вместо time=45.5 ms да кажем time=25.5 ms.

Един вид да лъжа колко е реалното забавяне на мрежата от дадено ip към дадено ip.

Това може ли да се направи по някакъв начин?

Предварително благодаря очаквам вашите съвети и идеи.

[laskov]

Във файла /etc/hosts добавяш един ред

192.168.1.1        google.com

където 192.168.1.1 е IP-то на рутера ти и ще получиш умопомрачителен резултат.

[abadon]

Това е хитро, обаче не ми върши работа. Може би аз не обясних нещата правилно с дадения пример. ping-а ще го пускам срещу друго ip не срещу dns име, затова този вариант не ме устройва

[laskov]

Сваляш си кода на ping, променяш и компилираш.

[b2l]

Що за глупости се пишат в тази тема? @abadon ще кажеш ли защо ти е да лъжеш отностно time-а? Всъщност този time е времето за което пакета достига и се връща обратно при хоста, който го е изпратил. Ping-ни си рутера и ще видиш <1ms.

Код:

ping -s 0 google.com

[laskov]

Що за глупости се пишат в тази тема? ...

Ние си се разбрахме

[laskov]

Още един вариант:
1. преименуваш ping на piping напр.
2. пишеш скрипт и го кръщаваш ping
Скрипта стартира piping и след като обработи изхода му (дели времето на 2), го печата.
Айде стига сме писали ...

[abadon]

Що за глупости се пишат в тази тема? @abadon ще кажеш ли защо ти е да лъжеш отностно time-а? Всъщност този time е времето за което пакета достига и се връща обратно при хоста, който го е изпратил. Ping-ни си рутера и ще видиш <1ms.

Код:

ping -s 0 google.com

Предлагам една услуга в интернет обаче сред клиентите ми се шири мнението, че виждаш ли колкото по-малък е response time на ping-а от сървъра който предлагам аз към още няколко други сървъра, които ги ползват за тест толкова по-добре. Защото виждаш ли ако е над 30ms значи интернета е бавен, което е пълна глупост. Просто няма как да забързам светлината, но върви го обясни на някой индиец или мазайзиец.

И изпадам в такава примерна ситуация предлагам 1Gbps свързаност България -> Италия обаче понеже response time-а на ping-а е 37ms. Клиентите викат а не тази услуга не е добра.

Ще ида да си взема 10Mbps от Германския ти колега, защото като пусна ping неговия time е 20ms. Той ми предлага двойно по-бърз нет от теб.

Затова ми трябва някак си да слъжа за този time и да го редуцирам с 5-10ms.

[abadon]

Още един вариант:
1. преименуваш ping на piping напр.
2. пишеш скрипт и го кръщаваш ping
Скрипта стартира piping и след като обработи изхода му (дели времето на 2), го печата.
Айде стига сме писали ...

  печелиш точка. Това е много добро решение.

[laskov]

Предлагам една услуга в интернет ...

Това, което си намислил на мен не ми допада, но бизнесът си е твой. Аз съм закостенял мозък и като разбера, че се опитват да ме излъжат, даже и да е против интересите ми, гледам да съм далеч.
А инъче, за твоите цели, скриптът може изобщо да не стартира piping, а просто да си пише някакви неща по екрана. Така ще демонстрираш свързаност, даже и когато нямаш такава!

За твоите цели, вероятно е по-добре да сравняваш възможности напр. с демонстрация на файлов трансфер ... или видео връзка ...

[abadon]

С файловия трансфер нямам проблем тъй като когато ти давам 1Gbps свързаност и ти отвориш достатъчен брой tcp връзки дали реално пакетите ще минават за 35ms пък аз с моя fake ping ще ти ги представям за 25ms. Едва ли ще ти е от значение не си ли съгласен? Така и така не можеш да си запълниш капацитета с една връзка.

Проблема е че тук сме хора, които разбираме или поне се опитваме да разбираме нещата и на теб или някой друг колега от форума му е ясно, че няколко ms отгоре или от долу не са най-важното нещо особено когато сървъра е на 2000-3000 км. Всички ние знаем че тези ms не са мерило за това колко ти е бърза връзката.

Но ми идва клиента индиец от щата раджастан пуска един ping вижда че при мен върви на 35ms. Пуска един ping при конкуренцията от където върви на 30ms. След което ми казва хайде отивам при конкуренцията ти защото там е по-добре, без да отчита че моите сървъри с в data center, че ползват HA SAN-ове за сторидж и т.н А конкуренцията е сложила едно жълто РС без никакво подсигуряване, но е на 200-300км по-близо то тестовия сървър и затова ping-а му е по-бързо.

От чисто техническа точка знаем че не е редно, но от маркетингова много би ми помогнало за бизнеса.

Това си мисля сега няма ли начин да се смени timestamp-a на icmp echo request-а с "правилен" от където и нормалния ping да се лъже, за да няма такива скриптове.

[gat3way]

ICMP пакета няма timestamp.

[laskov]

Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]
            [-p pattern] [-s packetsize] [-t ttl] [-I interface or address]
            [-M mtu discovery hint] [-S sndbuf]
            [ -T timestamp option ] [ -Q tos ] [hop1 ...] destination

Виж какво правят -Т и -Q , като уточнявам, че аз НЕ знам и не знам дали могат да са ти от полза.

[b2l]

Що за щуротии бе хора  ? Този time няма как да го промениш, освен ако не форматираш изхода от програмата както каза laskov. И то пак не го променяш ами само променяш това което вижда потребителя.

[amarth]

@abadon
Не съм съгласен с "Всички ние знаем че тези ms не са мерило за това колко ти е бърза връзката."

И тези ms са мерило. Тук  http://delian.blogspot.com/2008/03/network-performance-tuning-windows.html човека го е обяснил.

"TCP протоколът е този, който се използва в над 90% от вашата комуникация по Интернет или в локалната мрежа. Той цели да осигури сигурен пренос на данните – тоест данните се изпращат и се потвърждават че са получени правилно (пресмята се контролната им сума и се сравнява с тази записана във всеки пакет). Ако не са получени правилно не се потвърждават. Изпращащата страна изчаква малко време и изпраща непотвърдените участъци пак. За да не се налага да се потвърждава всеки пакет, преди да бъде изпратен следващия (понеже това ще ограничи максималната скорост на сесия в посока до големината на пакета за RTT време (RTT е времето необходимо за отиване и връщане на пакет), понеже всеки пакет с данни трябва да бъде потвърден преди да се изпрати следващия) потвържденията се правят на сегменти, които се наричат Windows (няма общо с Microsoft). Всяка страна казва на отсрещната непрестанно какъв е нейния моментен прозорец, от максимум байтове, които могат да бъдат изпратени към нея без потвърждение. Смисъла на това е, че така приемащата страна може да има нещо като Flow Control механизъм – ако има малък по размер буфер, ще е сигурна, че изпращача няма да изпрати повече данни от размера на този буфер (ако ние сме му казали максимален Receive Window <= на размера на буфера). Ако пък приложението четящо данните се бави, намаляваме Receive Window-а, и така намаляваме количеството данни, които да се трупат в буфера, до на практика пълното им спиране. Като прост ефект от това следва и формулата за максимална скорост на предаване на данни чрез TCP протокол в посока – тя е един Receive Window за RTT време. Или ако RTT е в милисекунди, то скоростта е (Receive Window * 1000)/RTT байтове в секунда.

И сега да се върнем към Windows – при него по подразбиране Receive Window е 8KB/17KB (при Linux е 32KB или 64KB в зависимост от Kernel-а). Следователно ако между двете комуникиращи си машини ping-а дава средно закъснение от 100мс, максималната скорост на трансфер към Windows ще бъде 8KB*1000/100 за секунда, или 80KB/сек. За пример Linux ще постигне при същите параметри 320KB/сек, само поради разликата в конфигурацията..."

http://en.wikipedia.org/wiki/TCP_tuning