Linux за българи: Форуми

Linux секция за напреднали => Хардуерни и софтуерни проблеми => Темата е започната от: abadon в Oct 31, 2011, 21:57


Титла: "Редуциране" на ping response time-а - търся съвет
Публикувано от: abadon в Oct 31, 2011, 21:57
Здравейте,

Не знам как точно да си формулирам въпроса и може би затова и не мога да намеря адекватна информация в 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.

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

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

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: laskov в Oct 31, 2011, 22:42
Във файла /etc/hosts добавяш един ред
Цитат
192.168.1.1        google.com
където 192.168.1.1 е IP-то на рутера ти и ще получиш умопомрачителен резултат.

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: abadon в Oct 31, 2011, 22:47
Това е хитро, обаче не ми върши работа. Може би аз не обясних нещата правилно с дадения пример. ping-а ще го пускам срещу друго ip не срещу dns име, затова този вариант не ме устройва

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: laskov в Oct 31, 2011, 23:04
Сваляш си кода на ping, променяш и компилираш.

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: b2l в Oct 31, 2011, 23:12
Що за глупости се пишат в тази тема? @abadon ще кажеш ли защо ти е да лъжеш отностно time-а? Всъщност този time е времето за което пакета достига и се връща обратно при хоста, който го е изпратил. Ping-ни си рутера и ще видиш <1ms.

Код:
ping -s 0 google.com

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: laskov в Oct 31, 2011, 23:30
Цитат на: b2l в Oct 31, 2011, 23:12
Що за глупости се пишат в тази тема? ...
Ние си се разбрахме :)

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: laskov в Nov 01, 2011, 00:05
Още един вариант:
1. преименуваш ping на piping напр.
2. пишеш скрипт и го кръщаваш ping
Скрипта стартира piping и след като обработи изхода му (дели времето на 2), го печата.
Айде стига сме писали ... :)

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: abadon в Nov 01, 2011, 00:11
Цитат на: b2l в Oct 31, 2011, 23:12
Що за глупости се пишат в тази тема? @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.

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: abadon в Nov 01, 2011, 00:12
Цитат на: laskov в Nov 01, 2011, 00:05
Още един вариант:
1. преименуваш ping на piping напр.
2. пишеш скрипт и го кръщаваш ping
Скрипта стартира piping и след като обработи изхода му (дели времето на 2), го печата.
Айде стига сме писали ... :)

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

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: laskov в Nov 01, 2011, 10:12
Цитат на: abadon в Nov 01, 2011, 00:11
Предлагам една услуга в интернет ...
Това, което си намислил на мен не ми допада, но бизнесът си е твой. Аз съм закостенял мозък и като разбера, че се опитват да ме излъжат, даже и да е против интересите ми, гледам да съм далеч.
А инъче, за твоите цели, скриптът може изобщо да не стартира piping, а просто да си пише някакви неща по екрана. Така ще демонстрираш свързаност, даже и когато нямаш такава! :)

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

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: abadon в Nov 01, 2011, 10:33
С файловия трансфер нямам проблем тъй като когато ти давам 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 да се лъже, за да няма такива скриптове.

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: gat3way в Nov 01, 2011, 11:58
ICMP пакета няма timestamp.

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: laskov в Nov 01, 2011, 12:03
Цитат
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 , като уточнявам, че аз НЕ знам и не знам дали могат да са ти от полза.

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: b2l в Nov 01, 2011, 12:18
Що за щуротии бе хора  ??? ? Този time няма как да го промениш, освен ако не форматираш изхода от програмата както каза laskov. И то пак не го променяш ами само променяш това което вижда потребителя.

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: amarth в Nov 01, 2011, 17:12
@abadon
Не съм съгласен с "Всички ние знаем че тези ms не са мерило за това колко ти е бърза връзката."

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

"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 ($2)

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: gat3way в Nov 01, 2011, 17:21
Сега като се замисля има начин, ще си поиграя вкъщи и ще пиша. В крайна сметка, повечето ping имплементации слагат timestamp в payload-а на пакета явно...ще видя може ли да се направи нещо по въпроса...

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: laskov в Nov 01, 2011, 17:46
Аз имах предвид повишаване на приоритета, ако такова нещо е възможно.

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: b2l в Nov 01, 2011, 17:57
Цитат на: laskov в Nov 01, 2011, 17:46
Аз имах предвид повишаване на приоритета, ако такова нещо е възможно.

Приоритет на какво?

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: gat3way в Nov 01, 2011, 18:05
Timestamp наистина има в ICMP ECHО пакетите, но не в хедъра, повечето ping имплементации го слагат в payload-а на пакета, който по спецификация трябва да се върне в същия вид. Това явно е вид оптимизация - за да не им се налага да пазят информация кой пакет кога е изпратен (при ping -f това би било доста брутално).

