trage 1 gig wan link

[Verwijderd]

opgelost, dank!

[ Voor 97% gewijzigd door Verwijderd op 04-09-2007 16:56 ]

[elevator]

Hoe test je dat hij maximaal 50 mbit haalt?

[Verwijderd]

door de tweede server te verplaatsen, en die met network monitor in de gaten te houden, en (ik weet, heel primitief) met een stopwatch te timen.

[Verwijderd]

sorry, ik las het verkeerd, we blazen een bestand van 2 gig over.

Wat ik nog toe wil voegen is dat alles op laag 2 doorgetrokken is, alles valt binnen 1 subnet.

[elevator]

OK - maar wat voor verkeer doe je er overheen dat je 50mbit haalt?

Wat voor traffic haal je als je bijvoorbeeld een 800gb file copieert (dus niet 800 keer een 1gb file, maar echt een 800gb file)?

[Westereen]

Test eens met NetCPS: http://www.netchain.com/netcps/

met de optie -m 1024 verstuur je een bestand van 1024mB.

[Verwijderd]

opgelost, dank!

[ Voor 109% gewijzigd door Verwijderd op 04-09-2007 16:56 ]

[jvanhambelgium]

Heeft KNP in 2 richtingen testen gedaan ? Als ze me UDP testen kan het mischien wel zijn dat er verschillende zitten op de Rx/Tx circuits ? Is het gewoon dark fiber of passeer je nog DWDM nodes/materiaal van KPN ofzo ?

Ik denk dat je een soort "metro ethernet" oplossing hebt, dus dat is niet direct een passive fiber te noemen tussen 2 panden ;-)

Als ze in de 2 richtingen testen gedaan hebben (wat ik wel verwacht eigenlijk) met vd UDP stream dan kan je dat al uitsluiten ...

[Verwijderd]

ik zal het morgen navragen.

Voor zover ik weet hebben ze 1 meter en een soort lus modus gezet, en de ander laten pompen.

[Kabouterplop01]

Da's dus op zich een goede test, met UDP. Geen last van overhead, bovendien als er lekker veel kleine pakketjes worden gestuurd krijgt je switch het ook goed druk. Kun je dus inderdaad het netwerk uitsluiten. Je kunt goed testen zonder virusscanner en met.
Dan serveer je eens met TFTP (UDP ) en dan met FTP (TCP). Dan zul je zien dat FTP "langzamer" lijkt. TCP heeft veel overhead.
dan met meerdere sessies tegelijk. dan zul je zien dat FTP "langzamer" blijft.
Conclusie TCP. Je zult moeten gaan meten en de TCP sliding windows size aanpassen.
Je hebt een formule nodig mbt tot de latency van de verbinding onderling.
de round trip delay van punt a naar punt b zogezegd. laten we zeggen dat je round trip 20 ms is. en dat je Bandbreedte 1 GBit is dan is de optimale tcp window size 2560000 bytes.
bij 15ms is dat 1920000 bytes. (nu weet je de formule ook)

nog een beetje:
The primary TCP tuning parameters appear in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

To enable high performance TCP you must turn on RFC1323 features (create REG_DWORD key "Tcp1323Opts" with value 3) and set the maximum TCP buffersize (create REG_DWORD key "GlobalMaxTcpWindowSize" with an appropriate value such as 4000000, decimal).

If you want to set the system wide default buffer size create REG_DWORD key "TcpWindowSize" with an appropriate value. This parameter can also be set per interface at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interface\interfaceGUID, which may help to protect interactive applications that are using different interfaces from the effects of overbuffering.

[jvanhambelgium]

zelfs "out-of-the-box" zal elk Windows product meer als 50 megabits / sec neerzetten !!! Zonder enige tuning of tweaking.
Dit is gewoon een abnormale waarde...

1) Is het in beide richtingen -> van de server op locatie ophalen / naar de server op locatie schrijven
2) Doe een test op de andere locatie tussen een client en die betreffende server, als je daar WEL plots 2x of 3x de snelheid gaat halen moet je toch KPN nog eens bellen...

Dus te testen :

