Forum Debian Users Gang

To nie musi być kwestia latencji, tylko obciążenia routera ISP.

Im bardziej przeciążony jest router, tym wolniej reaguje na pingi.

W samym protokole Ipv4 router ma już praktycznie dowolną fragmentację pakietów, dowolną długość nagłówka TCPv4, sumę kontrolną pakietu TCP i do tego jeszcze czasami NAT.
Jeżeli po Ipv4 leci sobie przez ten 1Gbit router równocześnie setka filmów z Youtuba, Netfiksa i CDA, to możesz przy 10 metrach kabla do routera ISP zobaczyć nawet 500ms.

Jeżeli ktoś ma w Windowsie bootneta, który akurat atakuje dom maklerski z Londynu srając fragmentowanymi pakietami UDP z prędkością 1Gbit albo nawet 2.5Gbit na nowej mobo,
to może zapchać całego switcha czy router, wywalić w ten sposób net na całej ulicy, coś podobnego też widziałem.

Czas faktycznej odpowiedzi na ping nie musi oznaczać odległości czy latencji, może mieć na niego wpływ wiele czynników.

Ping I hopa u mnie:

PING 95.160.240.1 (95.160.240.1) 56(84) bytes of data.
64 bytes from 95.160.240.1: icmp_seq=1 ttl=254 time=4.53 ms
64 bytes from 95.160.240.1: icmp_seq=2 ttl=254 time=8.74 ms
64 bytes from 95.160.240.1: icmp_seq=3 ttl=254 time=5.66 ms
64 bytes from 95.160.240.1: icmp_seq=4 ttl=254 time=6.15 ms
64 bytes from 95.160.240.1: icmp_seq=5 ttl=254 time=5.80 ms
64 bytes from 95.160.240.1: icmp_seq=6 ttl=254 time=4.59 ms
64 bytes from 95.160.240.1: icmp_seq=7 ttl=254 time=5.27 ms
64 bytes from 95.160.240.1: icmp_seq=8 ttl=254 time=6.53 ms
64 bytes from 95.160.240.1: icmp_seq=9 ttl=254 time=6.43 ms
64 bytes from 95.160.240.1: icmp_seq=10 ttl=254 time=6.48 ms

modem kablowy, skrętka 75 Ohm, sieć jeśli wierzyć ISP - FTTB, w praktyce jednak FTTDp.

Przy okazji, sieć  mojego operatora była modernizowana gruntownie w okolicach typowego łącza 50Mbit, teraz dział handlowy wszystkich klientów ciągnie za uszy na oferty 300-450 Mbit, a sieć od tego zaczyna się zatykać.
To jest rzeczywistość wszystkich w Polsce operatorów stacjonarnych i wielu komórkowych też.

Nabrali też Cię w tym gigabitem internetu, nie ma ani w Polsce ani na świecie serwera WWW,
z którego możesz targać więcej niż 80Mbit na sekundę (10MB/s).
Najszybsze chmury jak Fastly (obrabia Netfixa) pozwalają pobierać około 3-5MB/s, vod.tvp.pl czy cda.pl do około 4MB/s, podobnie Youtube ale dla zalogowanych.

Więc zastosowania dla łącza 1Gbit w domu nie masz żadnego poza niebagatelną ceną.

Pozdro

Ostatnio edytowany przez Jacekalex (2023-04-29 02:01:00)

sykstus napisał(-a):

Mam dwa pytania:

1. To normalne, że samo przyłączenie do sieci szkieletowej odpowiada za ponad 97% latencji (6.244 / 6.427)? Czy jednak to świadczy o jakimś problemie pomiędzy moim routerem a pierwszym serwerem dostawcy?

2. Czy ogólnie taki ping z domu to na dzisiejszą technologię max czego mogę oczekiwać? Jak to u was wygląda? (gdy wynajmowałem serwery w zewnętrznych serwerowniach to miałem pingi poniżej 2 ms)

