slechte netwerkperformance Gbps netwerk

Started by richardnl, December 30, 2007, 13:05:00

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DJ-Foxx

Quote from: richardnl on December 30, 2007, 13:05:00
Hallo

Ik heb Gbps apparatuur gekocht en aangesloten en toch krijg ik maar 7 Mb per seconde als ik van ene pc naar andere PC kopieer.

Volgende config:

- cat5e kabels
- d link dir 655 router met Gbps en jumboframe support volgens de site
- windows XP machine met Gpbs netwerkkaart en jumboframe support (P4 machine en 2 Gb intern geheugen en SATA HD)
- windows vista ultimate 4 Gb intern en 6750 processor

Wie heeft suggesties om het probleem te analyseren (tools) en oplossingen?

Bedankt

Groet
Richard

Richard,

als je vanaf de doel computer de copy naar je toe trekt, heb je dan het zelfde lag probleem ???
je XP clients moeten wel minimaal SP2 hebben, SP1 wil wel eens problemen mbt doorvoersnelheden 100 / Gbit verbindingen. ::)

richardnl

Quote from: SpeedyAndré on January 29, 2008, 12:15:35


;)

André  8)

Dit is niet de optie die ik bedoel maar echt bij de netwerkkaart eigenschappen
Zal deze week een screenshot plaatsen

wh-vanderpost

#27
Quote from: richardnl on January 29, 2008, 12:56:06
Dit is niet de optie die ik bedoel maar echt bij de netwerkkaart eigenschappen
Zal deze week een screenshot plaatsen
Bedoel je de 802.1p support...

Overigens Andre, je kan het configureren met TcMon.exe (Traffic Control Monitor). Een tooltje wat in de Resource Kit zit. Ik heb het even gedownload en erop gezet, maar het is vrij wazig allemaal.
Denon AVC-X3800H | NVidia Shield Pro | PS3
Tannoy Revolution R2 | RC (front+back) | R1 | SVS PB12-ISD
LG G3 83"
WBT | Oehlbach | Ixos | Kopp | Canare | Belden | DIY UTP | AudioQuest

Del member

Volgens mij heb je die QoS instellingen niet nodig.

Ik haalde op mijn laptop 970mbps via iperf met een TCP 256K window size.
Een filecopy vanaf samba haalde "slechts" 25Mbyte/sec.

Volgens mij zitten er beperkingen in het SMB protocol om gelijkaardige snelheden als iperf toe te laten.

wh-vanderpost

Maar iperf is toch alleen een testtooltje voor je netwerk performance...
Ik zal dat ook eens testen binnenkort op het netwerk, al kan ik het natuurlijk niet op OSX draaien ;D
Denon AVC-X3800H | NVidia Shield Pro | PS3
Tannoy Revolution R2 | RC (front+back) | R1 | SVS PB12-ISD
LG G3 83"
WBT | Oehlbach | Ixos | Kopp | Canare | Belden | DIY UTP | AudioQuest

SpeedyAndré

Northstar Extremo Monster Sigma 2K Xtc + NBS powercords Sphinx PJ8 Straightwire Virtuoso 2x Aragon Palladium Infinity Renaissance 90 Soundaware D100
Onkyo Tx-RZ3100, Panasonic DMR-UBS80, Oppo Udp203 + Bdp83, Shield 4K, Toshiba HD-XE1 PS3, PS4 Pro, Infinity Kappa center B, 4x Kappa Video II, 4x Oreus (height), SVS PB12ISD, Sony Vpl-VW550ES,  Harmony Elite + Companion, TX-P42U10E, LG UJ620V, VU+ Uno 4K SE, Zidoo Z9S+UHD3000, 50TB in DS1515+
2x Toshiba Daiseikai 8 3,5kW, Atlantic Ex V3 wpboiler 200l+coil Panasonic MDC07H3E5 warmtepomp

wh-vanderpost

Denon AVC-X3800H | NVidia Shield Pro | PS3
Tannoy Revolution R2 | RC (front+back) | R1 | SVS PB12-ISD
LG G3 83"
WBT | Oehlbach | Ixos | Kopp | Canare | Belden | DIY UTP | AudioQuest

Del member

ik heb iperf maanden gebruikt om IP over satteliet te testen
het is zeker geschikt om de maximale performantie te meten wat je kan halen