Locatie 1 : client -> Locatie 2 : server SCHRIJVEN (snelheid ? hier haalde je met een test 50Mbit/s)
Locatie 1 : client -> Locatie 2 : server LEZEN (snelheid ?)
Locatie 2 : client -> Locatie 2 : server LEZEN en SCHRIJVEN

[TrailBlazer]

Test eens met behoorlijke software en niet dmv een kopieeractie vanuit verkenner.
Iperf is al een stuk beter en je kan hierin ook lekker veel rotzooien met TCP windowsizes. Die link in de TS geeft inderdaad je waarschijnlijke probleem aan.
Je kan bijvoorbeeld eens proberen 20 files van elk een GB te kopieren met een ftp client die meerdere sessies ondersteunt. Dan zul je gezamenlijk op meer bandbreedte komen als elke sessie netjes 50 mbit haalt. Sowieso is het onrealistisch om te denken dat je slechts een sessie over een WAN heen zet.
Het is dus ook geen gekke waarde als je delay maar hoog genoeg is.

[ Voor 5% gewijzigd door TrailBlazer op 28-08-2007 08:57 ]

[jvanhambelgium]

>Sowieso is het onrealistisch om te denken dat je slechts een sessie over een WAN heen zet.
>Het is dus ook geen gekke waarde als je delay maar hoog genoeg is.

Hangt af van welk soort product de TS eigenlijk bij KPN heeft afgenomen.
Met een soort "metro ethernet" (dus ethernet -> (d)wdm -> ethernet) oplossing waarbij je dus vb 1000BaseT tussen 2 vestigingen kan doen moet je met een simpele file copy binnen 1 sessie al redelijke snelheid halen, vergelijkbaar als vb cross-lan cable tussen 2 pc'tjes zet.
Als het een MPLS/VPLS oplossing betreft zou dat ook gewoon precies "transparent" 1000BaseT moeten capabel zijn...

Ik doe "out-of-the-box" tussen 2 XP Pro PC's > 30MBytes/sec (dus toch wel enkele honderden megabits/sec) en bij de TS mag dat niet anders zijn....

[Brahiewahiewa]

'k Zou niet zomaar in het wilde weg aan de TCP parameters gaan lopen sleutelen.
Windows is auto-tuning wat dat betreft en 't zou erg vreemd zijn als dat nou net in jouw geval vertragend werkt.
Eerste wat je moet controleren is of de routering goed is.
Dus vanaf server1: TRACERT server2
en vanaf server2: TRACERT server1
Daarna moet je met een packet sniffer gaan kijken waarom de vertraging optreedt. 't Kan best zijn dat er in de routers een of andere vorm van spoofing is aangezet (Acks of keep-alives) die niet het bedoelde effect hebben, of dat er voortdurend re-transmits worden verzonden waardoor de throughput laaag blijft. Of wie weet heeft een of andere slimmerik QoS aangezet. Loopt er ook VOIP over die lijn? Dan zou het kunnen zijn dat iemand het achterlijke advies van Cisco heeft gevolgd om een MTU van 64 bytes in te stellen. Over MTU gesproken: je hebt toch niet perongeluk jumbo frames aangezet op je server(s)?

[brederodekater]

Heb je er misschien firewalls tussenstaan die als gateways fungeren voor de servers?, of heb je een 1 op 1 verbinding tussen de servers over hetzelfde VLAN?

Firewalls kunnen nog wel eens voor een performance-drop zorgen

[jvanhambelgium]

>Dus vanaf server1: TRACERT server2
>en vanaf server2: TRACERT server1

Denkelijk hebben ze een L2 service van KPN (vb een VPLS/MPLS oplossing ofzo) dus je gaat geen enkele tussenliggende hop zien ... het lijkt alsof het gewoon hetzelfde segment is...

[TrailBlazer]

[quote]jvanhambelgium schreef op dinsdag 28 augustus 2007 @ 09:09:
>Sowieso is het onrealistisch om te denken dat je slechts een sessie over een WAN heen zet.
>Het is dus ook geen gekke waarde als je delay maar hoog genoeg is.