Tak jak napisał Jacekalex - to zależy od obciążenia sieci ISP i też od konfiguracji. U mnie np jedyny względnie sensowny, lokalny, ISP na wiochach okolicznych kładzie światłowód, w mieście różnie. Po mieście gdzieniegdzie rozprowadzony jest światłowód i np są węzły z których do konkretnych bloków leci koncentryk. Różnica między taką opcją a czystym światłem w pingu z tego co pamiętam jest około trzykrotna ale musiałbym sprawdzić jak się dorwę do jakieś "świetlnej" sieci. U mojego ISP na wioskach są pingi "do" ISP rzędu 2 ms, na zewnątrz (od ISP "dalej") latają chyba po 5ms.
Patrz niżej. Pierwsze dwa pingi to są od lokalnego ISP, następne dwa to są lokalne portale ale nie mam pojęcia gdzie znajdują się serwery.

PING brama.satfilm.pl (77.91.63.254) 56(84) bytes of data.
64 bytes from brama.satfilm.pl (77.91.63.254): icmp_seq=1 ttl=253 time=9.22 ms
64 bytes from brama.satfilm.pl (77.91.63.254): icmp_seq=2 ttl=253 time=10.4 ms
64 bytes from brama.satfilm.pl (77.91.63.254): icmp_seq=3 ttl=253 time=7.61 ms
64 bytes from brama.satfilm.pl (77.91.63.254): icmp_seq=4 ttl=253 time=6.93 ms
64 bytes from brama.satfilm.pl (77.91.63.254): icmp_seq=5 ttl=253 time=7.43 ms

PING satfilm.pl (77.91.63.233) 56(84) bytes of data.
64 bytes from www_nowe.satfilm.pl (77.91.63.233): icmp_seq=1 ttl=61 time=9.30 ms
64 bytes from www_nowe.satfilm.pl (77.91.63.233): icmp_seq=2 ttl=61 time=11.5 ms
64 bytes from www_nowe.satfilm.pl (77.91.63.233): icmp_seq=3 ttl=61 time=7.64 ms
64 bytes from www_nowe.satfilm.pl (77.91.63.233): icmp_seq=4 ttl=61 time=7.80 ms
64 bytes from www_nowe.satfilm.pl (77.91.63.233): icmp_seq=5 ttl=61 time=7.04 ms

PING q4.pl (46.29.21.81) 56(84) bytes of data.
64 bytes from x1.przemasss.com (46.29.21.81): icmp_seq=1 ttl=55 time=23.4 ms
64 bytes from x1.przemasss.com (46.29.21.81): icmp_seq=2 ttl=55 time=22.4 ms
64 bytes from x1.przemasss.com (46.29.21.81): icmp_seq=3 ttl=55 time=20.7 ms
64 bytes from x1.przemasss.com (46.29.21.81): icmp_seq=4 ttl=55 time=20.0 ms
64 bytes from x1.przemasss.com (46.29.21.81): icmp_seq=5 ttl=55 time=21.2 ms

PING ddwloclawek.pl (104.21.235.143) 56(84) bytes of data.
64 bytes from 104.21.235.143 (104.21.235.143): icmp_seq=1 ttl=55 time=19.1 ms
64 bytes from 104.21.235.143 (104.21.235.143): icmp_seq=2 ttl=55 time=14.5 ms
64 bytes from 104.21.235.143 (104.21.235.143): icmp_seq=3 ttl=55 time=12.4 ms
64 bytes from 104.21.235.143 (104.21.235.143): icmp_seq=4 ttl=55 time=11.4 ms
64 bytes from 104.21.235.143 (104.21.235.143): icmp_seq=5 ttl=55 time=12.5 ms

PING onet.pl (99.83.207.202) 56(84) bytes of data.
64 bytes from aafc88a28d9997374.awsglobalaccelerator.com (99.83.207.202): icmp_seq=1 ttl=248 time=15.1 ms
64 bytes from aafc88a28d9997374.awsglobalaccelerator.com (99.83.207.202): icmp_seq=2 ttl=248 time=13.4 ms
64 bytes from aafc88a28d9997374.awsglobalaccelerator.com (99.83.207.202): icmp_seq=3 ttl=248 time=12.6 ms
64 bytes from aafc88a28d9997374.awsglobalaccelerator.com (99.83.207.202): icmp_seq=4 ttl=248 time=11.3 ms
64 bytes from aafc88a28d9997374.awsglobalaccelerator.com (99.83.207.202): icmp_seq=5 ttl=248 time=11.1 ms

