LACP

[dirklammers]

Omdat ik toch nog wat UTP-tjes richting de NAS had liggen deze eens met alle vier de netwerkpoorten aangesloten.
Uiteraard de managed switch ook ingesteld voor LACP.
Maar is het dan logisch dat 3 van de 4 poorten op MTU 9000 staan en de vierde op 1500 ?

[Pippin]

Controleren met

Code: [Selecteer]

ifconfigin PuTTY...

[Ben(V)]

Het is zo wie zo niet verstandig om jumbo frames aan te zetten maar met een LACP al helemaal niet.
Gewoon een standaard frame (1500 mtu) gebruiken voor al je verbindingen is altijd aan te raden.

De overhead die jumboframes met zich mee brengt weegt niet op tegen die paar bytes die je uitspaart en de potentiele problemen zijn groot.

Waarschijnlijk loop je al tegen zo'n probleem aan en probeert DSM dat op te lossen door voor een poort de mtu terug te schakelen, omdat je switch poort iets anders wil.
Welke switch gebruikt?

[dirklammers]

Oké, weer wat geleerd dus. Altijd gedacht dat een hogere MTU de doorvoersnelheid verbeterde en dus per definitie gunstig was.
Nu staat alles op 4 X 1500 MTU. De switch die ik gebruik is een TP-Link TL-SG2216; zie afbeelding.
Geen idee of de snelheidswinst in mijn omgeving merkbaar is hoor bij 4 LAN-poorten. Ik heb het meer ingesteld omdat het technisch kan dan omdat het perse moet.

Dirk

[Hofstede]

De verbinding wordt ook niet sneller, blijft maximaal 1 Gb. Alleen kan de NAS nu verbindingen opbouwen via verschillende poorten, dus zijn netwerkbelasting verdelen.
Het echte voordeel van LACP merk je dus alleen als je meerdere zware gebruikers hebt.

[Briolet]

…Altijd gedacht dat een hogere MTU de doorvoersnelheid verbeterde en dus per definitie gunstig was.…

MTU is alleen de blok grootte van een datapakket. De data doorvoer wordt niet groter, maar je bespaart op een paar headers omdat je dat data via minder blokken verstuurt. Dat scheelt maximaal 10%.

Als je echter een minder goede verbinding hebt, heb je bij 10x zo grote datablokken ook een 10x zo grote kans op corrupe blokken waardoor dat hele blok, wat nu ook 10x zo groot is, opnieuw verzonden moet worden. Je snelheid kan dan juist snel instorten.

--- 

Mijn eigen ervaring met Jumbo Frames is dat alles er perfect mee werkte en de filetransfer inderdaad iets sneller werd. Echter IMAP werkte niet meer betrouwbaar. Mijn mail programma had moeite te communiceren met de mailserver. Iets in de mailserver op de nas, of bij Apple mail, kon niet goed met die grote datablokken overweg.
Na een paar maand JumboFrames, was het probleem met IMAP de reden om weer naar 1500 MTU terug te gaan.

[Birdy]

Hier het verhaal van @Briolet 

[Ben(V)]

Een enkel jumbo frame transmit ongeveer evenveel data als 6 normale frames en heb je dus 5x de header overhead meer.
Dat komt op 6 frames ongeveer op 190 bytes overhead.
Dat is dus maximaal 3% verschil in het voordeel van de jumbo frames.

Vroeger had het meer impact omdat het uitpakken en samenvoegen van de data in de frames ook cpu power kost en als dat weinig beschikbaar is wordt alles trager, maar de tegenwoordig beschikbare cpu capaciteit lacht daar om.

Echter als er ergens in de keten geen jumboframes ondersteund worden dan wordt van elk package alleen het eerste frame geaccepteerd en moet de rest opnieuw verstuurd worden wat een enorme teruggang in throughput met zich meebreng.
Als je pech heb gebeurd dat helemaal niet en worden gewoon alle packages rejected.

Hetzelfde gebeurd als er een bit onderweg omvalt, dan moet het hele jumbo frame opnieuw verstuurd worden in plaats van het enkele 1500 bytes frame.