Pingi - czy mają znaczenie?

[MasterNETpl 100]

@m0tTo możesz wyjaśnić jak zwykły użytkownik ma zauważyć ping o 3ms mniejszy i co dla niego to w praktyce znaczy?

[m0tTo 0]

@m0tTo możesz wyjaśnić jak zwykły użytkownik ma zauważyć ping o 3ms mniejszy i co dla niego to w praktyce znaczy?

Średnio ping mniejszy o 3ms (to celem sprecyzowania). Biorąc pod uwagę skrajne maksymalne wartości zmniejszył się on o 9, pomijając już spadek liczby strat pakietów do prawie zera (wcześniej było ciut więcej, a nawet ciut ciut więcej).

No tak - ktoś zaraz zaraz ironicznie zawoła - strona mi sie ląduje 3ms szybciej. W praktyce łączność pomiędzy klientem a serwerem odbywa sie pakietami. Nie zagłębiając się w szczegóły powiedzieć trzeba, że dla każdego z takich pakiecików czas podróży zmniejszył się średnio o 3ms, co w przypadku średniej wielkości serwisu oznacza, że będzie się on ładował około 1s szybciej. Doliczając do tego straty, które była a już nie ma wartość tą można mniej więcej podwoić. Ja rozumiem, że na serwerze www nie ma to aż takiego znaczenia, ale chodziło mi o to , że tak dokładnie ponoć sprawdzający jora użyszkodnicy nie wychwycili takiej zmiany na lepsze.

[p 3]

No tak - ktoś zaraz zaraz ironicznie zawoła - strona mi sie ląduje 3ms szybciej. W praktyce łączność pomiędzy klientem a serwerem odbywa sie pakietami. Nie zagłębiając się w szczegóły powiedzieć trzeba, że dla każdego z takich pakiecików czas podróży zmniejszył się średnio o 3ms, co w przypadku średniej wielkości serwisu oznacza, że będzie się on ładował około 1s szybciej.

...moge spytac skad ta 1s?

[MasterNETpl 100]

@p pewnie z teorii która w ogóle nie ma poparcia w praktyce.

Nigdy bym nie wpadł, że 3ms trasy pakietów to aż 1s szybciej ładująca się strona...

wystarczy odrobinę logicznie pomyśleć.

[Tomasz Fiedoruk 98]

Kurcze to jak ja mam 200ms do DH, to strona powinna mi się w półtora minuty ładować

[Drapak 0]

Ja się pewno nie znam tak jak panowie fachowcy ale wydaje mi się, że raczej średnio

można porównywać czas przelotu pakietów ping z przelotem pakietów z danymi, ale

gdyby się uprzeć to wystarczy sprawdzić ile pakietów generuje odświeżenie np. tego

forum, a generuje jakieś 220 z czego około połowa to przychodzące z serwera do przeglądarki

(tcpdump -n -host 62.181.4.40 ... itd. co tam kto chce) więc nawet jeśli lecą o 3ms

krócej to razem daje to ~0,3 sek szybsze ładowanie strony.

[owszem 0]

No nikt już nie zauważył, że pingi do jor.pl zmalały o średnio 3ms.

A kogo to obchodzi. Zainteresowanie jor.pl wynika tylko z problemow z serwerem. Co komu po serwerze, który bez przerwy ma awarie, iptime jaki jest każdy widzi. Twoje zdanie jest prawdziwe tylko pod warunkiem, że serwer jest dostępny, a to wcale nie jest pewne. Często też te pingi można sprawdzić na stronie, której pisze "Przerwa techniczna, zapraszamy za kilka minut", tylko pomyliły im się minuty z godzinami.

 

Pozdrawiam.

[cyrial 0]

to razem daje to ~0,3 sek szybsze ładowanie strony.

 

A zaokrąglając w górę, to daje 1 sekundę (ironia). Tak jak by zwykli użytkownicy nie mieli co robić, tylko zachwywać się tym, że strona ładuje się krócej o 0.3 sek. JEEEEE superowo! Nie wiem jak inni, ja aż tak wyczulony nie jestem...