PING google.pl (172.217.16.35) 56(84) bytes of data.
64 bytes from muc03s08-in-f35.1e100.net (172.217.16.35): icmp_seq=1 ttl=120 time=13.3 ms
64 bytes from muc03s08-in-f35.1e100.net (172.217.16.35): icmp_seq=2 ttl=120 time=14.4 ms
64 bytes from muc03s08-in-f35.1e100.net (172.217.16.35): icmp_seq=3 ttl=120 time=11.1 ms
64 bytes from waw02s14-in-f3.1e100.net (172.217.16.35): icmp_seq=4 ttl=120 time=11.2 ms
64 bytes from muc03s08-in-f35.1e100.net (172.217.16.35): icmp_seq=5 ttl=120 time=11.6 ms

Jacekalex napisał(-a):

Nabrali też Cię w tym gigabitem internetu, nie ma ani w Polsce ani na świecie serwera WWW,
z którego możesz targać więcej niż 80Mbit na sekundę (10MB/s).
Najszybsze chmury jak Fastly (obrabia Netfixa) pozwalają pobierać około 3-5MB/s, vod.tvp.pl czy cda.pl do około 4MB/s, podobnie Youtube ale dla zalogowanych.

No niby masz rację ale jak mu wejdzie z 5 urządzeń korzystających z youtube'a w 1080p, jakieś torrenty w tle czy coś, aktualizacje windy i androidów, to nagle może się okazać że się sieć zapcha w moment. Ja mam tylko 300/15 ale kminię na przejście na 600/30.

Ostatnio edytowany przez Pavlo950 (2023-04-29 10:54:14)

sykstus napisał(-a):

Pavlo950 napisał(-a):

Znajomy jak mieszkał na wiosce to pingi "do" ISP miał rzędu 2 ms, na zewnątrz mu latały chyba po 5ms

No a u mnie do ISP jest ponad 6 ms, a oczekiwałem właśnie coś około 2 ms.

Może technik coś źle podłączył? Może kabel mam uszkodzony albo zanieczyszczony pomiędzy routerem a multiplekserem?

Jest taka możliwość?

7ms to nie jest duże opóźnienie.

Co innego, gdyby to było np 50 ms, ale poniżej 10 ms to nie jest żadna istotna sprawa.

Tu masz ciekawsze "czary":

 ping -c1 wp.pl
PING wp.pl (212.77.98.9) 56(84) bytes of data.
64 bytes from www.wp.pl (212.77.98.9): icmp_seq=1 ttl=59 time=14.9 ms

 lft wp.pl
Tracing .......****T
TTL LFT trace to www.wp.pl (212.77.98.9):80/tcp
 1  router (192.168.9.1) 0.4ms
**  [neglected] no reply packets received from TTL 2
 3  172.17.146.73 7.4ms
**  [neglected] no reply packets received from TTLs 4 through 5
 6  netia.plix.pl (195.182.218.13) 18.1ms
 7  WARSC001RT73.inetia.pl (83.238.248.19) 11.5ms
 8  kielb001rt02.inetia.pl (87.204.224.43) 15.3ms
 9  krakt002rt01.inetia.pl (87.204.224.175) 12.7ms
**  [neglected] no reply packets received from TTL 10
11  [target open] www.wp.pl (212.77.98.9):80 14.8ms

I tak przypadkowo serwer wp.pl odpowiedział na test lft po 14.8ms, ale router na skoku 6:

6 netia.plix.pl (195.182.218.13) 18.1ms

mimo, że ruch do wp.pl ode mnie przechodzi przez ten router.

Dlatego ICMP uważam z mocno niedoskonałą metodę diagnostyczną.

Co do samego Orange, oferty Orange to jedna sprawa, ale stan sieci Orange jest "totolotkiem" bo po prostu ta sieć jest o wiele za duża, zbyt rozległa,
żeby utrzymywać ją w każdym punkcie w najwyższej jakości, o czy nie mówią reklamy nowych łącz.
Jak pytałem ja o Orange światłowód, to najpierw mi chcieli umowę drukować, lale jak zapytałem o techniczne możliwości, to się okazało,
że takich nie ma, o czym Ja widziałem z UKE, a śliczna pani w biurze Orange ustaliła ten fakt  w swoim komputerze po około kwadransie,
i nie mogła pojąc, skąd ja o takich rzeczach wiem, skoro to Ona pracuje w Orange a nie ja.
xD