Hangt af van welk soort product de TS eigenlijk bij KPN heeft afgenomen.
Met een soort "metro ethernet" (dus ethernet -> (d)wdm -> ethernet) oplossing waarbij je dus vb 1000BaseT tussen 2 vestigingen kan doen moet je met een simpele file copy binnen 1 sessie al redelijke snelheid halen, vergelijkbaar als vb cross-lan cable tussen 2 pc'tjes zet.
Als het een MPLS/VPLS oplossing betreft zou dat ook gewoon precies "transparent" 1000BaseT moeten capabel zijn...

Ik doe "out-of-the-box" tussen 2 XP Pro PC's > 30MBytes/sec (dus toch wel enkele honderden megabits/sec) en bij de TS mag dat niet anders zijn....
[/quote
Ik heb even zitten kijken en een van onze 10Gbit linken onbelast het is de backup heeft al een delay van 4 ms 6500 switches. het is wel een behoorlijke afstand (wel binnen nederland)
Maar ik bedoelde meer dat hij even alle factoren moet gaan bekijken voordat hij besluit dat de link beroerd is. Testen of een link zijn bandbreedte haalt met een stopwatch en een kopieeractie in windows is natuurlijk verre van betrouwbaar.

Brahiewahiewa schreef op dinsdag 28 augustus 2007 @ 09:11:
'k Zou niet zomaar in het wilde weg aan de TCP parameters gaan lopen sleutelen.
Windows is auto-tuning wat dat betreft en 't zou erg vreemd zijn als dat nou net in jouw geval vertragend werkt.
Eerste wat je moet controleren is of de routering goed is.
Dus vanaf server1: TRACERT server2
en vanaf server2: TRACERT server1
Daarna moet je met een packet sniffer gaan kijken waarom de vertraging optreedt. 't Kan best zijn dat er in de routers een of andere vorm van spoofing is aangezet (Acks of keep-alives) die niet het bedoelde effect hebben, of dat er voortdurend re-transmits worden verzonden waardoor de throughput laaag blijft. Of wie weet heeft een of andere slimmerik QoS aangezet. Loopt er ook VOIP over die lijn? Dan zou het kunnen zijn dat iemand het achterlijke advies van Cisco heeft gevolgd om een MTU van 64 bytes in te stellen. Over MTU gesproken: je hebt toch niet perongeluk jumbo frames aangezet op je server(s)?

Het is een laag 2 link in ieder geval zou die zich zo gedragen voor de TS tracerouter heeft dus nul effect denk ik zo.
Jumboframes dan zou het alleen maar sneller worden of helemaal niet meer werken. Wel een goede optie BTW om jumboframes aan te zetten.

[Verwijderd]

opgelost, dank!

[ Voor 95% gewijzigd door Verwijderd op 04-09-2007 16:56 ]

[paella]

Dus als je FTPen zou, gaat het wel snel? Zou je nog kunnen testen.

[TrailBlazer]

dit is dus puur het probleem met TCP windowsize. Het heeft (voor de verandering) een niet met windows te maken maar met de beperkingen van het TCP protocol. Toen TCP bedacht werd had geen mens het voor mogelijk gehouden dat je Gbit links had met een latency van 4 ms. Met wat tweaken wordt het wel wat beter. Je kan ook nog met sACK (selective ACK) gaan expirimenteren.
FTP'en zal dus ook niet sneller gaan of ieder geval niet schrikbarend.

[ Voor 8% gewijzigd door TrailBlazer op 28-08-2007 20:26 ]

[Verwijderd]

opgelost, dank!

[ Voor 95% gewijzigd door Verwijderd op 04-09-2007 16:58 ]

[serkoon]

dit is dus puur het probleem met TCP windowsize. Het heeft (voor de verandering) een niet met windows te maken maar met de beperkingen van het TCP protocol. Toen TCP bedacht werd had geen mens het voor mogelijk gehouden dat je Gbit links had met een latency van 4 ms. Met wat tweaken wordt het wel wat beter. Je kan ook nog met sACK (selective ACK) gaan expirimenteren.
FTP'en zal dus ook niet sneller gaan of ieder geval niet schrikbarend.

Dat TCP oorspronkelijk niet gemaakt is om op gigabitsnelheden met hoge latencies (4ms kun je overigens niet echt als hoog beschouwen) goed te werken, wil niet zeggen dat TCP tegenwoordig daar ook niet mee om kan gaan. Middels window scaling is het prima mogelijk om zelfs 10GBit-pijpen met een paar honderd milliseconde latency te vullen.

Uitgaande van een relatief korte 1Gbit-link met niet al te veel (zwaar belaste) apparatuur tussen de beiden kanten, zal de latency toch echt niet boven de paar milliseconden (ruime schatting) uit moeten komen. Je hebt het dan over TCP-buffers van hooguit een paar honderd kilobyte, wat zover ik weet standaard gewoon moet werken onder moderne Windows-versies.

Het testen van verschillende applicatieprotocollen zal in ieder geval uitsluitsel moeten geven over of het aan TCP zelf of aan de applicatie ligt. Mijn guess is dat het meer aan de applicatie of disk I/O e.d. zal liggen dan aan de link; zo te horen is de TS daar ook al mee aan het tunen geslagen, dus het komt vast goed

[jvanhambelgium]

TrailBlazer schreef op dinsdag 28 augustus 2007 @ 20:25:
Je kan ook nog met sACK (selective ACK) gaan expirimenteren.
FTP'en zal dus ook niet sneller gaan of ieder geval niet schrikbarend.

Of ze kunnen er een stel Riverbed Steelhead dozen tussenzetten
Leuk om te weten dat alles opgelost is, ik had eerlijk gezegd niet gedacht dat het effectief de delay ging zijn ...tja ... 4ms ... heb nooit echt de formule toegespast om de max throughput te bepalen.

En inderdaad als ik tussen 2 PC's met een cross-cable test is de delay vééééél minder als 4ms ... vandaar dat er niet echt een issue is op die manier.

OK...tijd voor 10G WAN linkjes ;-)