Също така може да се върне ICMP ECHO REPLY пакет с модифициран timestamp, не с подръчните средства, но може да се напише програмка, която го прави. Има обаче много въпросителни. Вкъщи имам разни заигравки с raw сокети от едно време, ще модифицирам една от тях за целта и ще пробвам. Склонен съм да вярвам, че няма начин да се направи reliable, но ще е интересна занимавка. След час-два ще пиша пак.

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: gat3way в Nov 01, 2011, 18:56
Тъй, готово. Експериментът....донякъде успешен, за справка:

Код:
ping www.gat3way.eu

Естествено не прави точно това което се иска, а е просто PoC експеримент. Ако на някой му се играе:

Код:
#include <fcntl.h>
#include <errno.h>
#include <sys/socket.h>
#include <resolv.h>
#include <netdb.h>
#include <string.h>
#include <netinet/in.h>
#include <netinet/ip_icmp.h>


#define PACKETSIZE 64
struct packet
{
        struct iphdr iphdr;
        struct icmphdr hdr;
        char msg[PACKETSIZE-sizeof(struct icmphdr)];
};

struct protoent *proto=NULL;

unsigned short checksum(void *b, int len)
{       unsigned short *buf = b;
        unsigned int sum=0;
        unsigned short result;

        for (sum = 0;len>1;len-=2) sum += *buf++;
        if (len == 1) sum += *(unsigned char*)buf;
        sum = (sum >> 16) + (sum & 0xFFFF);
        sum += (sum >> 16);
        result = ~sum;
        return result;
}


unsigned short reverse2 (unsigned short nValue)
{
   return (((nValue>> 8)) | (nValue << 8));
}


void fuckicmp(struct sockaddr_in *addr)
{       const int val=255;
        int i, sd, cnt=1;
        short cs;
        struct packet pckt;
        struct sockaddr_in r_addr;
        char icmppacket[64];
        int sum;

        sd = socket(PF_INET, SOCK_RAW, IPPROTO_ICMP);
        if (sd < 0)
        {
                perror("socket");
                return;
        }
        if (setsockopt(sd, SOL_IP, IP_TTL, &val, sizeof(val)) != 0)
                perror("Set TTL option");
        if(setsockopt(sd, IPPROTO_IP, IP_HDRINCL, &val, sizeof(val)) < 0)
             perror("setsockopt() for IP_HDRINCL error");

        for (;;)
        {
                int len=sizeof(r_addr);
                if ( recvfrom(sd, &pckt, sizeof(pckt), sizeof(pckt), (struct sockaddr*)&r_addr, &len) > 0 )
                if (pckt.hdr.type==ICMP_ECHO)
                {
                    printf("Got icmp type=%d id=%d seq=%d\n",pckt.hdr.type,reverse2(pckt.hdr.un.echo.id),reverse2(pckt.hdr.un.echo.sequence));

                    pckt.hdr.type = ICMP_ECHOREPLY;
                    pckt.hdr.checksum = 0;
                    int src,dst;
                    src=pckt.iphdr.saddr;
                    dst=pckt.iphdr.daddr;
                    pckt.iphdr.daddr=src;
                    pckt.iphdr.saddr=dst;

                    //Uncomment to lie about pings, decrease response time by ~650ms
                    pckt.msg[6]+=10;

                    //Uncomment to make fun of users
                    //pckt.msg[3]+=20;

                    memcpy(icmppacket,&pckt.hdr,sizeof(struct icmphdr));
                    memcpy(&icmppacket[sizeof(struct icmphdr)],&pckt.msg,64-sizeof(struct icmphdr));
                    pckt.hdr.checksum=checksum(icmppacket,64);

                    if ( sendto(sd, &pckt, sizeof(pckt), 0, (struct sockaddr*)&r_addr, sizeof(r_addr)) <= 0 )
                        perror("sendto");
                }
        }
}

int main(int count, char *strings[])
{       struct hostent *hname;
        struct sockaddr_in addr;
        char *str="127.0.0.1";

        proto = getprotobyname("ICMP");
        hname = gethostbyname(str);
        bzero(&addr, sizeof(addr));
        addr.sin_family = hname->h_addrtype;
        addr.sin_port = 0;
        addr.sin_addr.s_addr = *(long*)hname->h_addr;
        addr.sin_addr.s_addr = INADDR_ANY;
        fuckicmp(&addr);

        return 0;
}


За да  тествате, първо забранявате echo response-ите от ядрото:

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

После компилирате и пускате горната програма като root.


Сега къде са проблемите и защо мисля, че подходът няма да доведе до решение на проблема:

1) Работи само при packet size=64, дефолтната в линукс. При други вероятно ще се счупи. Това лесно се оправя.
2) Правено е на базата на сорса на ping в линукс, където timespec структурата е първото нещо в payload-a и знаем точно къде да бутнем, за да променим резултата. Структурата между другото е архитектурно-зависима, така че ping от powerpc система примерно ще трябва да се handle-ва по друг начин. По-лошото е че windows ползва друг формат, не знам как и къде се пази timestamp-а, нямам сорса и единственият начин е да се снифи трафик и да се пробва.


Горните проблеми са разрешими, но най-големият проблем е че не можем лесно да "намаляме" response time-а освен ако часовниците на двете машини са синхронизирани, което обикновено не е случая. Тоест (както сигурно сте забелязали) можем да намаляме response time-a с милисекунди, но не можем да го вкараме в някакви разумни мярки и когато клиентът забележи, че timestamp-а е в бъдещето, се оплаква.

За целта трябва да се направи state таблица и промените да стават на база делтите между timestamp-овете на пристигналите icmp пакет-и, които могат да варират доста при бавна връзка. В идеалният случай може да се направи нещо което сработва след няколко получени пакети, но за първите пристигнали не можем да излъжим, няма начин освен ако не се сдобием с някакви свръхестествени способности.

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: laskov в Nov 01, 2011, 21:15
Цитат на: b2l в Nov 01, 2011, 17:57
Цитат на: laskov в Nov 01, 2011, 17:46
Аз имах предвид повишаване на приоритета, ако такова нещо е възможно.

Приоритет на какво?
На трафика - [ -Q tos ]

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: abadon в Nov 02, 2011, 00:57
Цитат на: amarth в Nov 01, 2011, 17:12
@abadon
Не съм съгласен с "Всички ние знаем че тези ms не са мерило за това колко ти е бърза връзката."

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

"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 ($2)

Интересна информация си ми дал. Само дето тези неща ги знам и съм ги чел много много отдавна, тъй като Делян ми приятел от 5-6 години. Около 2.5 години работех за него в бившата му фирма преди да се разпадне и т.н....

Точно днес с него дискутирах въпроса, каза че може да се напише iptables модул със стотина реда код който да дропи icmp echo request-ите, след което с libpcap след желаното време да се пращат icmp echo replay от името на хоста получател и така ping-а да се излъже. Като имал повече време след няколко седмици ще го разгледал въпроса, че му стана интересно.


@gat3way - Може да погледнеш идеята на Делян

Цитат на: laskov в Nov 01, 2011, 21:15
Цитат на: b2l в Nov 01, 2011, 17:57
Цитат на: laskov в Nov 01, 2011, 17:46
Аз имах предвид повишаване на приоритета, ако такова нещо е възможно.

Приоритет на какво?
На трафика - [ -Q tos ]

Приоритизацията на трафика не помага в този случай. Тя се ползва за други неща, като примерно Quality of service или при правене на шейпъри.

Дори и с най-висок приоритет да пращаш icmp пакетите въобще няма да промени response time-а ако мрежата ти не е претоварена и всичко работи както трябва, както е в моя случай. Виж ако си си запълнил канала на max може би ще се свали с малко времето, но едва ли ще е повече от няколко ms. От опита ми с проектирането и работата с мрежите знам, че на ~100Km физическо разстояние отговаря 1ms забавяне.  Това е времето нужно на светлината по оптично влакно да измине разстоянието от изпращача до получателя. Затова единствения сигурен метод за драстично сваляне е да се измисли как светлината да се свижи по-бързо....

Титла: Re: "Редуциране" на ping response time-а - търся съвет
Публикувано от: CTEHATA в Nov 02, 2011, 08:31
За техническата страна на нещата, предполагам че можеш да го решиш по много начини, като при по-добрите от тях, дори и клиентът да е с негов лаптоп за тестовете, пак ще го преметнеш. Най-мазно би било да модифицираш тялото на ICMP пакета. При код, който връща фалшив пакет след кратко забавяне, клиентът може да се усети ако тества бавен сървър

Има обаче един проблем. ВИНАГИ, когато излъжеш клиент рискуваш много.
Ако се окаже, че клиентът се интересува САМО от латентността (за някои приложения bandwith над някаква граница не е интересен), а ти го преметнеш, можеш да си навлечеш големи проблеми. Ако индиецът са го пратили да гледа пингове, защото ше ползват отдалечена база данни и някакво клиентско приложение, твоите трикове ще се окажат класическа измама. В държави като Германия, това може да има последици и за теб.

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

На твое място бих зарязал пинга, а бих наблегнал на демо с 10 HD камери, които предават едновременно или нещо подобно.


Powered by SMF 2.0 Beta 4 | SMF © 2006, Simple Machines LLC