richardnl

zie de image
Qos Package tagging heb ik aangezet

Del member

Hier staat QoS Packet Scheduler ook aangevinkt onder de Local Area Connection properties (volgens mij default).
In mijn driver heb ik geen QoS opties, wel TCP checksum acceleratie en dat soort offload toestanden deze staan aan.


Wim44

Als je kopieert van schijf naar schijf over Gbps verbinding dan is de snelheid van de HD zelf al een bottleneck. De Gbps verbinding is sneller. Voorbeeld: 1 Gbps = 1000 Mbps = 100 MBytes/sec.
De snelheid is te verhogen door de bloklengte van de records en de buffering tussen de schijf en het geheugen anders in te stellen.

Uitje

Heb er niet zo heel veel verstand van maar als je zegt dat QoS iets uitmaakt voor de netwerk performance dan denk ik dat het probleem niet in je netwerkje zelf zit maar meer in de hardware van een van beide pc's.

riwi

Quote from: DJ-Foxx on January 29, 2008, 12:35:05
als je vanaf de doel computer de copy naar je toe trekt, heb je dan het zelfde lag probleem ???
je XP clients moeten wel minimaal SP2 hebben, SP1 wil wel eens problemen mbt doorvoersnelheden 100 / Gbit verbindingen. ::)

Ik las deze tip van je en heb daar een vraag over. Ik heb namelijk een duidelijk verschil tussen het versturen van een file en het halen van een file :
PC A heeft een file en die wil ik kopieren ik naar PC B
Geef ik het kopieer commando op PC A en kopieer ik naar de netwerkschijf die zich in PC B bevind dan zie ik 22-25 MB/sec gemiddeld.
Start ik een remote desktop sessie naar PC B en kopieer vandaar vanaf de netwerk schijf op PC A de file naar lokale drive van PC B dan zie ik 50MB/sec die dan zakt tot 40MB/sec maar  over 200GB gewoon gemiddeld 38-40MB/sec blijft.

Het experiment werkt ook andersom : file staat op PC B en moet naar PC A. Sturen van PC B naar PC A : 22MB/sec.
Zelfde bestand halen van PC B door het kopieer commando op PC A te geven 40-50MB/sec.
Volgens mij is dit een windows setting/eigenschap ergens, maar ik weet niet waar of wat het is.

PC's zijn allemaal WinXP Pro SP2, geupdate met ctupdate. Switches zijn netgear gs105 en gs108(2x) Jumboframes staat uit. Netwerk kaart : intel Pro1000 PCI-E x1 en een interne nvidia Nforce430. Processors : E6750 en Athlon64-3000+ en AthlonX2-3800. Cat5e en Cat6 bekabeling. Schijven allemaal raid0 2x500G of 2x750G samsungs, of 4x500G raid0 op de linuxPC.

Ik zie ook verschillen is ook met 1 PC op linux : XP --> Linux  22-25MB/sec   XP<---Linux +35MB/sec

Ik denk dus echt dat winXP een limiet zet op de via SMB te versturen data... maar hoe zet je die uit ???

Iemand een idee? Ik wil graag beide kanten op met 40-50MB/sec :)

richardnl


Wim44

Wat is de maximale overdracht snelheid van je schijven ?

Kjelt

Quote from: riwi on July  1, 2008, 22:10:28
Ik denk dus echt dat winXP een limiet zet op de via SMB te versturen data... maar hoe zet je die uit ???
Iemand een idee? Ik wil graag beide kanten op met 40-50MB/sec :)
Wellicht heb je hier iets aan: een interessante academische paper: http://www.pats.ua.ac.be/content/publications/2006/mmertens_IPProtocols.pdf
Op pagina 11 staan enkele parameters die voor SMB onder XP zijn verhoogd.
Als je naar de grafieken kijkt zie je dat bij 1 connectie ze inderdaad bij Intel read bij de 20MB/s blijven hangen, echter met meerdere connecties gaat dit lineair omhoog tot 80MB/s (4 connecties).
Oftewel als je meerdere files wilt kopieren dan kun je dit beter parallel aan elkaar opstarten dan als 1 grote kopieeraktie.
Ik heb de paper niet helemaal doorgelezen dus misschien staan er meer handige tips of verklaringen in waarom deze limiet optreedt bij SMB