[Verwijderd]

Wat ik me heb laten vertellen is dat we de window (misschien praat ik poep, maar werk al bijna 2 weken veels te lang en ben moe) veel groter kunnen zetten, maar dat er dan applicaties kunnen zijn die weinig data nodig hebben. Deze krijgen dan veel langere timeouts dan nodig.

Kan je dat bevestigen?

[serkoon]

Verwijderd schreef op dinsdag 28 augustus 2007 @ 21:39:
Wat ik me heb laten vertellen is dat we de window (misschien praat ik poep, maar werk al bijna 2 weken veels te lang en ben moe) veel groter kunnen zetten, maar dat er dan applicaties kunnen zijn die weinig data nodig hebben. Deze krijgen dan veel langere timeouts dan nodig.

Kan je dat bevestigen?

Zo werkt het niet. TCPs melden aan elkaar het maximale window, dat wil zeggen: het maximaal aantal bytes wat een TCP ontvanger kan bufferen zonder dat het acknowledged is. Zo weet een TCP sender dus hoeveel data er maximaal uitgestuurd mag zijn naar de andere kant. TCPs varieren de windows tijdens het versturen van data als flow-control-methodiek. Wanneer je grote buffers hebt en dus grote maximale windows, wil dat niet zeggen dat de window tijdens datatransfers ook ingesteld zijn op dat maximum. Ook is er geen koppeling tussen het sturen van acknowledgements en het vol raken van deze buffers. Oorspronkelijk stuurden TCPs simpelweg voor elk ontvangen in-order pakket een acknowledgement; tegenwoordig worden middels 'delayed ack' een aantal acknowledgements opgespaard en in een klap een veel groter block geacknowledged (scheelt dataverkeer voor alle acks en scheelt veel werk voor de verwerking ervan aan beide kanten).

Dus kort antwoord: nee, grotere TCP buffers/maximale windows hebben geen negatief effect voor gevallen waarbij weinig data wordt gestuurd.

[Verwijderd]

jvanhambelgium schreef op dinsdag 28 augustus 2007 @ 21:37:
[...]


Of ze kunnen er een stel Riverbed Steelhead dozen tussenzetten
Leuk om te weten dat alles opgelost is, ik had eerlijk gezegd niet gedacht dat het effectief de delay ging zijn ...tja ... 4ms ... heb nooit echt de formule toegespast om de max throughput te bepalen.

En inderdaad als ik tussen 2 PC's met een cross-cable test is de delay vééééél minder als 4ms ... vandaar dat er niet echt een issue is op die manier.

