Jumbo Frames -> MTU 9000

[m4v3r1ck]

Hallo Maccers,

Onderstaand mijn instellingen voor het gebruik van JF MTU 9000 i.c.m. Link Aggregation alles bekabeld met CAT6a UTP.

1. OS X Netwerk Instellingen:





2. HP-1810-G (managed switch)



TOEGEVOEGD n.a.v. opmerking @Ben(V) <- Bedankt!



3. DSM 5.1 instellingen Link Aggregation met MTU 9000







4. Het m.i. tegenvallende resultaat! 

MP 5.1 (2012)
OSX 10.10.2 (14C1514)

File: 48.3 GB .iso
Programma: Forklift

File gekopieerd van een interne MAC_RAID0 naar de NAS via (Passive) FTP:



Heb ik iets gemist qua instellingen?

Uiteraard na alle instellingen te hebben ingevoerd, alle hardware herstart. Iemand nog andere suggesties? Wat zou theoretisch überhaupt het maximaal haalbare zijn?

Bedankt alvast!

Fijne dag 

[Pippin]

Ben geen Maccer maar,
"Het m.i. tegenvallende resultaat!"
impliceert een bepaalde verwachting
Om geMaccer te voorkomen zou het beter zijn Windows aan te schaffen

Alle gekheid op een stokje, heb je een vergelijking met hoe het was?
Het enige wat ik zie in de grafiek is fluctuatie.
Of is dat wat je bedoelt?

Denk dat het beter is een MAC programmatje te gebruiken om de snelheid te meten.
Dat grafiekje van DSM zie je niet zo veel aan.

[Briolet]

Off-topic:

Ik zie helemaal geen plaatjes. Als ik de tekst open in edit mode (moderator privilege)  dan zie ik wel correcte linken. Wat is hier aan de hand?

Als ik de link in een nieuw browser window plak, zie ik het plaatje wel, dus de link klopt.

Edit: Dit was met Safari. Als ik deze pagina met Firefox open, zie ik de plaatjes wel. ra-ra.

Is dat een beveiliging van safari omdat het hier mixed content betreft: de plaatjes staan op een https link?

[Ben(V)]

Tegenvallend is hooguit ten opzichte van je verwachtingen.
Een LACP verhoogt de maximale snelheid  namelijk niet, alleen de bandbreedte.

Een enkele connectie (client <--> server) ofwel mac naar NAS maakt maar gebruikt van een van de twee netwerk verbindingen.
Wel houd je nog een verbinding over met dezelfde capaciteit om ander werk te doen.

Dus als je de echte capaciteit wilt testen zul je dat met twee clients gelijktijdig moeten doen.

Bij mij verhogen jumbo frames de snelheid niet. Integendeel het heeft juist een verlagend effect.
Anderen hebben wel voordeel geconstateerd, met name mac gebruikers.

PS Al je instellingen zijn prima in orde, al mis ik een plaatje van je switch waar je de trunk gemaakt hebt.

[Briolet]

Met Jumbo frames zul je niet meer dan 10% snelheidswinst boeken. Dat effect zie je ook niet in zo'n fluctuerende grafiek.

Ik dacht dat het effect van Jumbo frames het grootst is op zwaar belaste netwerken waar de switches dan minder pakketten te bewerken hebben.

[Birdy]

Wat laat

Code: [Selecteer]

ping -D -s 8150 <IP-NAS>" zien vanaf je MAC ?

[Ben(V)]

Met Jumbo frames zul je niet meer dan 10% snelheidswinst boeken. Dat effect zie je ook niet in zo'n fluctuerende grafiek.

Ik dacht dat het effect van Jumbo frames het grootst is op zwaar belaste netwerken waar de switches dan minder pakketten te bewerken hebben.

Jumbo frames hebben eigenlijk alleen een voordeel als er ergens in de keten een device de pakketjes niet snel genoeg kan afhandelen.
Voor elk jumbo frame moeten er 6 pakketjes van standaard afmetingen verstuurt worden, wat in totaal 190 bytes extra is op 9038 bytes van een jumbo frame pakket.
Dat is een overhead van 2%

Als er meer dan 2% voordeel uit een jumbo frame setting haalt, is er in de keten een device die te langzaam is om alle pakketjes tijdig af te handelen.

[Erwin1]

Vanuit Synology wordt aangeraden om jumbo op automatisch te laten staan, devices kijken toch wat de maximale doorvoer snelheid is.

Daarnaast zou je eens kunnen proberen om via een ander protocool te werken, afp is het meeste geschikt voor de NAS.

[Ben(V)]

Jumbo frames kun je helemaal niet op automatisch zetten.
Afp is alleen het beste voor de mac, voor de Nas maakt het momenteel niet uit.
Vanaf DSM 5.2 zal smb de betere keuze zijn als de client ook smb 3 ondersteund

[Briolet]

Wat laat

Code: [Selecteer]

ping -D -s 8150 <IP-NAS>" zien vanaf je MAC ?

