Bericht door: Heppieboeddah op 21 april 2015, 16:48:12
In mij netwerk hangt alles aan een Gigabit bedrading. De Nic, de router, de switch. Alle apparaten ondersteunen Jumbo Frames.
Alles stond/staat ingesteld op Jumbo frames MTU 9000. Dat werkte prima en leverde binnen mijn netwerk een winst op van 30%.
Na de update van de DSM naar 5.2 bèta, stond de Jumbo frames op de NAS op 2000. Die veranderd naar 9000. Opgeslagen.
Vreemd is nu dat als ik de NAS benader via het interne ipadres 192.168.1.131:5000 er op geen enkele manier te verbinden is. Kom niet eens in het inlogscherm.!
Als ik hetzelfde doe op mijn tablet via de WiFi dan kan ik wel inloggen?! Pc en Tablet, NAS zitten in hetzelfde netwerk en subnet.
Verlaag ik nu de MTU op de NAS naar 2000, dan kan ik zowel via de pc en het tablet inloggen!
Waar gaat het fout? Of is het een bug?
Bericht door: Briolet op 21 april 2015, 17:01:32
Bericht door: Heppieboeddah op 21 april 2015, 17:18:22
Bericht door: Ben(V) op 21 april 2015, 20:45:13
Bericht door: Heppieboeddah op 21 april 2015, 21:29:02
Bericht door: m4v3r1ck op 23 april 2015, 15:38:12
Met name de volgorde van instellen.
Dank alvast!
Bericht door: Birdy op 23 april 2015, 15:43:15
Bericht door: m4v3r1ck op 23 april 2015, 16:15:46
Zal terugmelden welke volgorde en dat het natuurlijk (hopelijk) werkt! ;-)
Bericht door: Birdy op 23 april 2015, 16:27:12
Bericht door: Heppieboeddah op 23 april 2015, 16:28:03
Zou mij ook de juiste richting opduwen
Bericht door: Pippin op 23 april 2015, 16:41:59
/etc/synoinfo.conf
/etc.defaults/synoinfo.conf
Voeg/pas, aan de volgende regel toe > bond0_mtu= <
onder de regel eth0_mtu= en eth1_mtu=
Daarna NAS herstarten.
Bericht door: Ben(V) op 23 april 2015, 16:49:07
Bericht door: Pippin op 23 april 2015, 16:54:53
In 5.2 kan het dus? Wist ik niet, op 5.1 gaat het niet, althans bij mij.
Bericht door: Pippin op 23 april 2015, 17:17:50
Bericht door: Heppieboeddah op 23 april 2015, 19:15:07
Laat staan met bonding.
Intern via UTP is de NAS niet bereikbaar indien ik de MTU op 9000 zet. Maakt gewoon geen verbinding
Extern en over Wifi is het geen probleem, maar dan heb je toch niet veel aan Jumbo-frames. Heb begrepen dat dat niet werkt.
Maar goed, misschien dat het met bonding wel werkt.... :evil:
Bericht door: m4v3r1ck op 23 april 2015, 22:41:39
Je hebt toendertijd ook nog reacties geplaatst in die Topic ;D
Mijn geheugen laat me in de steek? ;-)
Bericht door: Heppieboeddah op 01 mei 2015, 14:24:51
Na diverse Teamviewer sessies, kabels omzetten, verschillende manieren van aan sluiten van de NAS, zelfs rechtstreekse utp van NAS naar PC etc etc... Geen resultaat. Op het moment dat de MTU op de NAS hoger ingesteld wordt dan MTU 3000 is de NAS onbereikbaar en dus ook niet te pingen.
Men wil nu mijn sys-config backuppen en bij hun weer op een NAS terugzetten om te kijken of ze aldaar het issue kunnen reproduceren.
Blijft voorlopig jammer dat de NAS die MTU 9000 niet vreet. Zoals eerder gezegd is mijn winst met Jumboframes bijna geminimaliseerrd
Bericht door: Ben(V) op 01 mei 2015, 14:35:44
Als je een mtu van 9000 zou hebben scheelt dat per pakketje van 9000 byte maar 190 bytes ten opzichte van een standaard mtu van 1500.
Dat is maar 2%.
Bericht door: Heppieboeddah op 01 mei 2015, 15:56:37
Dat is 35% winst, mag jij gerust gering noemen. Hoop niet dat je kwalijk neemt dat ik dat wel veel winst noem.
Bericht door: Ben(V) op 01 mei 2015, 16:45:01
Echter het voordeel komt dan ergens anders vandaan dan van de jumbo frame afmetingen.
Een standaard frame heeft een mtu van 1500 waarvoor 1538 byte getransporteerd moeten worden.
Voor een jumbo frame met een mtu van 9000 worden 9038 bytes getransporteerd.
Om dezelfde data te kunnen versturen met een mtu van 1500 moeten er dus 6 frames verstuurd worden ( 6x 1500 = 9000)
Er moeten dan dus 1538 x 6 = 9228 bytes verstuurd worden terwijl een mtu van 9000 maar 9038 bytes nodig heeft.
Het verschil is 9228 - 9038 = 190 bytes ofwel ongeveer 2% van 9000.
Als je dus meer voordeel uit jumbo frames haalt betekent dat gewoon dat er ergens in de keten hardware zit die moeite heeft met het verwerken van meer packages.
Meestal is de instelling van de netwerkkaart in je pc of mac de plek waar je het voordeel echt kunt halen.
Hieronder een plaatje hoe de frames zijn opgebouw om mijn berekeing te onderbouwen.
[attachimg=1]
Bericht door: Heppieboeddah op 01 mei 2015, 16:50:46
Bericht door: Ben(V) op 01 mei 2015, 17:06:16
Meer pakketjes betekent ook meer werk om uit te pakken.
Vaak zijn met name de netwerkkaarten in PC (mac's weet ik niet maar zal ook wel) niet goed geconfigureerd of zijn gewoon matig van kwaliteit.
Ik heb eens een PC gehad die een netwerksnelheids boost van 40% kreeg toen ik er een simpel intel netwerkkaartje in stopte in plaats van de onboard nic te gebruiken.
Maar dingen als alle optimalisaties in de drivers uitzetten en vooral xon/xoff uitzetten helpt vaak enorm.
Die optimalisatie stammen uit de tijd dat de cpu werk uit de hand genomen moest worden, maar de huidige cpu's in pc's zijn vele malen krachtiger dan de hardware van die netwerk interface zodat je dat beter door de cpu kunt laten doen.
Bericht door: Heppieboeddah op 01 mei 2015, 17:56:35
De winst welke ik Had gemaakt van zo n 30% werd behaald bij het instellen van de Jumbo frames in DSM 5.1.
Waar de drop vandaan komt is denk obvious. Bij Synology denken ze er ook zo over kennelijk, alleen kunnen ze het niet/nog niet tackelen.
Bericht door: Ben(V) op 01 mei 2015, 18:10:27
Alleenkan 30% nooit door jumbo frames komen.
Synology doet ook geen uitspraak over de snelheid, alleen over het feit dat jumbo frames bij jou niet meer werken.
Bericht door: Pippin op 01 mei 2015, 18:18:00
Wat jij zegt echter ook. Het probleem is dat na die update JF niet goed meer werkt op de DS.
Wat hij bedoelt is dat er kans is dat er een ander apparaat, zonder JF ingesteld, zijn werk niet goed doet.
Jouw oplossing was/is JF gebruiken waardoor het apparaat niet zoveel meer hoeft te verwerken door de pakketgrootte.
Bericht door: Heppieboeddah op 01 mei 2015, 18:33:52
Nergens heb ik het erover gehad dat Synology maar iets over de snelheid welke te behalen zou zijn heeft gezegd. Die vloeien voort uit empirisch onderzoek mijnerzijds
Het enige wat zij ook vreemd vinden is dat na het verhogen van de MTU naar 4000 of hoger, max 9000, de NAS niet meer intern benaderbaar is. Dat het in mijn apparatuur of netwerk zou zitten hadden we na enkele sessies Teamviewer en hardware matige tests al behoorlijk kort gesloten
Bericht door: Briolet op 01 mei 2015, 18:52:26
Het enige wat zij ook vreemd vinden is dat na het verhogen van de MTU naar 4000 of hoger, max 9000, de NAS niet meer intern benaderbaar is.
Ik zou gokken dat het ook in switches of de switch van de router kan liggen die de grotere pakketten niet aankan. Op windows kun je eens een groot pakket via de commandline versturen:
Code: [Selecteer]
ping -l 8150 -f ServerIPDit stuurt een groot pakket met de eis dat er niet gefragmenteerd mag worden. Die moet goed overkomen bij goed werkende JF
Dat het extern wel lukt komt doordat internet verkeer dan weer naar 1500 MTU terugschakelt.
Bericht door: Heppieboeddah op 01 mei 2015, 19:37:01
Ook ik heb die ping gedaan al voordat ik contact met Synology had opgenomen. Het resultaat wat dat alles naar behoren werkte behalve de ping Request naar de NAS bij 4000 of hoger. Echo: Request time out
De switch is een managed Netgear met ondersteuning Jumbo Frames. Zelfs alle andere poorten op de switch zijn getest. Allemaal met hetzelfde resultaat. Geen connectie met de NAS bij 4000 of hoger.
Bericht door: Ben(V) op 01 mei 2015, 19:42:43
Anders had hij de melding gegeven dat dat hij wil fragmenteren maar dat niet kan omdat het df bit gezet is.
Jouw melding krijg je ook als je verzendende device een mtu heeft die kleiner is dan het pakketje dat je wilt pingen.
Bericht door: Heppieboeddah op 01 mei 2015, 19:46:52
Bericht door: Ben(V) op 01 mei 2015, 19:52:30
Als het zendende device of een device tussen zender en ontvanger de oorzaak is dan krijg je een melding als "not reachable".
Als de ontvanger (hier de Nas dus) een verkeerde mtu heeft dan krijg je de melding dat hij het pakket wil fragmenteren maar dat niet kan omdat het df bit gezet is.
Bericht door: Heppieboeddah op 01 mei 2015, 20:28:09
De DS heeft ook al zonder tussenkomst van wat dan rechtstreeks aan de Nic gehangen ook daar zodra de MTU de 3000 overstijgt, kapt de NAS ermee. Hoe duidelijker wil je het hebben? Wat zou er nu nog tussen kunnen zitten dat een hogere MTU blokkeert.
Bericht door: Ben(V) op 01 mei 2015, 20:54:24
Als het je NAS was zou je een andere melding krijgen.
Download deze tools eens naar je PC die kan analyseren waar het zit.
http://www.iea-software.com/products/mtupath.cfm
Dit is het laatste wat ik er over zeg want blijkbaar stel je hulp niet op prijs gezien je toon.
Bericht door: Heppieboeddah op 01 mei 2015, 21:56:42
NAS:
IN RANGE: 1~2976
SCAN TIMEOUT: 2977~9170
EXCEDED: 9171~16384.
Alle ander apparaten gaan tot de range 1~9170.
Je kan mijn antwoorden misschien niet op prijs stellen. Maar alles wat ik al heb aangegeven wordt door jou in twijfel getrokken, en dat doet mij de tenen krommen
Tevens ga je volledig bij aan het feit dat deze situatie in ontstaan pas na installatie Bèta 5.2 en het bij 5.1 allemaal keurig netjes werkte. Een causaal verband met de update lijkt mij meer voor de hand liggen tot al het andere. Kennelijk komt Synology ook tot die conclusie en zal zoals ik eerder schreef het proberen te tackelen.
Bericht door: Briolet op 02 mei 2015, 20:27:28
Zal een melding maken via bugreport. Maar misschien dat iemand het kan bevestigen.
Ik heb vandaag dsm 5.2 geïnstalleerd en een paar snelheidstesten gedaan.
apparatuur:DS 415+, iMac (late 2009), netgear SG108 switch
Onder DSM5.1 een bond met fail over, onder DSM 5.2 een bond met load balancing
test programma "Helios lan tester" met de default settings
Ik heb ook naar de Jumbo frames gekeken, maar zag geen problemen onder DSM 5.2. Dit deed het gewoon goed hoewel ik geen significant verschil kon meten met de standaard frames. IMAP heeft hier problemen mee zodat JF voor mij nog steeds geen optie is.
Ik heb ook de nieuwe SMB3 geactiveerd. Hiermee kon ik geen verschil meten t.o.v SMB2
Met afp zag ik tussen de DSM versies wel een verbetering in read snelheid, maar niet in schrijfsnelheid. Dat vind ik vreemd omdat bij alle testen Security Station aan stond en er constant 5 cameras naar de nas streamden. Dan zou ik juist verwachten dat de write snelheid een voordeel zou hebben van de nieuw load balancing optie bij een bond.
Bericht door: Ben(V) op 02 mei 2015, 20:57:14
Als je dus een ook een client met smb 3 hebt en twee netwerkkaarten in een bond (net als de NAS), dan kun je effectief van beide netwerkpaden gebruik maken en het je dus effectief 2Gb tussen client en Nas tot je beschikking.
Met smb 2 was dat beperkt tot 1Gb zelf in deze configuratie.
Bericht door: Babylonia op 20 augustus 2015, 14:57:49
Download deze tools eens naar je PC die kan analyseren waar het zit.
http://www.iea-software.com/products/mtupath.cfm
Ik ben ook wat aan het experimenteren met MTU / Jumbo frames met een nieuwe DS415+ opstelling (DSM 5.2).
(Nog) niet met dubbel aangesloten netwerkkabels. (Heeft in mijn situatie ook niet zoveel zin).
Op welke waarde ik de NAS of de netwerkkaart van de PC ook ingesteld heb (dus ook bij uitgeschakelde Jumbo Frames), de test geeft telkens hetzelfde resultaat als zijnde:
MTU path scan to (mijn lokale NAS IP), ttl=64, limit ttl=48
#16 processing - best MSS 4009 <estimated MTU 4037> [p???ppppp?p?p???]
#1 MSS IN RANGE 1 <== 4008 ==> 4009
#2 SCAN FAILLURE 4010 <== 12374 ==> 16384
Daarmee zou ik denken dat de maximale MTU dan 4000 is.
Dat zou dan kunnen liggen aan de op het moederbord geïntegreerde 1 Gigabit netwerkkaart.
Ik kan geen informatie vinden over de maximale MTU-waarde m.b.t. de Intel 82579V
Wel dat de Intel ethernet controller Jumbo Frames ondersteunt.
http://ark.intel.com/nl/products/52963/Intel-82579V-Gigabit-Ethernet-PHY
Gezien de inmiddels al wat gedateerde Intel netwerkcontroller denk ik dat die 4000 realistisch is.
(In Windows 8 kan ik kiezen tussen een MTU van 4000 en 9000, of uitschakelen).
Met er tussen aangesloten een unmanaged switch (http://www.dlink.com/nl/nl/home-solutions/connect/switches/go-sw-8g-8-port-gigabit-dlinkgo-switch), als specificatie een max. voor Jumbo Frames van 9,216 Bytes.
Specificatie van de modem/router is mij niet bekend, maar PC en NAS hangen aan de switch.
Een test via de command line:
Voor Windows
Code: [Selecteer]
ping -f -l 8150 "myLocalIP"Hier betekent -f : don't fragment en -l 8150 de geteste pakket grootte......ongeacht de eerder ingestelde MTU's (niet, een lage waarde of maximum),
pakket groottes ingesteld boven 1472 worden gefragmenteerd.
"Packet needs to be fragmented but DF set"
Ook een vast IP-adres in de PC + NAS ingesteld, en rechtstreeks met een netwerkkabel verbonden, maakt niets uit.
Is het maximum dan 1500 of toch datgene wat dat test tooltje (http://www.iea-software.com/products/mtupath.cfm) aangeeft waar Ben(V) aan refereert,
zijnde een MTU / Jumbo frames van maximaal 4000 ???
Bericht door: Ben(V) op 20 augustus 2015, 16:12:19
Als je alleen in de NAS de mtu hebt aangezet dan default die naar een mtu van 4000, die moet je dan wel veranderen naar 9000.
Ik heb zelf ook een pc met een 82579V netwerk chip op het moederboard en die kan wel een mtu van 9000 aan.
Ik weet niet meer welke driver ik had draaien die van windows of die van intel maar een van die twee gaf me niet de mogelijkheid om de mtu te zetten.
Misschien dus even kijken of je de driver kunt updaten.
http://www.intel.com/p/en_US/support/detect?iid=dc_iduu
PS Verwacht niet te veel van de voordelen van een hoge mtu, bij mij ging de performance alleen maar achteruit.
Bericht door: Babylonia op 20 augustus 2015, 19:42:31
(alles was in orde), maar tests zoals eerder beschreven via de DOS-box bleven hetzelfde.
Praktisch gezien of ik nu MTU 9000 gebruikte of "disabled", de benadering van de NAS werkte op beide instellingen hetzelfde. (Moest wel PC en NAS + switch echt allemaal een keer herstarten om de NAS in het netwerk van de PC terug te zien).
Ik heb ook nog wat filmbestanden van 1,5 GB overgezet van PC naar NAS, maar merkte eigenlijk geen verschil.
Nou ja, misschien heel misschien een paar tienden MB/ps "strakker" in performance met MTU 9000 ??
In ieder geval niet iets om je er druk over te maken.
Overzetten van zo'n filmbestand ging met circa 112 MB/ps
Dat benadert ongeveer de maximum snelheid van een 1 Gb netwerkverbinding (minus wat overhead).
Als ik nu de prestaties van de DS415+ op de Synology website kijk (https://www.synology.com/nl-nl/products/performance#4_bay), is dat precies de nominale waarde die zij opgeven. :D
Dus de NAS werkt precies zoals verwacht. (Mooi ook dat Synology eerlijk is in hun opgave).
De snelheid van een kleine portable USB 3.0 disk achter een WD TV Live was circa 10x trager.
(MTU op 9000 of disabled maakte niet uit). Dan is de NAS toch beter in rendement. :D
Bedankt in ieder geval voor alle aanvullende zaken.