Goed... en dan nu de resultaten [LAN]

[bash!]

Hallo iedereen.. heb mijzelf even vermaakt met het analyseren van de ethernet stream tussen dreambox en pc..

 

voor de duidelijkheid; het volgende is de opstelling -->

 

Dreambox <-> crosscable <-> PC/Lan analyser

 

De gebruikte analyser is van een professioneel type en geeft een reëel gemiddelde van de stream weer.

 

gebruikte process is een FTP stream gegenereerd met FlashFXP. (expres geen andere programma's om een duidelijk vergelijk te krijgen.)

 

Er is een TS bestand gekopieerd van exact 1GB.

 

Hieronder de resultaten:

 

Streamen van Dreambox naar PC

 

100 Mbit Full Duplex max stream 3.752 MBytes per sec

100 Mbit Half Duplex max stream 3.476 MBytes per sec

10 Mbit Full Duplex max stream 1.032 MBytes per sec

10 Mbit Half Duplex max stream 1.148 Mbytes per sec

 

Streamen van PC naar Dreambox

 

100 Mbit Full Duplex max stream 1.532 MBytes per sec

100 Mbit Half Duplex max stream 0.964 Mbytes per sec

10 Mbit Full Duplex max stream 1.024 Mbytes per sec

10 Mbit Half Duplex max stream 1.212 Mbytes per sec

 

Duidelijk is dat de dreambox zijn 100 Mega bit lang niet haalt. Op een snelheid van 10Mbit lijkt hij beter aan de specs te komen. (wat vrij logisch is)

 

Bovenstaande snelheden moeten met 8 vermenigvuldigd worden om de snelheid in Megabits te verkrijgen. Dat betekent dat de transmissie snelheid dus niet boven 25 Mbit komt. Een vierde van wat mogelijk zou moeten zijn!

 

Mocht ik eraan toekomen, dan zal ik de stream verder analyseren om te kijken wat de latency is tussen de verschillende frames. Hieruit kan later eventueel meer blijken.

 

Op het eerste gezicht zijn er géén retransmissions te zien en verloopt de stream erg netjes. De window size zou aanzienlijk vergroot kunnen worden om zo meer data achter elkaar te kunnen versturen zonder 'ontvangst bevestiging'.

 

Het is denk ik aan de linux guru's om te kijken of deze optie beschikbaar is in de netwerk drivers.

 

Is er iemand die weet welke opties beschikbaar zijn??

 

Ik hoop dat iemand hier iets aan heeft!

 

Groeten,

Bas

 

 

[tCC]

om de test compleet te maken moet je het eigenlijk ook ff testen met NFS, aangezien dat toch wel DE reden is om te klagen...

[Bart]

100mbit/s haal je effectief nooit door de benodigde overhead. Alles meer dan 50 mbit/s effectief over een 100 mbit lijn is prima.

 

Hogere snelheid is voor streamen en NFS niet belangrijk. Maximale bitrate die zo'n beetje wordt uitgezonden is 6 mbit/s dus zolang je daar maar boven zit is netwerk geen probleem. Vandaar dat je ook met een 10 mbit dbox2 nog heel redelijk kunt streamen.

 

Snelheid is vooral van belang wanneer je muziek of video van en naar een in de Dreambox ingebouwde harddisk wilt overzetten. Je praat dan al gauw over enkele gigabytes waarbij halvering van snelheid zoals Dreambox nu presteerd betekend dat je zo een half uur langer kwijt bent met kopieeren.

 

[mietde]

Citaat:

Je praat dan al gauw over enkele gigabytes waarbij halvering van snelheid zoals Dreambox nu presteerd betekend dat je zo een half uur langer kwijt bent met kopieeren.

 

Vertel mij wat <img src="/ubbthreads/images/graemlins/mad.gif" alt="" />

 

De geteste waardes zijn overigens geflateert,

andere ftp clients zijn stukken trager zoals bijv. totalcommander.

 

een >4,5Mbyte/sec moet toch echt kunnen <img src="/ubbthreads/images/graemlins/crazy.gif" alt="" />

[Ronaldd]

Citaat:

Op het eerste gezicht zijn er géén retransmissions te zien en verloopt de stream erg netjes. De window size zou aanzienlijk vergroot kunnen worden om zo meer data achter elkaar te kunnen versturen zonder 'ontvangst bevestiging'.

Het is denk ik aan de linux guru's om te kijken of deze optie beschikbaar is in de netwerk drivers.

Is er iemand die weet welke opties beschikbaar zijn??

Tijdens creeren van een TPC/IP socket kan je de optie TCP_NODELAY mee geven wat er voor zorgt dat TPC/IP niet wacht op de 'ontvangst bevestiging' maar packetjes direct verstuurd. Dit is geen optie van de netwerk kaart en moet in de applicatie worden ingesteld. Windows staat er bekend om om de 'ontvangst bevestigingen' erg laat te versturen, lees de samba doc maar eens. Of het hier daad werkelijk om dit probleem gaat is makkelijk (voor mij) te testen. Ik heb nl. de complete samba suite gebouwd voor de dreambox en met samba kan je TCP_NODELAY aanzetten.

Zal vanavond met smbclient testen met en zonder TCP_NODELAY.

Ronald

[bash!]

Klinkt goed Ronaldd!

 

overigens is het streamen van Video TCP/UDP wat zowieso niet op ontvangstmeldingen wacht (connectionless). Hiermee zijn door veel minder overhead ook veel hogere snelheden te halen. Is het mogelijk om een TFTPd op de Dreambox te draaien? (TFTP=UDP)

 

Overigens is de overhead nooit zoveel dat je maar max 50Mbit kan halen. Tenminste... niet op een directe link zonder tussenkomende apparaten/applicaties en werkend op Full duplex. Naar mijn server via een switch kom ik nu tot ongeveer 75Mbit.

 

Gisteravond geen tijd meer gehad om de stream verder door te lopen. duidelijk is wel dat Windows inderdaad traag reageert met ontvangstbevestigingen. Misschien vanavond meer nieuws!

 

Groeten,

Bas

[Gast]

Ik doe veel performance werk met Oracle databases, en daar kun je echt het effect van tcp_nodelay. Verder is de tcp_nodelay verschillend voor elk platform. Ik heb waardes gezien van 10 ms, maar ook 100ms. Dat zorgt dus voor een hoge latency. Ik denk dat voor TCP streaming het beter zou zijn dat de tcp driver tcp.nodelay = true maakt. Is dat ook het geval?

 

 

[twel12]

Hmm, het is dus duidelijk, dat de stream NAAR de dreambox in de meeste gevallen beduidend langzamer is dan de stream naar de PC.

 

Ik ken dit verschijnsel van andere toepassingen en daar heeft het met de gebruikte cache te maken. Windows (met FlashFXP) heeft beduidend meer cache, dan de FTPServer (die misschien minimaal geïmplementeerd is) in de dreambox. (Ik heb zelf geen dreambox en weet ook niet welke FTP server daarin gebruikt wordt).

 

Ik weet bijna wel zeker, dat een schijf (in de dreambox) met 8 Mb cache VEEL beter presteert dan één met 2 Mb cache (bij transfer naar de dreambox toe).

 

Als iemand dit zou kunnen testen en de performance wordt beter, dan lijkt het mij idd een cache probleem.

 

Groeten Twel12.

[Ronaldd]

>Hmm, het is dus duidelijk, dat de stream NAAR de dreambox in de meeste gevallen beduidend langzamer

>is dan de stream naar de PC.

 

>Ik ken dit verschijnsel van andere toepassingen en daar heeft het met de gebruikte cache te maken.

>Windows (met FlashFXP) heeft beduidend meer cache, dan de FTPServer (die misschien minimaal

>geïmplementeerd is) in de dreambox. (Ik heb zelf geen dreambox en weet ook niet welke FTP

>server daarin gebruikt wordt).

 

De gebruikte FTP server op DB maakt niet zoveel uit een FTP server doet niet aan caching. Dat doet het OS. Aangezien de DB weinig geheugen over heeft is er ook maar een kleine buffer cache

 

 

>Ik weet bijna wel zeker, dat een schijf (in de dreambox) met 8 Mb cache VEEL beter

>presteert dan één met 2 Mb cache (bij transfer naar de dreambox toe).

Niet in de DB. Wat men wil is grote files (ts bestanden van 1G) heen en weer kopieren. Dan maakt 8Mb of 2 MB niets uit. Mischien dat tijdens opnemen het wat zal uitmaken. Dan kan de schijf iets meer bufferen tijdens bijf. recalibratie.

 

Ronald

 

 

[twel12]

Citaat:

Aangezien de DB weinig geheugen over heeft is er ook maar een kleine buffer cache

 

Daar sla je de spijker op z'n kop. Nu zet de schijf in de dreambox steeds "de rem" erop! Hij moet eerst z'n data flushen naar de schijf. Met een grotere schijf cache krijg je dus per saldo betere prestaties.

 

Maar alleen een experiment zal deze theorie kunnen staven.

 

Groeten Twel12.

[tCC]

Citaat:

Citaat:

Aangezien de DB weinig geheugen over heeft is er ook maar een kleine buffer cache

Daar sla je de spijker op z'n kop. Nu zet de schijf in de dreambox steeds "de rem" erop! Hij moet eerst z'n data flushen naar de schijf. Met een grotere schijf cache krijg je dus per saldo betere prestaties.

Maar alleen een experiment zal deze theorie kunnen staven.

Groeten Twel12.

ik hoop het toch niet, ik heb hopelijk NIET VOOR NIETS die 2MB Maxtor 120GB gekocht ipv die 8MB, aangezien die 2MB versie op de Dream MM site stond...

[mietde]

Citaat:

ik hoop het toch niet, ik heb hopelijk NIET VOOR NIETS die 2MB Maxtor 120GB gekocht ipv die 8MB, aangezien die 2MB versie op de Dream MM site stond...

 

Zo is het.

[Ronaldd]

Ik heb ook bewust gekozen voor een 5400 toeren schijf met 2MB. Tijdens opname wordt er een stream van ong 0.6 MByte/sec weg geschreven (als ik goed het gerekend). Deze transfer rate is vele malen lager dan wat een moderne 5400 toeren schijf kan wegschrijven.

 

Naar mijn idee maakt het weinig uit of je nu 2MB lege schijf cache hebt of 8 MB <img src="/ubbthreads/images/graemlins/laugh.gif" alt="" />

 

Ronald

[twel12]

Voor het weg schrijven van de video/audio streams is de snelheid van het HD subsystem ruim voldoende!!

 

Maar de topic starter presenteerde cijfers over de ftp transfer snelheden en daar gaat de discussie dus eigenlijk over.

 

Groeten Twel12.

[Ronaldd]

Citaat:

Maar de topic starter presenteerde cijfers over de ftp transfer snelheden en daar gaat de discussie dus eigenlijk over.

Dat klopt maar de rol van een harde schijf is daarin vreselijk belangrijk. Als je een trage hardeschijf hebt kan je wel een gigabit ethernet hebben maar de data gaat NOOIT sneller over de lijn dan dat de harde schijf data kan aanleveren. Het is zelfs nog erger bij opslaan op een langzame schijf vanaf snelle machine over 100Mb.

Met 100Mbit per seconde praten we wel over 12.5 MByte per seconde menig harde schijf kan dat niet continuu opleveren. Daarom was mijn eerste probeersel om netwerk snelhijd te meten (in ander topic waar dit vervolg op is) zonder harddisk.

Ronald