riwi

Quote from: richardnl on August 21, 2008, 15:32:14
niemand een suggestie?

Ik denk dat er iets op 100Mbit blijft steken. Daarvoor is de 7MB/s limiet wel te begrijpen.

Je schijven zijn vast wel snel genoeg (iig sneller dan 7MB/sec). Zelfs een 5 jaar oude ATA schijf haalt makkelijk
50MB/sec. De huidige SATA gaan 80-100MB/sec en daarboven.

Had je als test al eens ipv switches ertussen een cross ethernet kabel tussen beide PCs gelegd? (voor Gbit kun je ipv cross een gewone patch kabel gebruiken want gbit netwerkkaarten doen auto mdi-x). Met zo'n test zou je rand apparatuur uitsluiten.

Heb je 2 hardeschijven in de PC? Als je van de ene HD naar de andere HD kopieert (grote file 10GB of zo) gaat dat wel vlot?

Ik heb 1 oude PC die hard blijft steken op 4MB/sec maar dat is een bekende hardware fout in de VIA chipset voor de disk access (miniITX PC met Via C3 processor)

@Kjelt bedankt, ik zal het eens doorlezen.

gijsnoorlander

Quote from: Kjelt on August 21, 2008, 16:54:58
[...]
Oftewel als je meerdere files wilt kopieren dan kun je dit beter parallel aan elkaar opstarten dan als 1 grote kopieeraktie.
Ik heb de paper niet helemaal doorgelezen dus misschien staan er meer handige tips of verklaringen in waarom deze limiet optreedt bij SMB
Nee, je kunt alleen zinnig meerdere threads starten als de files op verschillende schijven staan en ook naar verschillende schijven geschreven worden.
Een schijf die op 2 plaatsen tegelijk moet schrijven (of lezen) is altijd netto langzamer dan wanneer dat in 1 stroom data kan.

Het SMB protocol gebruikt allerlei methodes om ook bij beroerd aangelegde netwerken te voorkomen dat de performance totaal in elkaar stort. Dat is tegenwoordig met switches niet zo'n issue meer, maar het zit bij gbit- en 100Mbit netwerken nog wel in de weg.
Bij 100Mbit netwerk kun je bijvoorbeeld zonder problemen 66Mbit halen tussen 2 PC's, maar zodra een derde machine erbij komt en ook wat gaat babbelen over dat netwerk, dan zakt die transfer onherroepelijk naar 33 Mbit/s.
Bij Gbit heb ik ook veel van dergelijke transfers gezien, alleen was het dan vaak blijven hangen op 166 Mbit of 333 Mbit.
Een heel enkele keer haal ik ook werkelijk de max snelheid van mijn schijven (85MB/s), maar meestal zit het rond die 20 a 40 MB/s. en dan ook alleen nog maar bij grote files.

Kjelt

#43
Quote from: gijsnoorlander on August 24, 2008, 16:35:39
Nee, je kunt alleen zinnig meerdere threads starten als de files op verschillende schijven staan en ook naar verschillende schijven geschreven worden.
Een schijf die op 2 plaatsen tegelijk moet schrijven (of lezen) is altijd netto langzamer dan wanneer dat in 1 stroom data kan.
Als dat zo is dan ligt dit aan het OS want als je puur naar de hardware kijkt dan zie je het volgende:

