Usporena brzina SFTP

Pozdrav svima,

Imam jedan (meni) interesantan problem.

Na jednom kraju konekcije je file-server/NAS (80/8Mbps CATV), na drugom client (100/100Mbps FTTH).
Preko SFTP prebacujem fajlove sa servera na client (znaci 8Mbps), i to je radilo savrseno (vec vise stotina GB sa stabilnih 7-8Mbps) mesecima, sve do pre 2-3 nedelje.

E sad. Nista nije menjano ni na jednoj strani, ali sada mi se brzina otprilike prepolovila, i nije stabilna, vec varira negde izmedju 2.5-4Mbps, ali je uglavnom izmedju 3-4Mbps (ne prekida se konekcija, vec je samo usporena).
CATV signal na modemu je navodno dobar (danas je na brzinu proverio drug koji radi u ISP), ali detaljnije cu moci da saznam tek za par dana.

Ono sto je interesantno je, da ako merim brzinu preko speedtest.net ili drugog slicnog servisa, DL je dosta manji nego 80Mbps (30-40-50Mbps koji mi zapravo i nije toliko bitan), ali UL je tu oko 7-8Mbps.
Bez obzira koji server/drzavu da odaberem na speedtest.net, UL je uvek oko 7-8Mbps, sto je zapravo i u redu.
Ali kad hocu fajlove da prebacujem, UL sa NAS-a nikad ne ide preko tih 3-4Mbps. Naravno u lokalnoj mrezi ide, znaci nije do NAS-a.
Probao sam SFTP, FTP, NFS, CIFS ... menjao portove ... ali nista. UL nece brze od 3-4Mbps.

Ima li neko ideju zasto dobijam dobru brzinu na speedtest.net (ping: 30ms, jitter: 10ms), a samo pola preko file-servisa?

Vec danima istrazujem ovo, i sve mi se vise cini da je problem do ISP-a (promena u ruti, prioriteta, il inesto slicno).
Ali nikako mi ne ide u glavu zasto je brzina OK na speedtest.net ...

Najbolje da probas da izmeris brzinu izmedju klijenta i servera, sa recimo iperf, to se lako postavlja i odmah vidis kolika je, pa ako je to dobro da sumnjas na servis.