Pozdro

EDIT:
mam nowy "rekord":

lft dug.net.pl
Tracing ..*.***.*****.****T
TTL LFT trace to 70.ip-145-239-95.eu (145.239.95.70):80/tcp
 1  router (192.168.9.1) 0.4ms
**  [neglected] no reply packets received from TTL 2
 3  172.17.146.73 6.6ms
**  [neglected] no reply packets received from TTLs 4 through 5
 6  ovh.tpix.pl (195.149.232.234) 207.7ms
**  [neglected] no reply packets received from TTLs 7 through 9
10  vl1067.waw-d1-a75.pl.eu (91.121.131.151) 16.5ms
**  [neglected] no reply packets received from TTLs 11 through 17
18  [target open] 70.ip-145-239-95.eu (145.239.95.70):80 17.1ms

Niby:

18  [target open] 70.ip-145-239-95.eu (145.239.95.70):80 17.1ms

ale:

 6  ovh.tpix.pl (195.149.232.234) 207.7ms

Właśnie dlatego ICMP jest kiepskim środkiem diagnostycznym.

Ostatnio edytowany przez Jacekalex (2023-04-29 12:47:50)

sykstus napisał(-a):

Jacekalex napisał(-a):

Właśnie dlatego ICMP jest kiepskim środkiem diagnostycznym.

To masz lepszą propozycję?

Poza tym swoje pomiary robisz z urządzenia podłączonego z routerem po wifi czy kablem?

Wolę używać to:

[i] net-analyzer/lft
     Available versions:  3.91-r1{tbz2}
     Installed versions:  3.91-r1{tbz2}(09:17:00 15.02.2023)
     Homepage:            http://pwhois.org/lft/
     Description:         Layer Four Traceroute (LFT) and WhoB

W Debianie też jest:

apt policy lft
lft:
  Zainstalowana: 3.91-1
  Kandydująca:   3.91-1
  Tabela wersji:
 *** 3.91-1 990
        990 https://deb.debian.org/debian stable/main amd64 Packages
        500 https://deb.debian.org/debian testing/main amd64 Packages
        500 https://deb.debian.org/debian sid/main amd64 Packages
        100 /var/lib/dpkg/status

Bo lft po prostu nie używa icmp tylko protokołu warstwy czwartej tcp lub ewentualnie udp.
icmp to protokół bezpołączeniowy, nie nadaje się do diagnostyki tak dobrze, jak tcp, który jednak tworzy połączenie.

Dzięki temu widzę prawdziwe problemy, jak router netia.plix.pl, który w traceroute okazuje 21 ms, ale w teście tcp opóźnienie może mieć wartość ponad 200 ms.
Dosyć częsty problem, kiedy icmp formalnie chodzi ale strony www mulą jakby pchać słonia przez dziurkę od klucza.

Oprócz tego używam dosyć często nmapa, czasami iperfa.
Niezłą diagnostykę stron umożliwia też curl oraz skaner podatności nikto.

Testy robię zawsze po kablu, wifi tworzy dodatkową warstwę potencjalnych i faktycznych problemów,
przez co żaden wynik nie miałby sensu.
Np test szybkości fast.com po ipv4, po kablu mam 140-160Mbit, po wifi w okolicach 70-90Mbit.
Po wifi sygnał leci szyfrowany WPA2 AES128, tymczasem routery domowe przeważnie mają umiarkowaną wydajność szyfrowania pomimo, że reklamują w nich diabli wiedzą jakie prędkości,
w praktyce nieosiągalne.

Ostatnio edytowany przez Jacekalex (2023-04-29 17:20:44)

Sprawdzę tę usługę "fast" tylko że potrzebuję wersji konsolowej, bo tylko serwer mam po kablu i nie mam tam środowiska graficznego.

Nie chodzi o program fast czy usługę, tylko stronę testową:
https://fast.com/pl/
Konkurencję dla
https://speedtest.pl