bedenk dat de seektime niet zoveel uitmaakt op de datatransfersnelheid. Om een voorbeeld te geven de 1TB WD Caviar black heeft een sustained (dus continue) transferrate van de print naar het moederbord (SATA bus) van 145MB/s  :o en deze heeft een 32MB buffer.
Hij heeft een max. seektime van 4ms,  Transfer van HDDplatter to buffer is gelimiteerd aan het RAMgeheugen van 40ns (ik neem per write 64bits (8bytes) dan duurt dit  ongeveer 17ms (12x sneller als sustained datarate van 145MB/s).
Dan neem ik ook nog even ten nadele van deharddisk snelheid aan dat er pas weer gelezen wordt als de buffer leeg is:

Dan krijgen we het volgende scenario:
                                                              proces 1                parallel proces 2                                          total time
HDD read file1  disk to buffer 32MB                17ms                                                                                          17ms
Transfer buffer -> SATA start  (32/145)                                       220ms                                                         
seek                                                          4ms                                                                                          21ms                 
Wachten tot buffer leeg is:                                                                                                                         237ms
HDD read file2  16MB /80MB/s  200ms             17ms                                                                                                                           
en weer verder.

Oftewel de hele bottleneck van de harddisk zit in de sustained dataread van 145MB/s wil de seektime van de harddisk een significante rol gaan spelen dan
zou de sustained SATA datarate in de orde van  4ms voor 32MB zijn oftewel  ruim 8000MB/s !!!!

Als het OS slim zou zijn en voldoende buffers heeft dan zou je dus bijv. bij 2 threads  2x237ms per 2x32MB nodig hebben en kun je op je sloffen de 25MB/s van smb aan.
Hoeveel threads dan theoretisch:  32MB/s*237ms = 135MB/s /25MB/s = 5 threads. De fabrikant garandeert zelfs 145MB/s (dus de echte HDD wacht niet tot de buffer helemaal leeg is maar heeft dual port ram aan boord  ;)

Waar het dus fout gaat is of bij de chipset op het moederbord OF en dat verwacht ik eigenlijk, bij het OS.
Wil dit echt goed gaan dan moet het OS weten hoe groot de buffer van de HDD is en deze dan altijd in volle buffergroottes via DMA aanvragen en daar zal het fout gaan vermoed ik, waarschijnlijk worden er steeds kleinere blokjes opgevraagd zeker als je een programma als windows exploder hebt met alle fancy grafische fruttels erop  ;)

gijsnoorlander

Quote from: Kjelt on August 25, 2008, 11:15:30
Als dat zo is dan ligt dit aan het OS want als je puur naar de hardware kijkt dan zie je het volgende:

bedenk dat de seektime niet zoveel uitmaakt op de datatransfersnelheid. Om een voorbeeld te geven de 1TB WD Caviar black heeft een sustained (dus continue) transferrate van de print naar het moederbord (SATA bus) van 145MB/s  :o en deze heeft een 32MB buffer.
Van HDD-controller naar mainboard kan ik zo gauw niet terug vinden wat WD claimt, alleen dat het een SATA-300 interface heeft.
In een test, waarbij achter elkaar zo snel mogelijk van de schijf gelezen wordt zoals hier halen beide schijven zo'n 80-110 MB/s en dat ook nog alleen maar aan het begin van de schijf.
De WD-schijf in die test heeft trouwens 16 MB cache, dus mogelijk is het ook niet helemaal dezelfde schijf als die jij bedoeld. De Seagate schijf in die test performed een stukje beter dus ik denk dat we die dan wel kunnen vergelijken met de schijf die jij in gedachte hebt. Dat de leessnelheid afneemt is trouwens ook niet meer dan logisch, aangezien de omtrek in het midden kleiner is dan aan de rand en de rotatie-snelheid over het algemeen constant is (die WD schijf had in de omschrijving een rpm van 5400-7200, maar dat is volgens mij een powersave-optie)