[p 3]

ale gdyby się uprzeć to wystarczy sprawdzić ile pakietów generuje odświeżenie np. tego

forum, a generuje jakieś 220 z czego około połowa to przychodzące z serwera do przeglądarki

(tcpdump -n -host 62.181.4.40 ... itd. co tam kto chce) więc nawet jeśli lecą o 3ms

krócej to razem daje to ~0,3 sek szybsze ładowanie strony.

ilosc pakietow != ilosci zadan, tak wiec Twoje obliczenia mocno mijaja sie z prawda.

[Drapak 0]

ilosc pakietow != ilosci zadan

Mówimy o szybkości przesyłania pakietów czy o szybkości obsługi przez serwer żądań z przeglądarki? Bo chyba zboczyłeś z tematu, ew. przedstaw swoje obliczenia.

Poza tym jak ktoś ma kiepski dns to w ogóle nie odczuje zmiany w szybkości ładowania stron,

aby pominąć opóźnienia z zapytań dns trzeba mieć na kompudełku np. dnsmasq.

 

pozdrawiam

[p 3]

Mówimy o szybkości przesyłania pakietów czy o szybkości obsługi przez serwer żądań z przeglądarki? Bo chyba zboczyłeś z tematu, ew. przedstaw swoje obliczenia.

Nie zboczylem z tematu, tylko znam podstawy dzialania protokolu TCP

[T 6]

Mówimy o szybkości przesyłania pakietów czy o szybkości obsługi przez serwer żądań z przeglądarki? Bo chyba zboczyłeś z tematu, ew. przedstaw swoje obliczenia.

Poza tym jak ktoś ma kiepski dns to w ogóle nie odczuje zmiany w szybkości ładowania stron,

aby pominąć opóźnienia z zapytań dns trzeba mieć na kompudełku np. dnsmasq.

Twoje wypowiedzi są załamujące.

 

 

Nie zboczylem z tematu, tylko znam podstawy dzialania protokolu TCP

To nawet nie jest śmieszne tylko smutne. Ale czego się spodziewać, gdy np. konsultantom TPNET mylą się protokoły TCP/UDP/ICMP i używają tych skrótów zamiennie?

[p 3]

To nawet nie jest śmieszne tylko smutne. Ale czego się spodziewać, gdy np. konsultantom TPNET mylą się protokoły TCP/UDP/ICMP i używają tych skrótów zamiennie?

Hmm...?

[Drapak 0]

Nie zboczylem z tematu, tylko znam podstawy dzialania protokolu TCP

Dobrze, czy na podstawie tych podstaw może przytoczyć swoje wyliczenia?

 

Twoje wypowiedzi są załamujące.

To nawet nie jest śmieszne tylko smutne. Ale czego się spodziewać, gdy np. konsultantom TPNET mylą się protokoły TCP/UDP/ICMP i używają tych skrótów zamiennie?

No dobrze, rozumiem, że posmutniałeś bo wspomniałem o dns, który chodzi na udp

(a czasem też na tcp, np. u mnie). I jesteś załamany rzucając we mnie paroma skrótami

z protokołów sieciowych, o których nie mam bladego pojęcia, jako potencjalny konsultant TP :-)

 

A może tak coś konkretniej w temacie? Bardzo proszę o wyciągnięcie mnie z ciemnogrodu,

w końcu to forum ma pomagać a nie pokazywać kto lepszy. A może się mylę? No to jazda.

 

Przypomnę może, że chodzi o wpływ czasu odpowiedzi serwera na pakiety icmp echo-request

na szybkość ładowania stron z tegoż serwera do przeglądarki.

 

pozdrawiam

[r.s 0]

Pingi do ~50ms nie są zbyt odczuwalne. Główną role odgrywa serwer, który obsługuje requesty i w jaki sposób nimi zarządza (konfiguracja httpd, mysql, php, dysku etc.).

[Drapak 0]