Ostatnio edytowany przez Jacekalex (2023-04-30 06:50:57)

Da się zmierzyć z konsoli na sporo sposobów.
Np speedtest-cli - konsolowy klient napisany w Pythonie.
Np Iperf3 pozwala mierzyć prędkość miedzy dwoma hostami, na których jest uruchomiony.
Można też przy pomocy programów wget, curl, aria czy axel pobierać duże pliki faktyczne lub testowe z różnych serwerów, tu masz testowe o  dokładnych wielkościach:
http://noc.pirx.pl/

Sam apt nieźle miedzy prędkość pokazując pobieranie setki paczek z repozytorium na chmurze fastly, tej samej,
na której jest netfix i fast.com.

W konsoli tty nie ma pojęcia "nie da się" jest pojęcie "jak to zrobić"
xD

Jacekalex napisał(-a):

Da się zmierzyć z konsoli na sporo sposobów.
Np speedtest-cli - konsolowy klient napisany w Pythonie.

Wiem, że się da, pisałem, że nie da się prosto i szybko.

A podobno pomiary z serwerów SpeedTesta nie są do końca wiarygodne, bo dostawcy celowo zawyżają priorytet do tych serwerów.

To już wolę z serwerów Netflixa mierzyć.

Pavlo950 napisał(-a):

Jeśli o transfer chodzi to może po prostu sshfs i kopiowanie dużych plików między dwiema maszynami? ssh chyba nie ma żadnych ograniczeń pod tym względem?

Mógłbym, gdybym miał dostęp do swojego starego serwera, który wynajmowałem w OVH, ale już nie mam. Tamten serwer wiedziałem na pewno, że jest szybki (on miał zresztą na pewno lepsze łącze niż to które mam w domu od Orange).

Mam zamiar sobie to ogarnąć:

https://github.com/ddo/fast

Jacekalex napisał(-a):

Nikt mnie nie nabierze na przepakowanie oferty 50Mbit na 500Mbit, co nagminnie robią operatorzy, żeby mieć "rynkowe oferty".

Kiedy nagle pojawiają się formalnie wyższe transfery w sieci, która na taki wzrost przepustowości nie jest przygotowana, to cala sieć siada i cierpią wszystkie połączenia.
Kable i światłowody to nie są gumowe baloniki, które można bezpiecznie nadmuchać, na wymienianie sieci co 4 lata nie stać żadnego operatora ostatniej mili, to za duże koszty.

No ja mam to szczęście że ISP w miarę na bieżąco modernizuje swoją sieć XD 20 lat temu pamiętam że mieli transfery 128 kb/s w tej samej cenie co teraz 300 mb/s XD i rzeczywiście podnoszą dopiero po modernizacji.

Zwróć uwagę na podtytuł:

Transfer z routera mam tylko ok 1-2MB/s. Gdzie moje obiecane 300Mb/s?

w tym wątku:
https://eko.one.pl/forum/viewtopic.php?id=12021

Bardzo pouczający.

Sam znam firmę, która podłącza ludziom internet powyżej 100 Mbit ale używać można tylko do 100 Mbit.
Powód jest taki, że dostarczany sygnał w budynkach pochodzi od routera w piwnicy.
Jak się robi oszustwo?
Żeby używać ponad 100 Mbit, trzeba włączyć w swojej karcie sieciowej tryb pracy 1000baseT/Full.
Ale żaden sterownik napisany zgodnie z RFC, nie pozwoli włączyć tego trybu   bez włączenia trybu autonegocjacji.
Tylko że przy włączonej autonegocjacji router dostawcy negocjuje tylko jedną wartość, to jest 10Mbit.

Taki przypadek widziałem kiedyś na własne oczy.

A te oferty łącz od 1 Gbps do nawet 10 Gbps w OVH to też pic na wodę?

OVH nie pracuje z durnymi klientami co się nie znają, tylko z administratorami sieciowymi, którzy znają się na diagnostyce sieciowej.
Także tam wiele oszukać się nie na.

95% ludzi na świecie to idioci, którzy nie znają się na kupowanej technologii,
i to tam korpo i mniejsze firmy też szukają nadzwyczajnych zysków.

Ostatnio edytowany przez Jacekalex (2023-05-03 16:43:17)