Quote from: Kjelt on August 25, 2008, 11:15:30
Hij heeft een max. seektime van 4ms,  Transfer van HDDplatter to buffer is gelimiteerd aan het RAMgeheugen van 40ns (ik neem per write 64bits (8bytes) dan duurt dit  ongeveer 17ms (12x sneller als sustained datarate van 145MB/s).
Dan neem ik ook nog even ten nadele van deharddisk snelheid aan dat er pas weer gelezen wordt als de buffer leeg is:
Laten we die cijfers eens gebruiken...
track-to-track zoektijden zitten in de orde van 4 ms terwijl zoektijden naar een willekeurig deel van de schijf in de orde van 12-17 ms zitten. (gemiddeld een halve rotatie wachten is met 7200rpm ruim 4ms en dan nog de wat meer dan de 4 ms track-to-track latency)
Volgens jouw gegevens van 145 MB/s leessnelheid vanuit de cache naar de controller is de controller-snelheid dus niet de beperkende factor, aangezien je in de praktijk met achter elkaar lezen amper boven de 100 MB/s komt. Kortom de schijf zelf kan het niet bijbenen. Als je dus achter elkaar een blok data leest heb je aan het eind van een track dus hooguit 4ms vertraging, maar in de praktijk minder.
Als je afwisselend een blok data hier op de schijf leest en het volgende blok daar, dan heb je steeds tussen die blokken data een vertraging van zo'n 12+ ms. Dan gaat het dus puur om de grootte van die afwisselende blokken data. Als je bijv een sec lang blok A leest en een sec lang blok B dan vallen die 12ms in het niet, maar als je dat in blokken van 1 MB (of nog kleiner) doet dan is die delay in verhouding enorm en zakt de gemiddelde leessnelheid dus enorm in.
Die blokgrootte is meestal een OS-keuze, of de keuze van de applicatie.
In de praktijk zie ik de performance behoorlijk inzakken als er meerdere threads tegelijk zijn richting dezelfde schijf.
Het kan best zijn dat die nieuwe 1 TB schijven zelfs in random-access-mode benadering per stroom data de 20+ MB/s makkelijk halen. Mijn grootste schijf in mijn werkbak is 500GB WD RE-2.
In de HTPC heb ik wel een TB-schijf van Samsung zitten, maar daar zit geen gbit ethernet verbinding op dus zinvol testen is dan niet echt mogelijk.

[....]

Quote from: Kjelt on August 25, 2008, 11:15:30
Oftewel de hele bottleneck van de harddisk zit in de sustained dataread van 145MB/s wil de seektime van de harddisk een significante rol gaan spelen dan
zou de sustained SATA datarate in de orde van  4ms voor 32MB zijn oftewel  ruim 8000MB/s !!!!
8000 MB/s haalt je geheugen in de PC niet eens en mogelijk in dual-channel zou je in de buurt kunnen komen terwijl daar ook vaak zo'n 8 chips parallel zitten te werken. Op een schijf zit er vaak maar 1 zo'n chipje, dus ik denk dat daar die 145MB/s vandaan komt, namelijk de snelheid van het cache-geheugen.

Quote from: Kjelt on August 25, 2008, 11:15:30
Als het OS slim zou zijn en voldoende buffers heeft dan zou je dus bijv. bij 2 threads  2x237ms per 2x32MB nodig hebben en kun je op je sloffen de 25MB/s van smb aan.
Mee eens, OS en applicatie hebben veel invloed op de performance.

Kjelt

Het hangt er inderdaad vanaf welke blokgrootte er door het OS bij lezen wordt gekozen EN de blokgrootte van de formatering EN de mate van fragmentatie van de schijf. Echter als je dus kijkt als er gekozen wordt voor het lezen van  de buffergrootte en de blokken redelijk bij elkaar in de buurt liggen dan heb je zeker een factor 10 nog over voor de harddisk zelf een beperking vormt.
Link voor de genoemde technische data van deze harde schijf: (pdf)

gijsnoorlander

Trouwens nog een tip voor redelijk rappe file-transfer over je netwerk... Teracopy
Als je gewoon via de verkenner files copy/paste naar een netwerkshare, neemt Teracopy het over.
Over 100Mbit netwerken haal ik dan gemiddeld zo'n 11,5 MB/s (relatief grote files van minstens een paar MB groot), terwijl dat zonder Teracopy zo'n 4-6 MB/s is in de praktijk.
Over WiFi scheelt het ook, al scheelt het niet zo veel als met bedraad (max zo'n 50% van netwerksnelheid, waar dat normaal zo'n 33% is).
Ander groot voordeel is dat je transfer niet gelijk afgebroken wordt als een file niet benaderbaar is oid. en je weer moet gaan opzoeken waar 'ie gebleven is. Ook kun je een transfer weer resumen of pauzeren.

richardnl

teracopy is echt te gek...
ik haal nu 32 MB / S max en gemiddeld ongeveer 30  ;D

thanks voor de tip

richardnl

Sinds kort heb ik een homeserver draaien.
De eerste resultaten zijn echt top 60 MB per seconde via terracopy....

Wimpie007

Bij mij zakt het ineen als een pudding :(
Installeer je het op alle pc's?
CinéSas:ThemeScene H56A, Marantz SR4600, DIY - Profigold - Lapp kabels, Samsung DVD, HTPC, Wharfedale Diamond 9.1 surround,...DVD collectie
Stereo: Sony ES EV, Classé VV, Marantz CD5000, PC, Wharfedale Pacific Evolution 10,...