[All] Speed up LAN?

[DBdrug]

Zie bij user scripts in DCC het volgende staan:

 

Speed up lan -> ifconfig eth0 mtu 570

 

Standaard staat de mtu op 1500 (te zien in webinterface bij Configuratie, Settings).

 

Werkt bovenstaande, geeft het inderdaad snelheidswinst? Zou interessant voor de DM500 met opnemen over netwerk, dan gaat nog wel eens moeizaam.

Weet dat daar ook een andere oplossing voor is (solderen!), maar als het zo verbeterd kan worden is dit natuurlijk stukje gemakkelijker..!!

 

Vermoed dat het nogal van je netwerkconfiguratie afhangt. Weet dat Windows ook standaard de mtu op 570 heeft staan voor lokale netwerken (lan's), voor alleen internet is mtu 1500 sneller. Maar dat is voor de Dreambox meestal niet van toepassing.

 

Weet heeft hier ervaring mee? Zal het eens testen.

[Gast]

Weet je al wat meer ??

[DBdrug]

Nee, nog niet... en ook niemand anders die hier ooit mee heeft ge-expirimenteerd? Kan me haast niet voorstellen.

[Gast]

De max mtu van ethernet (t/m 100mbit) is 1500. Verlagen leidt bij mij (op een dm500) tot een minder presterend netwerk. Maar het is toch niet heel moeilijk om zelf uit te proberen of het invloed heeft?

[DBdrug]

Gister ff getest met opname, opname loopt na ongeveer 10 sec. helemaal vast! Duidelijk geen verbetering dus... nou ja, viel te proberen!

 

Waarom het dan 'Speed up lan' heet in DCC is mij niet duidelijk...

[Gast]

DCC kan ook voor de andere dreamboxen en waarschijnlijk zelfs voor de dbox gebruikt worden. Op andere boxen geeft het wellicht een ander resultaat. Misschien dat het bij de maker van DCC wel werkte <img src="/forums/images/graemlins/smile.gif" alt="" />.

[Alfi]

Zo lastig is de hardware mod niet. En die geeft toch echt de allerbeste resultaten. Ik had dezelfde problemen met mijn DM500S. 200-300k/s max. Na de mod is het een gwoon werkende 10mb interface geworden.

 

Streamen gaat zonder problemen en ook opnemen werkt helemaal prima.

 

Theo

[Pat3068]

ter info:

mtu size = maximum transfer unit size

de maximum hoeveelheid data in elk te verzenden pakketje wordt gestopt. Elk pakketje bevat een stukje adressering, wat (uiteraard) ook in elk pakket meegezonden wordt. Hoe meer data je dus per pakket hebt, hoe beter de verhouding tussen data en adres informatie(overhead genoemt).

Dus bij de hedendaagse netwerken bij voorkeur de mtu size zo groot als mogelijk. (ethernet heeft een limiet van 1500 bytes per pakket, dit zelfs ook minder zijn, onder bepaalde condities)

Als je meer erover wil lezen:

http://en.wikipedia.org/wiki/MTU_%28networking%29

[Gast]

De optie in DCC is bedoeld om de standaard pakketgrootte van 1500 bytes op te splitsen in pakketjes van 570.

Dit werkt erg goed op netwerken waarbij veel packetloss optreedt.

 

Wat er in de praktijk gebeurd is dat als een pakket van 1500 bytes niet op tijd ontvangen wordt, er een NACK (not acknowledge) naar de verzender wordt gestuurd om aan te geven dat uit de reeks pakketten dit ene pakketje gemist wordt. Vervolgens begint de verzender opnieuw met verzenden van de pakketje vanaf het missende pakketje... M.a.w. de gehele reeks wat na het missende pakketje verstuurd was moet, inclusief het missende pakketje, opnieuw verstuurd worden.

 

Indien je netwerk last heeft van veel packetloss dan kun je je voorstellen dat het steeds maar weer opnieuw hertransmitten van lost packets de effectiviteit en dus de doorvoersnelheid niet ten goede komt.

 

Splits je nu de 1500 pakketjes op in 2x 570 dan neemt weliswaar de effectiviteit af (1x 1500 is sneller dan 2x 570 uitlezen) maar in het geval van een packetloss hoeft er niet zoveel opnieuw verzonden te worden.

 

Dus, heb je een goed functionerend netwerk (even een pingtest doen) dan gewoon default op 1500 laten staan. Zie je tijdens een pingtest (continu test) dat er packets gedropt worden (time out) dan zou je de optie voor 570 kunnen nemen.

 

Ron

[Gast]

In een normale TCP sessie wordt na elk pakket een ACK verwacht, als die niet komt binnen de timeout, dan volgt een retransmissie van dat pakket. Dat proces werkt sequentieel.

 

Daarnaast kunnen zender en ontvanger samen een TCP window size afspreken, waarbij er inderdaad meerdere pakketten verstuurd worden zonder op een ACK te wachten (de window size). Echter, zodra er packet loss op treed zal dit window direct en automatisch worden verkleind om te veel hertransmissies te voorkomen, dat is ingebouwd in het TCP protocol. Uiteindelijk kun je dus weer uitkomen op een window size van 1.

 

Het verkleinen van de MTU is meestal (en zeker in het geval van recording/playback) een slecht idee, omdat de tijd die je theoretisch zou winnen door minder hertransmissie verloren gaat aan de tijd die je nodig hebt voor packet assembly/disassembly (omdat alle pakketjes in tweeen gesplitst moeten worden). Bovendien wordt 't een puinhoop als MTU discovery niet lekker werkt in je netwerk, de andere kant blijft dan pakketten versturen met de standaard ethernet MTU.

 

Die window size is relevant om de data zo snel mogelijk weg/binnen te krijgen. Vooral op Windows staat deze veel te klein ingesteld om gebruik te maken van een 100Mb interface. Zoek daarvoor naar "HKEY_LOCAL_MACHINE\SYSTEM\CurrentC­ontrolSet\Services\Tcpip\Parameter­s", daar moet een sleutel staan met de naam "TCPWindowSize". De waarde daarvan moet minstens 131072 (128KB) zijn voor voldoende performance op 100Mb. Is deze sleutel afwezig of is de waarde lager, dan wordt de throughput afgeknepen door de te kleine window size.

 

Op mijn 7000 is de standaard window size 108544 (ls -l /proc/sys/net/core, de rmem en wmem waardes), 4 keer de standaard MS Windows windowsize! Mijn linux server (Redhat EL4) gebruikt standaard wel een 128Kb window.

 

Er zullen vast nog wel meer parameters te tunen zijn, daar moet ik nog eens tijd voor vrijmaken. <img src="/forums/images/graemlins/wink.gif" alt="" />

[DBdrug]

Okay, mooie uitleg allemaal!

 

Maar hoe verander ik de 'TCPWindowSize' op mijn DM7000, WanWizard? En dat kan waarschijnlijk op dezelfde manier op m'n DM500?! Dat zou dus dan wel snelheidswinst moeten (kunnen) geven.

 

Pingtest uitgevoerd hier, geen enkel probleem met netwerk. Dus 'MTU' op 1500 zal beste resultaten geven, dit ook inderdaad gezien bij opnemen.

[Gast]

echo [nummer] > /proc/sys/net/core/ ... en dan de rmem* en wmem* files. Zie http://www.speedguide.net/read_articles.php?id=121 voor wat voorbeeldjes.

 

Maar op een DM7000 staan ze op 108544, en dat is ruim voldoende. Het probleem zit 'm vaak aan de andere kant, op de NAS of de Windows machine die voor de mount gebruikt wordt. Ik heb geen idee wat de default is op een DM500, maar (voor Pli in ieder geval) komen beide images uit dezelfde built tree, met dezelfde kernel, dus ik verwacht dat die gelijk zullen staan.

 

Als je dat wilt controleren: cat /proc/sys/net/core/wmem_max (en rmem_max).

 

Mocht je dit echt willen dan moet je ook nog een plaats vinden waar je deze commando's moet plaatsen, want dit moet bij elke boot gebeuren, en wel voor de initialisatie van de netwerk driver...