Ik heb mijn nas laatst op 2000 MTU gezet. Daar gaat toch iets mis in mijn nas, want:

Code: [Selecteer]

Briolet ping -D -s 1477 10.0.1.40
PING 10.0.1.40 (DS 415): 1477 data bytes
1485 bytes from 10.0.1.40: icmp_seq=0 ttl=64 time=0.482 ms
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3

Bij 1 byte minder gaat het wel goed en dat is de hoogste waarde die ik voor de reguliere 1500 MTU mag gebruiken. Het lijkt erop dat ondanks de 2000 MTU instelling, nog gewoon 1500 MTU gebruikt wordt.
Vroeger onder dsm 4.x kon ik gewoon de hoge waardes pingen die bij 9000 MTU behoren. Ik had al problemen bij 9000 MTU dus blijkbaar gaat er iets mis in mijn configuratie.
Het ligt ook niet aan de switch, want als ik mijn andere mac ping gaat het wel goed (al mijn macs staan al jaren op 9000 MTU):

Code: [Selecteer]

Briolet$ ping -D -s 8150 10.0.1.22
PING 10.0.1.22 (iMac): 8150 data bytes
8158 bytes from 10.0.1.22: icmp_seq=0 ttl=64 time=0.619 ms
8158 bytes from 10.0.1.22: icmp_seq=1 ttl=64 time=0.575 ms
8158 bytes from 10.0.1.22: icmp_seq=2 ttl=64 time=0.599 ms


[Pippin]

Wat laat ifconfig voor MTU waarden zien?

[Ben(V)]

Een standaard configuratie met een mtu van 1500 kan met ping een maximale data size van 1472 aan, want er komt 20 bytes bij voor de IP header en 8 bytes voor de ICMP header.

Als je andere waarden voor mtu instelt moeten alle device in het netwerkpad die mtu ondersteunen.
Afhankelijk van de implementatie van die devices zullen ze als dat niet matched ofwel de pakketjes rejecten ofwel terugvallen op de standaard mtu van 1500.
De NAS valt naar mtu 1500 terug en ik vermoed je mac's ook.
Als je de mac's dus een mtu van 9000 geeft en je Nas van 2000 matched het niet en vallen ze terug naar 1500.

[Briolet]

Het moet toch een bug in de NAS geweest zijn vanwege mijn gebruik van een Wifi Accesspoint die ergens in LAN1 geïntegreerd is. (Hoewel Synology dat nergens expliciet vermeld)

Ik heb net de accesspointmode omgezet in een wifi-routermode. Dan kan ik wel een bond maken van mijn beide LAN-poorten en  Jumboframes op deze bond instellen. Ik heb 4000 MTU ingesteld en kan nu wel probleemloos een groot pakket pingen:

Code: [Selecteer]

Briolet$ ping -D -s 3000 10.0.1.30
PING 10.0.1.30 (DS 415 in bond)): 3000 data bytes
3008 bytes from 10.0.1.30: icmp_seq=0 ttl=64 time=0.319 ms
3008 bytes from 10.0.1.30: icmp_seq=1 ttl=64 time=0.307 ms
3008 bytes from 10.0.1.30: icmp_seq=2 ttl=64 time=0.297 ms
3008 bytes from 10.0.1.30: icmp_seq=3 ttl=64 time=0.319 ms
…


[Erwin1]

Jumbo frames kun je helemaal niet op automatisch zetten.
Afp is alleen het beste voor de mac, voor de Nas maakt het momenteel niet uit.
Vanaf DSM 5.2 zal smb de betere keuze zijn als de client ook smb 3 ondersteund

Mmm niet helemaal tactisch uitgelegd van me.
Vanuit Synolgy wordt aangeraden jumbo frames uit te laten staan, dan schakelt de nas zelf kennelijk.
En in combinatie met een Mac is AFP toch het smb protocol voor Mac? Zelf ervaar ik daarmee het meest pistier resultaat.

[Ben(V)]

Wat Synology bedoelt is dat je jumbo frames beter uit kunt laten omdat als er een device in de keten zit dat geen jumbo frames ondersteund je helemaal geen verbinding meer krijgt.

AFP en en SMB zijn twee verschillende protocollen, dus AFP is niet het SMB protocol voor de mac.
AFP is door Apple ontwikkelt en SMB (ook wel CIFS genoemd) door Microsoft.
Een mac kan ook met SMB werken.

Vroeger werkte de mac (net als alle unix varianten inclusief Synology) met een Samba implementatie van het smb protocol, maar toen Samba zijn opensource policy aanscherpte (meer open maakte) heeft Apple een eigen SMB implementatie geschreven die kwalitatief een stuk slechter was.
Inmiddels is het na vele versies en patches wel weer een redelijk goede implementatie en is het volgens Apple nu het preferred protocol.
Ik vermoed dus dat ook Apple met SMB 3 bezig is en in de toekomst AFP laten vallen.