Single tcp stream, lage snelheid

[Keiichi]

Op mijn internetlijn van ziggo heb ik een probleem dat upload en download snelheden laag zijn. Bij gewone speedtests komt dit niet naar boven omdat dslreports van meerdere stream tergelijk gebruik maakt.

Mijn netwerk situatie: Een FreeBSD 12 server hangt met aan een ziggo ubee modem in bridge mode. Die server is een nat router, maar de tests die ik gedaan heb zijn op deze server zelf.

Wat ik al gedaan heb is bepaald netwerk tuning in FreeBSD, waaronder het ophogen van de waardes van kern.ipc.maxsockbuf, net.inet.tcp.sendbuf_max, net.inet.tcp.recvbuf_max , maar haalt niets uit. Het enige vreemde wat ik verder nog kon zien was de mtu van de adapter re0 (waarop het modem zit) was 576. Het zetten naar 1500 helpt niet, de verbinding valt weg en wordt weer terug naar 576 gezet.

Waar kan ik het nog meer in zoeken?

[dion_b]

Single stream TCP performance is een functie van latency vs throughput en is erg gevoelig voor buffering en windowing.

Eerste vraag is wat exact je probleem is? Welke toepassing gebruik je die per se een enkele TCP thread nodig heeft? Normaliter zal alles wat fors bandbreedte nodig heeft vanzelf meerdere threads openen, dus is dit waarschijnnlijk een non-issue.

[Keiichi]

M'n exacte probleem is dat bij een upload voor m'n backups, m'n upload verre van vol benut wordt (5mbit ipv 20mbit mogelijk). rsync of sftp is wat dat betreft vrij single threaded :-)

Ik heb met wireshark wat proberen uit te vinden wat er anders is dan vanaf een plek waar er geen probleem is. Een verschil dat ik zie is dat vanaf de probleemverbinding de length van een IP packet 524 is en bij een andere verbinding 10 tot 30kbytes is voor een groot deel.

[dion_b]

Je loopt hier in de upload tegenaan? Dat is opvallend aangezien dat bij kabel sowieso vrij traag is, om dan in de knoop te komen met single thread moet iets goed fout staan idd

Het lijkt me onwaarschijnlijk dat dit al op de modem fout gaat, maar keerzijde: als dat wel zo is heeft het tweaken op de server weinig nut. Ik zou een known-good client rechtstreeks op modem aansluiten (tussendoor nodem rebooten zodat de nieuwe MAC een DHCP lease kan krijgen) en dat eerst uitsluiten. Ook fout? Dan heeft Ziggo iets om op te lossen (welk Ubee is het trouwens?). Geen probleem? Dan weet je dat het linksom of rechtsom je BSD server is. Ben bang dat ik zelf onvoldoende kennis heb over BSD networking om veel te kunnen helpen in dat geval.

[jvanhambelgium]

Keiichi schreef op donderdag 10 oktober 2019 @ 22:17:
Mijn netwerk situatie: Een FreeBSD 12 server hangt met aan een ziggo ubee modem in bridge mode. Die server is een nat router, maar de tests die ik gedaan heb zijn op deze server zelf.

Dus die BSD "router" / server doet dan ook de PPPoE sessie ? Omdat je spreekt over "bridge mode" of is dit een "cable modem" en krijgt je BSD server via DHCP over de z'n Realtek er0 interface gewoon een IP ?

[Will_M]

Hoe staat "alles" in je back-up programma ingesteld? Back-Up protocollen vallen, als je niets instelt, meestal terug op de laagst mogelijke snelheid om te voorkomen dat de library moet gaan bufferen.

(Altijd leuk als je weer eens één LTO drive in een off-site robot 'stuque' hebt om willekeurige redenen ..... Back-Up Window wordt dan ineens niet meer gehaald).

[ Voor 14% gewijzigd door Will_M op 12-10-2019 18:56 ]

[dion_b]

jvanhambelgium schreef op zaterdag 12 oktober 2019 @ 11:02:
[...]


Dus die BSD "router" / server doet dan ook de PPPoE sessie ? Omdat je spreekt over "bridge mode" of is dit een "cable modem" en krijgt je BSD server via DHCP over de z'n Realtek er0 interface gewoon een IP ?

Waar heb je het over? "onnodig complex door aanhalingstekens"

Ziggo is een kabelprovider, een kabelmodem in bridge mode is exact dat: het bridget de ethernetverbinding (over DOCSIS), je kunt rechtstreeks van de DHCP server van de provider een publiek IP aanvragen. Je hebt dan op dat interface een Ethernetverbinding met de buitenwereld. Als je die verbinding wilt delen met andere apparaten op LAN moet je NAT-routing doen. Dat is volgens ts wat deze BSD server (o.a.) doet.

[ Voor 9% gewijzigd door dion_b op 12-10-2019 16:22 ]

[jvanhambelgium]

dion_b schreef op zaterdag 12 oktober 2019 @ 16:20:
[...]

Waar heb je het over? "onnodig complex door aanhalingstekens"

Ziggo is een kabelprovider, een kabelmodem in bridge mode is exact dat: het bridget de ethernetverbinding (over DOCSIS), je kunt rechtstreeks van de DHCP server van de provider een publiek IP aanvragen. Je hebt dan op dat interface een Ethernetverbinding met de buitenwereld. Als je die verbinding wilt delen met andere apparaten op LAN moet je NAT-routing doen. Dat is volgens ts wat deze BSD server (o.a.) doet.

Feit dat hier dan idd geen PPPoE van toepassing wegens DOCSIS/Cable maakt het net wat minder complex. Nu, die MTU van 576 is de minimum MTU-waarde volgens RFC6691 en die blijkt dus manueel niet aanpasbaar op de server zonder dat de communicatie wegvalt na aanpassing??

Het is idd niet normaal dat je vanuit de BSD-server geen ethernet frames op de kabel kan zetten die niet hoger mogen zijn dan 576

Kan je met de Wireshark eens capturen of je dan iets van ICMP-messages ziet terugkomen van de Ziggo unit als je de MTU in stapjes gaat verhogen ?

[Will_M]

@dion_b & @jvanhambelgium : De TS probeert volgens z'n tweede post back-up data te 'streamen' .... Da's serieus wat anders dan dat wat een normale TCP 'stream' behelst.

Archive 'bit' mag bijvoorbeeld pas gezet worden als de stream 100% valide is gebleken.....

[ Voor 23% gewijzigd door Will_M op 12-10-2019 20:27 ]