OK...tijd voor 10G WAN linkjes ;-)

het leuke is, over 10g haal je met 1 sessie niks meer. (heb ik me laten vertellen)
Met deze latency, het blijft een burst, dan wachten op de Ack.

[ Voor 4% gewijzigd door Verwijderd op 28-08-2007 22:00 ]

[Verwijderd]

opgelost, dank!

[ Voor 98% gewijzigd door Verwijderd op 04-09-2007 16:57 ]

[needless to say]

Ik zou eerst en vooral, zoals reeds gezegd, beginnen met een UDP-test dmv bvb iperf. Maak maar gerust pakketten aan met een grootte van de MTU van je netwerk. Dan kun je ook mooi uitrekenen wat de efficiëntie is die je haalt. Eens dit een deftige performantie geeft ga je de pakketten verkleinenen om te zien of je switch-hardware het wel aankan. Bij gebruik van Iperf krijg je bij testen op UDP ook gedetailleerde resultaten over veranderingen in delay, packet loss en out-of-order pakketten.

Eens al dit een deftige performantie geeft maar TCP niet moet je pas beginnen met TCP tuning. TCP uiteraard ook weer testen via een testprogramma zoals iperf. Windows heeft standaard veel te kleine TCP windows. Maar de window size moet je eerst uitrekenen via latency x bandbreedte.

Een ander belangrijk gegeven, is dat TCP maar erg weinig tegen packet loss of out-of-order pakketten kan. Sniff eens het verkeer voordat het binnenkomt bij de server (steek er een switch tussen die het verkeer dupliceert naar een testmachine die vervolgens het verkeer analyseert). Kijk naar de trace om te zien of je veel packet loss hebt, en of er geen out-of-order pakketten zitten. Indien je met out-of-order pakketten zit (normaal enkel bij redundante lijnen), zal Iperf dit trouwens ook zeggen bij de UDP-test. Als je met veel loss zit kan je vaak wel aan je maximale capaciteit geraken door veel parallelle TCP-streams op te zetten.

In elk geval, prioriteiten zouden moeten zijn:

1. UDP met grote pakketten
2. UDP met kleine pakketten
3. TCP + TCP-verkeer analyseren
4. testen met meerdere parallelle TCP-streams.

En gebruik een deftig testprogramma zoals iperf.


edit: waarom selecteer je 9000 als MTU? Heb je hier een reden voor? Hou ermee rekening dat de MTU over UTP bvb normaal nooit meer dan 1500 mag zijn. Het is beter om bij het testen kleinere MTUs te gebruiken waarvan je zeker bent dat ze overal door je netwerk geraken. Veel netwerkkaarten droppen elk pakket met een MTU > 1500.

[ Voor 13% gewijzigd door needless to say op 28-08-2007 22:15 ]

[TrailBlazer]

jvanhambelgium schreef op dinsdag 28 augustus 2007 @ 21:37:
[...]


Of ze kunnen er een stel Riverbed Steelhead dozen tussenzetten

je kent mijn menig over die dingen he

Leuk om te weten dat alles opgelost is, ik had eerlijk gezegd niet gedacht dat het effectief de delay ging zijn ...tja ... 4ms ... heb nooit echt de formule toegespast om de max throughput te bepalen.

En inderdaad als ik tussen 2 PC's met een cross-cable test is de delay vééééél minder als 4ms ... vandaar dat er niet echt een issue is op die manier.

OK...tijd voor 10G WAN linkjes ;-)

hebben we al

[TrailBlazer]

serkoon schreef op dinsdag 28 augustus 2007 @ 21:18:
[...]


Dat TCP oorspronkelijk niet gemaakt is om op gigabitsnelheden met hoge latencies (4ms kun je overigens niet echt als hoog beschouwen) goed te werken, wil niet zeggen dat TCP tegenwoordig daar ook niet mee om kan gaan. Middels window scaling is het prima mogelijk om zelfs 10GBit-pijpen met een paar honderd milliseconde latency te vullen.