który obsługuje requesty i w jaki sposób nimi zarządza (konfiguracja httpd

Oczywiście masz rację, a teraz skocz na górę do #2 postu, chodzi o to aby się

ustosunkować, podając konkretne wyliczenia / pomiary, do tego co tam jest napisane.

Pisanie "to jest bzdura bo coś tam coś tam panowie z TP /której nikt nie lubi/" jest może

i błyskotliwe ale mało konkretne.

pozdrawiam

[r.s 0]

Raczej nie jest to dokładnie możliwe, ponieważ jest za dużo czynników wpływających na wydajność i ogólne działanie strony...

[p 3]

Dobrze, czy na podstawie tych podstaw może przytoczyć swoje wyliczenia?

Nie robilem zadnych wyliczen, bo mi takie rzeczy do szczescia nie sa potrzebne. Po prostu zwrocilem uwage na fakt, ze Twoje obliczenia bazuja na blednych zalozeniach (jak chociazby fakt, ze pakiety sa wysylane pojedynczno oczekujac kazdorazowo na ACK).

 

Pingi do ~50ms nie są zbyt odczuwalne. Główną role odgrywa serwer, który obsługuje requesty i w jaki sposób nimi zarządza (konfiguracja httpd, mysql, php, dysku etc.).

...i co to w ogole wnosi do tematu?

[Drapak 0]

Po prostu zwrocilem uwage na fakt, ze Twoje obliczenia bazuja na blednych zalozeniach (jak chociazby fakt, ze pakiety sa wysylane pojedynczno oczekujac kazdorazowo na ACK).

Chyba myślimy na innych płaszczyznach. Po pierwsze chodziło o to aby udowodnić, że zwiększenie

szybkości przetwarzania pakietów icmp przez ruter brzegowy, o 3 ms na pakiet, nie spowoduje

wczytywania serwisu szybciej aż o 1 sekundę. Po drugie jakie ma znaczenie ile trzeba czekać

na potwierdzenie ACK? Żadnego, bo to też jest pakiet, który przetwarza ruter (szybciej).

Uprościłem więc bardzo środowisko pomiarowe i policzyłem po prostu wszystkie pakiety jakie

przechodzą przez ruter. I napisałem o tym na samym początku.

Może zamieszanie wynikło z tego, że admin zostawił to o co się rozbija w starym wątku:

No nikt już nie zauważył, że pingi (...) zmalały o średnio 3ms. (...) to (...) zasługa, nowego routera brzegowego, którego niedawno skończyłem.

Oczywiście mogę się mylić i dlatego proszę o przytoczenie podobnego do mojego wywodu

opierającego się na lepszych założeniach. Człowiek się cały czas uczy.

 

pozdrawiam

[moron 0]

czas podróży zmniejszył się średnio o 3ms, co w przypadku średniej wielkości serwisu oznacza, że będzie się on ładował około 1s szybciej.

tzn ze jak pingi wzrosna z np 10 na 40 czyli o 30ms to strona bedzie sie ladowac 10s dluzej?

teraz to juz nic nie kapuje...

[p 3]

Chyba myślimy na innych płaszczyznach.

Nie chyba tylko na pewno.

 

Po pierwsze chodziło o to aby udowodnić, że zwiększenie

szybkości przetwarzania pakietów icmp przez ruter brzegowy, o 3 ms na pakiet, nie spowoduje

wczytywania serwisu szybciej aż o 1 sekundę.

Ze co? Z Twojego 'wywodu' wynika wlasnie, ze spowoduje... Skoro taka stona jak ta (zawierajaca lacznie kilkanascie skryptow/obrazkow) 'przyspieszy' o ~0,3s, to taka z wieksza iloscia grafik chyba bez problemow (wg. Twoich 'wyliczen') 'przyspieszy' o >1s?

 

Po drugie jakie ma znaczenie ile trzeba czekać

na potwierdzenie ACK? Żadnego, bo to też jest pakiet, który przetwarza ruter (szybciej).

Oj, ma...

 

Uprościłem więc bardzo środowisko pomiarowe i policzyłem po prostu wszystkie pakiety jakie

przechodzą przez ruter. I napisałem o tym na samym początku.

Może zamieszanie wynikło z tego, że admin zostawił to o co się rozbija w starym wątku:

Niczego nie uprosciles, tylko zrobiles burdel, ktory ma sie nijak do tego co sie dzieje w rzeczywistosci.

 

Oczywiście mogę się mylić i dlatego proszę o przytoczenie podobnego do mojego wywodu

opierającego się na lepszych założeniach. Człowiek się cały czas uczy.

Nie 'mozesz sie mylic' tylko sie myslisz, co Ci juz wyraznie wczesniej napisalem.

[Drapak 0]

Ze co? Z Twojego 'wywodu' wynika wlasnie, ze spowoduje... Skoro taka stona jak ta (zawierajaca lacznie kilkanascie skryptow/obrazkow) 'przyspieszy' o ~0,3s, to taka z wieksza iloscia grafik

Możesz mi wskazać miejsce gdzie ja pisałem o grafikach i skryptach na stronie?

Jesteś odporny na tekst pisany czy o co chodzi? Najpierw piszesz, że ilość żądań != ilosci pakietów.

Za jakiś czas znowu piszesz o obrazkach i skryptach.

Co mnie to obchodzi jaka jest zawartość strony. Liczę wszystkie pakiety włącznie z ack.

Mówimy o opóźnianiu pakietów przez ruter a nie o przetwarzaniu żądań obrazków przez apache.

Jak dla mnie jesteś totalnie odporny na tekst pisany przez kogoś innego. W dodatku zaczyna Cię drażnić, że ktoś się nie płaszczy, bo wkraczają nowe określenia, burdel, ciekawe co dalej.

Napisz coś konkretnego poza "oj ma" to pogadamy, na razie EOT.

[p 3]

Możesz mi wskazać miejsce gdzie ja pisałem o grafikach i skryptach na stronie?

Nie, bo nigdzie o nich nie pisales.

 

Jesteś odporny na tekst pisany czy o co chodzi? Najpierw piszesz, że ilość żądań != ilosci pakietów.

Za jakiś czas znowu piszesz o obrazkach i skryptach. Co mnie to obchodzi jaka jest zawartość strony.

Nie wiem czy zauwazyles, ale zawartosc strony ma bezposredni wplyw na ilosc generowanych zadan. To, ze ta liczba nie jest rowna (a w ogolnosci nie jest nawet bliska) ilosci przeslanych pakietow niczego nie zmienia.

 

Liczę wszystkie pakiety włącznie z ack.

Nie musisz tego podkreslac w kazdym swoim poscie. Zdaje sobie sprawe z tego co robisz, a takze z faktu, ze to jest zle (o czym juz Ci wyraznie wczesniej napisalem, podajac jednoczesnie jedno ze zlych zalozen, z ktorych wychodzisz - jak widac nie pomoglo).

 

Mówimy o opóźnianiu pakietów przez ruter a nie o przetwarzaniu żądań obrazków przez apache.

Z tego takze doskonale sobie zdaje sprawe.

 

Jak dla mnie jesteś totalnie odporny na tekst pisany przez kogoś innego. W dodatku zaczyna Cię drażnić, że ktoś się nie płaszczy, bo wkraczają nowe określenia, burdel, ciekawe co dalej.

Napisz coś konkretnego poza "oj ma" to pogadamy, na razie EOT.

[moron 0]

odpowie mi ktos?

CYTAT

czas podróży zmniejszył się średnio o 3ms, co w przypadku średniej wielkości serwisu oznacza, że będzie się on ładował około 1s szybciej.

tzn ze jak pingi wzrosna z np 10 na 40 czyli o 30ms to strona bedzie sie ladowac 10s dluzej?

teraz to juz nic nie kapuje...

[p 3]

odpowie mi ktos?

I tak (odpowie) i nie (nie bedzie ladowac sie o 10s dluzej)