Hvala za ovaj iperf.
Izmerio sam i sa tim, i meri otprilike istih 3-4Mbps kao sto dobijam i preko SFTP, a i router pokazuje za vreme iperf testiranja otprilike tu brzinu.
Ali sto je interesantno, da kad merim sa speedtest.net, i on izmeri 7Mbps, i router pokazuje protok od oko 7Mbps!!!
Sad sam proverio i sa fast.com, i tamo je 7Mbps, i router takodje pokazuje 7Mbps.
Ne razumem ... :(

Sutra cu vec nadam se vise saznati o kvalitetu signala na CATV modemu, pa cu videti sta dalje ...

Jel moguce da iperf ne meri dobro?

Nije moguće. Rezultati koje daje iperf su stvarna realna brzina protoka u lokalnoj mreži.

Speedtest testira file transfer izmedju tvog lokalnog kompa i njihovog servera koji je tebi najblizi. Ti mozes sasvim lepo da imas protok od 8Mbps na relaciji server-speedtest jer kada sa svog servera odes na speedtest.net, on te preusmeri na neki srvXXX.speedtest.net koji je najblizi tvom serveru. Isto vazi i kada testiras sa klijenta (klijent-speedtest). Medjutim, izmedju klijenta i servera protok i dalje moze da bude traljav i tu je mogucih razloga bezbroj ...

Kada si koristio iperf verovatno si koristio TCP. Da li si probao UDP (iperf -u)? Speedtest koristi UDP, dok SFTP (kao i NFSv4, moguce i CIFS) koristi TCP, a performanse TCP zavise od mnogo toga.

To ti je ono kada meriš do najbližeg servera, probaš test my net do londona i nemaš polovinu protoka...

Ali kad merim preko interneta, onda ISP moze da utice na protok, zar ne? moze da blokira ili "uspori" odredjene portove ...

Tačno, trotluju torente, recimo...

Da, koristio sam TCP, sad sam probao i sa UDP:

[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 976 KBytes 7.99 Mbits/sec 690
[ 5] 1.00-2.00 sec 977 KBytes 8.00 Mbits/sec 691
[ 5] 2.00-3.00 sec 977 KBytes 8.00 Mbits/sec 691
[ 5] 3.00-4.00 sec 976 KBytes 7.99 Mbits/sec 690
[ 5] 4.00-5.00 sec 977 KBytes 8.00 Mbits/sec 691
[ 5] 5.00-6.00 sec 977 KBytes 8.00 Mbits/sec 691
[ 5] 6.00-7.00 sec 976 KBytes 7.99 Mbits/sec 690
[ 5] 7.00-8.00 sec 977 KBytes 8.00 Mbits/sec 691
[ 5] 8.00-9.00 sec 976 KBytes 7.99 Mbits/sec 690
[ 5] 9.00-10.00 sec 977 KBytes 8.00 Mbits/sec 691
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 9.54 MBytes 8.00 Mbits/sec 0.000 ms 0/6906 (0%) sender
[ 5] 0.00-10.00 sec 9.13 MBytes 7.66 Mbits/sec 1.292 ms 1268/6899 (18%) receiver

Ako oduzmem 18% gubitka od 8Mbps, to je 6.66Mbps, koliko meri i speedtest.

Ali kako zna iperf da je izgubio 18%, ako kod UDP neme provere da li je paket stigao u celosti?

Iperf i sa jedne i druge strane...
dogovoriš kolko ćeš poslati...

Inace bili juce tehnicari iz ISP, zamenili jedan kablic, kazu da je sad HFC u redu.
Mada (kaze drug iz ISP da) je i pre toga bilo OK, tako da nisu nista popravili i da javimo ako i dalje ne bude dobro.
Sutra ce doci neko drugi ...

Nego, pogledao sam status na samom modemu, i power level na cetvrtom upstream kanalu je 0.0 dBmV.
Ovo je Cisco EPC3925 modem/router.
Na par mesta sam video na netu da modem pokazuje power level samo na prvom kanalu, ili sva cetiri.

Ovako je kod mene (Upstream channels power level):
1: 30.8 dBmV
2. 31.0 dBmV
3. 31.0 dBmV
4. 0.0 dBmV

Zna li mozda neko da li je ovo ovako dobro sa tri kanala, ili mora da rade sva cetiri?

OK, tako sam i pretpostavio da se dogovore koliko ce slati, ili koliko je bilo poslato.

Pa imaš tri kanala, linija je dobra jer modem se ne napreže mnogo da šalje, mada je mislim 30 malo nisko...

Kakav je ping izmedju klijenta i servera? Koliki je RTT? Kako izgleda traceroute od klijenta ka serveru i obrnuto?
UDP i TCP rade na razlicite nacine. UDP spamuje paketima dokle god mu to protok na samom interfejsu omogucava. TCP ceka na potvrdu pre nego sto posalje sledeci paket i tu u igru ulaze brojni parametri, pri cemu su najvazniji velicina prozora (window size - WS) i povratno kasnjenje (round-trip time - RTT, podatak koji ti vraca ping). Maksimalni protok koji mozes da postignes kod TCP je kolicnik 8*WS/RTT (ova osmica je tu zato sto se WS izrazava u bajtovima, a protok najcesce u bit/s). U normalnim okolnostima, maksimalni WS je 65535 bajtova, pa ako ti je kasnjenje izmedju servera i klijenta npr. 200 ms = 0.1s tada imas 8*65535/0.2 = 2.6Mbps i to bez obzira na protok na interfejsu. Vise informacija imas ovde.

Mozda ti se kasnjenje na relaciji server-klijent povecalo iz nekog razloga - npr. ako neki od provajdera koristi razlicitu rutu u odnosu na onu koju si imao ranije.

U tom slucaju mozda moze da ti pomogne TCP Window Scale Option (RFC1323), mada bi to u novijim OS trebalo da bude ukljuceno po defaultu.

Ovo gore je samo jedan moguci uzrok, mozda se i ne uklapa u tvoj slucaj ...

Tako je. Upstream power level vrednosti su ispod normalnih vrednosti. Nešto tu ne valja. Da li ima packet loss-a?

Ping RTT je prosecno 34ms u oba pravca, sa 0.1% (klijent->server) i 1.3% (server->klijent) gubitaka paketa. Tako nesto je bilo i pre, tako da smatram da je to u redu.

Evo traceroute od klijenta prema serveru:

 1  fritz.box				 (192.168.178.1)   0.647 ms  0.389 ms  0.414 ms

 2  1.64.63.185.rev.ftth.sak.ch		 (185.63.64.1)	   4.549 ms  4.671 ms  4.472 ms

 3  sak.zh.as8758.net			 (212.25.27.189)  19.983 ms  9.243 ms  4.512 ms

 4  grace.glb.as8758.net		 (83.150.35.140)   4.898 ms  5.013 ms  5.293 ms

 5  swissix.retn.net			 (91.206.52.143)   4.283 ms  4.351 ms  4.201 ms

 6  et410-6.rt.tnr.beg.rs.retn.net	 (87.245.234.69)  23.247 ms 23.198 ms 23.253 ms

 7  gw-sattrakt.retn.net		 (87.245.240.171) 26.977 ms 34.383 ms 27.475 ms

 8  91.102.227.34			 (91.102.227.34)  26.313 ms 26.069 ms 26.592 ms

 9  91.102.226.226			 (91.102.226.226) 25.669 ms 25.989 ms 25.560 ms

10  * * *

i ovako ide do maksimalnih

64  * * *

i od servera prema klijentu:

 1  fritz.box				 (192.168.188.1)   1.988 ms  1.802 ms  1.724 ms

 2  1-40-40-46.cpe.sattrakt.net		 (46.40.40.1)	  39.251 ms 40.030 ms 40.245 ms

 3  91.102.226.254			 (91.102.226.254) 46.729 ms 24.260 ms 46.658 ms

 4  91.102.227.21			 (91.102.227.21)  16.367 ms 16.522 ms 18.021 ms

 5  91.102.228.162			 (91.102.228.162) 17.910 ms 23.060 ms 22.940 ms

 6  193.188.137.52			 (193.188.137.52) 35.551 ms 24.879 ms 28.153 ms

 7  hu0-0-1-0.01.p.czh.ch.as15576.nts.ch (217.11.214.32)  28.042 ms 31.377 ms 33.186 ms

 8  212.103.68.205			 (212.103.68.205) 36.320 ms 36.213 ms 30.854 ms

 9  zara.zh.as8758.net			 (212.25.28.233)  33.092 ms 61.982 ms 35.027 ms

10  swissix.zh.as8758.net		 (91.206.52.6)	  64.934 ms 65.076 ms 34.417 ms

11  swissix.glb.as8758.net		 (91.206.52.2)	  35.602 ms 33.838 ms 35.698 ms

12  ghayda.glb.as8758.net		 (83.150.35.141)  61.464 ms 61.193 ms 34.791 ms

13  1.64.63.185.rev.ftth.sak.ch		 (185.63.64.1)	  37.008 ms 33.642 ms 32.266 ms

14  * * *

i ovako ide do

30  * * *

Nisam nesto puno koristio traceroute, pa ne znam da li je timeout na hop-ovima problem ili nije ...

Inace bio je prekjuce admin iz ISP-a, zamenio je modem. Nazalost nista se nije promenilo, i dalje je sve usporeno ... :(
Znaci ili je problem do signala, ili neka promena rute ...

Nema packet loss-a, ili je beznacajno.
Jel se ti upstream kanali "ukljucuju" po potrebi? Jako me iritira zasto ne radi taj cetvrti kanal ... ;)
Drug kaze da njegov modem pokazuje vrednosti na svih cetiri US kanala.

Jel zna neko neki brz FTP server sa kojim bih mogao da testiram brzinu (po mogucnosti UL i DL)? (Tele2 sam probao, ide sa spomenutih 3-4Mbps)
Dobro bi bilo da je u Srbiji, a idealno ako je u STCable mrezi ...

Znas kako ako treba da imas 4 kanala a rade samo 3 + sto ti je nizak nivo signala, mozda da se obratis
ISP-u da sredi kablove?

Nije, to je verovatno zato sto neko od ISP na putu filtrira ICMP Echo ili UDP (portove 33434-33534), tako da ruteri ne odgovaraju na te upite.

Svejedno, ovo sto si poslao daje neka zanimljiva zapazanja. Recmo, rutiranje u smeru klijent-server i obrnuto ti je asimetricno. Od klijenta ka serveru put vodi od Svajcarske direktno na RETN (ruski operater, prisutan i u Svajcarskoj), a onda u jednom hopu stizes do Beograda, sto je malcice cudno ... mada mozda RETN krije traceroute hopove (ako koriste MPLS to je moguce postici). U suprotnom smeru ide preko Budimpeste gde direktno ulazi u mrezu jednog svacjarskog operatera (NTS - AS15576) i dalje nastavlja ka tvom operateru (IWAY - AS8758). Drugim recima, ti imas:

* Klijent-server: AS8758 - AS9002 - AS41897
* Server-klijent: AS41897 - AS15576 - AS8758

Uvidom u RIPE/RADB bazu, vidi se da je direktan peering izmedju AS15576 i AS41897 novijeg datuma, odnosno da nije dokumentovan nigde. Bas kao sto ni bix.hu nema nigde podatak da je Sattrakt njihov clan, tako da mi sve ovo lici se Sat-Trakt prikacio na Budapest Internet Exchange (bix.hu) nedavno, da je tamo napravio neke peeringe sa nekim operaterima ... izmedju ostalog, verovatno i sa AS15576, koji ti sada kvari rutiranje. Neki ruter na tom putu verovatno negde baguje.

Ako te ne mrzi, mozes li da bacis ovde output za traceroute sa SERVERA (znaci i Srbije) ka: www.nic.ch, www.cern.ch ... i mozda www.swisscom.ch i [62.2.34.16]. Tu bi bilo zanimljivo videti gde i kako ide rutiranje. Rutiranje sa strane klijenta je nebitno, ono ocigledno nije promenjeno.

Takodje, ovo sto Bane predlaze nije lose da proveris sa provajderom. A isto tako, da ih pitas da li su nesto menjali u svojoj mrezi u poslednje 2-3 nedelje. Mada, oni ce 100% tvrditi da nista nisu dirali i da je sve do tebe ... klasika ...