Uitgaande van een relatief korte 1Gbit-link met niet al te veel (zwaar belaste) apparatuur tussen de beiden kanten, zal de latency toch echt niet boven de paar milliseconden (ruime schatting) uit moeten komen. Je hebt het dan over TCP-buffers van hooguit een paar honderd kilobyte, wat zover ik weet standaard gewoon moet werken onder moderne Windows-versies.

Het testen van verschillende applicatieprotocollen zal in ieder geval uitsluitsel moeten geven over of het aan TCP zelf of aan de applicatie ligt. Mijn guess is dat het meer aan de applicatie of disk I/O e.d. zal liggen dan aan de link; zo te horen is de TS daar ook al mee aan het tunen geslagen, dus het komt vast goed

reken het #$#&#%*&%* dan even uit voordat je begint te blaten. De formule in de link in de TS klopt gewoon. 1 gbit maal een delay van 4 ms is 1E9*4E-3. Uit je hoofd kan je dan uitrekenen dat je bij deze link al een window van een 4mbit nodig hebt. Wil je dan een 10gbit link met een delay van 100ms volpompen heb je een buffer nodig van 1 gbit. Ga jij de server even aanwijzen die dat kan. Sowieso is het volkomen onzin om zo'n buffer te hebben want al raakt slechts een op de miljoen pakketten van 1000 bit kwijt dan kan je overnieuw beginnen.
[arrogant mode on]
Als ik even arrogant over mag komen ik werk ondertussen 7 jaar met WAN netwerken 4 jaar bij een provider en nu bij een bedrijf wat een netwerk heeft met bandbreedtes en apparatuur waar de meeste van jullie alleen maar van kunnen dromen.
Ik ben zowel CCIP als CCSP en ben aan het leren voor mijn CCIE en heb dit verhaal al aan klanten kunnen uitleggen toen de gemiddelde tweaker nog een harde plasser kreeg van een 2mbit internteverbinding.
[arrogant mode off]
sorry dat ik even pissed overkom maar dit verhaal heb ik al zovaak lopen vertellen en in de TS staat het prima uitgelegd. IK mag toch hopen dat we in PNS iets verder denken.

[ Voor 17% gewijzigd door TrailBlazer op 28-08-2007 22:32 ]

[brederodekater]

TrailBlazer schreef op dinsdag 28 augustus 2007 @ 22:23:
[...]

[arrogant mode on]
Als ik even arrogant over mag komen ik werk ondertussen 7 jaar met WAN netwerken 4 jaar bij een provider en nu bij een bedrijf wat een netwerk heeft met bandbreedtes en apparatuur waar de meeste van jullie alleen maar van kunnen dromen.
Ik ben zowel CCIP als CCSP en ben aan het leren voor mijn CCIE en heb dit verhaal al aan klanten kunnen uitleggen toen de gemiddelde tweaker nog een harde plasser kreeg van een 2mbit internteverbinding.
[arrogant mode off]

Rustig aan man, wind je niet zo op. "Arrogantie mode" zou niet nodig moeten zijn lijkt me, ik neem aan dat je hier voor je lol zit?

[TrailBlazer]

brederodekater schreef op woensdag 29 augustus 2007 @ 00:16:
[...]


Rustig aan man, wind je niet zo op. "Arrogantie mode" zou niet nodig moeten zijn lijkt me, ik neem aan dat je hier voor je lol zit?

ja dat zit ik ook wel daar gaat het ook niet om.
Ik erger me er gewoon aan dat er mensen blijven die gewoon maar wat blijven roepen zonder dat ze de moeite lezen om de onafhankelijke bronnen te lezen en te begrrijpen.

[overhyped]

TrailBlazer schreef op woensdag 29 augustus 2007 @ 06:39:
[...]

ja dat zit ik ook wel daar gaat het ook niet om.
Ik erger me er gewoon aan dat er mensen blijven die gewoon maar wat blijven roepen zonder dat ze de moeite lezen om de onafhankelijke bronnen te lezen en te begrrijpen.

Moet even (ondersteundend) om je lachen Zeker op netwerk gebied zijn er een hoop blaters op deze aarde: Mijn internet doet 't thuis dus ik heb verstand van internet. Mijn lan doet 't thuis dus ik weet alles van lans en het kan niet moeilijk zijn:) maar: Goed uitgelegd: Fijn iemand op tweakers.net waar ik 't gevoel van heb op gelijkwaardig niveau cisco mee te kunnen praten

Maar back on topic: TCP is gevoelig voor latency, en SMB dubbel: de EVPN dienst van KPN is hier gevoelig voor (+/- 5 ms delay kan problematisch worden) bij normaal kantoor gebruik merk je het niet: Meerdere sessies = meerdere keren de trage troughput. wanneer je de lijn vol trekt met 1 (smb) sessie: je loopt dan tegen de protocol beperkingen aan.

[serkoon]

TrailBlazer schreef op dinsdag 28 augustus 2007 @ 22:23:
reken het #$#&#%*&%* dan even uit voordat je begint te blaten. De formule in de link in de TS klopt gewoon. 1 gbit maal een delay van 4 ms is 1E9*4E-3. Uit je hoofd kan je dan uitrekenen dat je bij deze link al een window van een 4mbit nodig hebt. Wil je dan een 10gbit link met een delay van 100ms volpompen heb je een buffer nodig van 1 gbit. Ga jij de server even aanwijzen die dat kan.

*kuch*. Ik zeg dus letterlijk 'paar honderd kilobyte' voor 4ms op 1Gbit/s. 4mbit =~ 'paar honderd kilobyte'.

Verder:

code:

# sysctl net.inet.tcp.recvspace
net.inet.tcp.recvspace: 67108864

Standaard FreeBSD-bak met 64MB grote receive buffer. Goed, 100ms op 10Gbit is wel wat veel voor een enkele TCP-stream, omdat je, zoals je zegt, dan 100MByte kwijt bent aan een buffer voor slechts een verbinding. Aangezien we tegenwoordig toch al richting >4Gbyte aan RAM gaan voor standaard servertjes, valt dat overigens steeds meer mee.

Sowieso is het volkomen onzin om zo'n buffer te hebben want al raakt slechts een op de miljoen pakketten van 1000 bit kwijt dan kan je overnieuw beginnen.

Dat is inderdaad het nadeel van dat soort pijpen, waar ook onderhand een aantal redelijk werkende oplossingen voor zijn, zoals bijvoorbeeld SACK.

Eerlijk gezegd snap ik je frustratie en je arrogantie-mode dus niet bepaald, aangezien jouw berekening precies uitkomt op wat ik zeg en dit soort windows gewoon standaard werken onder moderne OS'en en dus ook helemaal niet zo bijzonder zijn. Zie ook bijvoorbeeld http://proj.sunet.se/LSR2/, waar men met windows van 150MB werkte om een snelheid van 4.5Gbit/s te halen op een verbinding met plus-minus 270ms latency. (Een nieuwer record is overigens http://data-reservoir.adm.s.u-tokyo.ac.jp/lsr-20060219/, waar 8.8GBit/s gehaald is met een latency van 500ms)

[ Voor 3% gewijzigd door serkoon op 29-08-2007 23:39 ]

[kwiebus]

jvanhambelgium schreef op dinsdag 28 augustus 2007 @ 07:24:
zelfs "out-of-the-box" zal elk Windows product meer als 50 megabits / sec neerzetten !!! Zonder enige tuning of tweaking.

Dat is niet per definitie waar. Kopieren via de Windows Explorer kan wel degelijk traag verlopen zoals ik onlangs merkte bij het kopieren van een paar vmware images:

Slow network performance occurs if you copy files to a domain controller that is running Windows 2000 or Windows Server 2003

[jvanhambelgium]

kwiebus schreef op donderdag 30 augustus 2007 @ 00:24:
[...]


Dat is niet per definitie waar. Kopieren via de Windows Explorer kan wel degelijk traag verlopen zoals ik onlangs merkte bij het kopieren van een paar vmware images:

Slow network performance occurs if you copy files to a domain controller that is running Windows 2000 or Windows Server 2003

Hmm, ok...met dat produkt KAN je blijkbaar per definitie soms zo'n dingen wel verwachten
Ik heb heb thans nooit mogen ervaren met de verschillende versies die door elkaar gebruikt werden.

Gelukkig staat dat allemaal wat deftig beschreven...