Synology-Forum.nl
OS Specifieke ondersteuning => Mac OS X => Topic gestart door: m4v3r1ck op 29 april 2015, 14:24:42
-
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:
(https://dl.dropboxusercontent.com/u/137518766/Synology/ScreenCap%202015-04-29%20at%2013.48.47.jpg)
(https://dl.dropboxusercontent.com/u/137518766/Synology/ScreenCap%202015-04-29%20at%2013.48.52.jpg)
2. HP-1810-G (managed switch)
(https://dl.dropboxusercontent.com/u/137518766/Synology/ScreenCap%202015-04-29%20at%2013.50.17.jpg)
TOEGEVOEGD n.a.v. opmerking @Ben(V) <- Bedankt!
(https://dl.dropboxusercontent.com/u/137518766/Synology/ScreenCap%202015-04-30%20at%2011.37.06.jpg)
3. DSM 5.1 instellingen Link Aggregation met MTU 9000
(https://dl.dropboxusercontent.com/u/137518766/Synology/ScreenCap%202015-04-29%20at%2013.53.09.jpg)
(https://dl.dropboxusercontent.com/u/137518766/Synology/ScreenCap%202015-04-29%20at%2013.53.22.jpg)
(https://dl.dropboxusercontent.com/u/137518766/Synology/ScreenCap%202015-04-29%20at%2013.52.28.jpg)
4. Het m.i. tegenvallende resultaat! :(
MP 5.1 (2012)
OSX 10.10.2 (14C1514)
File: 48.3 GB .iso
Programma: Forklift (http://www.binarynights.com/forklift/)
File gekopieerd van een interne MAC_RAID0 naar de NAS via (Passive) FTP:
(https://dl.dropboxusercontent.com/u/137518766/Synology/ScreenCap%202015-04-29%20at%2002.44.49.jpg)
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 8)
-
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 ;D 8)
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.
-
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?
-
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.
-
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.
-
Wat laat
ping -D -s 8150 <IP-NAS>" zien vanaf je MAC ?
-
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.
-
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.
-
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
-
Wat laat 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:
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):
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
-
Wat laat ifconfig voor MTU waarden zien?
-
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.
-
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:
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
…
-
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.
-
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.
-
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 ;D 8)
LOL! ;D
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?
Omdat het een 48.3 GB .iso file is, zou ik een veel constantere upload naar de NAS verwachten idd.
Denk dat het beter is een MAC programmaatje te gebruiken om de snelheid te meten. Dat grafiekje van DSM zie je niet zo veel aan.
Ik zal eens kijken op MacUpdate en dan vergelijken met de grafiek van DSM, bedankt!
-
Is dat een beveiliging van safari omdat het hier mixed content betreft: de plaatjes staan op een https link?
Het zijn DropBox gekopieerde links, dus idd httpS.
https://dl.dropboxusercontent.com
-
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.
Ik zal tegelijkertijd met dezelfde file ook vanaf mijn Windows 7 Laptop eens de upload doen, bedankt voor deze tip!
Bij mij verhogen jumbo frames de snelheid niet. Integendeel het heeft juist een verlagend effect.
Anderen hebben wel voordeel geconstateerd, met name mac gebruikers.
Ik ga het verder testen!
PS Al je instellingen zijn prima in orde, al mis ik een plaatje van je switch waar je de trunk gemaakt hebt.
Bedankt een plaatje van de trunk in de HP1810 toegevoegd in 1e post.
-
Wat laat ping -D -s 8150 <IP-NAS>" zien vanaf je MAC ?
Last login: Thu Apr 30 11:51:04 on ttys000
You have mail.
MACPRO:~ $ ping -D -s 8150 192.168.178.125
PING 192.168.178.125 (192.168.178.125): 8150 data bytes
8158 bytes from 192.168.178.125: icmp_seq=0 ttl=64 time=0.748 ms
8158 bytes from 192.168.178.125: icmp_seq=1 ttl=64 time=0.952 ms
8158 bytes from 192.168.178.125: icmp_seq=2 ttl=64 time=1.067 ms
8158 bytes from 192.168.178.125: icmp_seq=3 ttl=64 time=0.876 ms
8158 bytes from 192.168.178.125: icmp_seq=4 ttl=64 time=0.924 ms
8158 bytes from 192.168.178.125: icmp_seq=5 ttl=64 time=0.958 ms
8158 bytes from 192.168.178.125: icmp_seq=6 ttl=64 time=0.940 ms
8158 bytes from 192.168.178.125: icmp_seq=7 ttl=64 time=0.883 ms
8158 bytes from 192.168.178.125: icmp_seq=8 ttl=64 time=0.919 ms
8158 bytes from 192.168.178.125: icmp_seq=9 ttl=64 time=0.907 ms
8158 bytes from 192.168.178.125: icmp_seq=10 ttl=64 time=0.931 ms
8158 bytes from 192.168.178.125: icmp_seq=11 ttl=64 time=0.870 ms
8158 bytes from 192.168.178.125: icmp_seq=12 ttl=64 time=0.957 ms
8158 bytes from 192.168.178.125: icmp_seq=13 ttl=64 time=0.919 ms
8158 bytes from 192.168.178.125: icmp_seq=14 ttl=64 time=0.905 ms
8158 bytes from 192.168.178.125: icmp_seq=15 ttl=64 time=0.836 ms
8158 bytes from 192.168.178.125: icmp_seq=16 ttl=64 time=0.968 ms
8158 bytes from 192.168.178.125: icmp_seq=17 ttl=64 time=1.016 ms
8158 bytes from 192.168.178.125: icmp_seq=18 ttl=64 time=0.882 ms
8158 bytes from 192.168.178.125: icmp_seq=19 ttl=64 time=0.847 ms
8158 bytes from 192.168.178.125: icmp_seq=20 ttl=64 time=0.889 ms
-
Wat laat ifconfig voor MTU waarden zien?
Komt ie dan MMD:
MACPRO:~ $ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
inet6 ********** prefixlen 64 scopeid 0x1
nd6 options=1<PERFORMNUD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 9000
options=b<RXCSUM,TXCSUM,VLAN_HWTAGGING>
ether **********
media: autoselect (1000baseT <full-duplex>)
status: active
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 9000
options=b<RXCSUM,TXCSUM,VLAN_HWTAGGING>
ether **********
media: autoselect (1000baseT <full-duplex>)
status: active
en2: flags=8823<UP,BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
ether **********
nd6 options=1<PERFORMNUD>
media: autoselect (<unknown type>)
status: inactive
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
lladdr **********
nd6 options=1<PERFORMNUD>
media: autoselect <full-duplex>
status: inactive
p2p0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 2304
ether **********
media: autoselect
status: inactive
bond0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 9000
options=b<RXCSUM,TXCSUM,VLAN_HWTAGGING>
ether **********
inet6 **********%bond0 prefixlen 64 scopeid 0x9
inet 192.168.178.100 netmask 0xffffff00 broadcast 192.168.178.255
nd6 options=1<PERFORMNUD>
media: autoselect (1000baseT <full-duplex>)
status: active
bond interfaces: en0 en1
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 **********%utun0 prefixlen 64 scopeid 0xa
inet6 ********** prefixlen 64
nd6 options=1<PERFORMNUD>
Alhoewel dit aba-ka-dabra voor mij is, kan ik wel hieruit opmaken van mijn MACBOND (bond0) betsaat uit "bond interfaces: en0 en1" met een MTU van 9000, en "media: autoselect (1000baseT <full-duplex>)".
MMD graag even jouw terugkoppeling wat de rest allemaal betekend, bedank alvast!
-
MACPRO:~ $ ping -D -s 8150 192.168.178.125
PING 192.168.178.125 (192.168.178.125): 8150 data bytes
8158 bytes from 192.168.178.125: icmp_seq=0 ttl=64 time=0.748 ms
8158 bytes from 192.168.178.125: icmp_seq=1 ttl=64 time=0.952 ms
Uitstekend dus, Jumbo MTU 9000 werkt tussen je MAC > NAS.
Edit:
Als het niet goed gaat, dan krijg je bijvoorbeeld dit (Windows > Server):
C:\Windows\system32>ping -l 8150 -f Server
Pinging Server [192.168.1.22] with 8150 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 192.168.1.22:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
-
Dank voor je bevestiging dat de MTU 9000 dus goed werkt, nu dan nog maar wat andere testjes doen. Zal nu mijn Bootacmped Windows 8 opstarten en daar eens kijken hoe een en ander werkt om MTU 9000 in te stellen. Weer een leerzaam 'projectje' ! ;)
Ik zal ook hiervan even wat screens e.d. plaatsten, maar dan uiteraard in het Windows sub-forum, want we houden het wel proper natuurlijk! :lol:
-
…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.
Nee, sinds Mavericks (eind 2013) is SMB het preferred protocol. Sinds die tijd wordt SMB genomen als beide protocollen beschikbaar zijn. (En als de mac weet dat ze beschikbaar zijn). In de standaard configuratie meldt de mac via Bonjour zowel zijn aanwezigheid als SMB server en als AFP server. Als je dan geen protocol opgeeft, verbind hij met SMB. Persoonlijk had ik daar problemen mee omdat ik dan tegen allerlei bugjes aanliep waardoor ik SMB expliciet uit moest zetten. Nu met Yosemite zijn die bugjes weg en staat smb weer aan op mijn macs.
De nas echter, meld via bonjour alleen zijn aanwezigheid als AFP server. (Ook met DSM 5.1), dus daar verbind hij nog niet standaard via SMB. Zodra Synology ook SMB toevoegt aan de Bonjour broadcasts, zal de mac ook SMB gaan gebruiken als default.
-
Dank voor je bevestiging dat de MTU 9000 dus goed werkt,
Ik loop met mail weer tegen een probleem met MTU 9000 aan. MTU 9000 heeft bij mij altijd goed gewerkt met filetransfer. Dus van nic naar nic gaat het goed. Echter, IMAP krijgt dan verbindingsproblemen. Ik weet echter niet of dat aan de IMAP server op de nas ligt, of aan het Apple mail programma. Een van beide heeft problemen om grote datablokken te verwerken.
Zowel de Synology MailSever als ook Apple mail heeft meerdere updates gehad sinds mijn test van ruim een jaar geleden dus heb ik het gisteren opnieuw geprobeerd. Niet opgelost en IMAP werkt nog steeds niet goed met Jumbo. (Gisteren met MTU 4000 getest) Ik heb Jumbo op de nas dus weer uit gezet. Op mijn iMacs staat het al zeker twee jaar aan zonder problemen. Ik gebruik mijn iMac's nog steeds als primaire fileserver.
Ik ben benieuwd of anderen ook deze problemen kennen. En op het probleem op de mac zit of in de nas.
-
ifconfig laat onder andere de MTU waarden zien van de (virtuele) netwerkadapters.
Het is ter controle of de waarden ook daadwerkelijk gezet zijn.
Het ziet er naar mijn idee goed uit.
tun0 = VPN
fw0 = firewire
lo0 = loopback te herkennen aan 127.0.0.1
p2p0 = Airdrop
En inderdaad de bond0 bestaat uit en0 en en1
De andere adapters die je ziet voor zover ik even snel kan vinden:
stf0 = IPv6
gif0 weet ik niet maar waarschijnlijk ook een virtuele
Ter controle kun je ifconfig ook nog op de NAS doen maar denk niet dat het nodig is omdat naar aanleiding van @Birdy`s post je al weet dat er geen fragmentatie van pakketten plaatsvindt.
Je zou evt. met een stopwatch kunnen meten maar beter is een goed programmatje.
Dan vergelijken met MTU 1500.
Ook ik denk dat men beter standaard kan laten als er geen problemen zijn.
-
Topic gaat verder hier voor Windows. (http://www.synology-forum.nl/windows/jumbo-frames-gt-mtu-9000-23655/)
-
Topic gaat verder hier voor Windows. (http://www.synology-forum.nl/windows/jumbo-frames-gt-mtu-9000-23655/)
Bedankt voor het verplaatsen, ik had er weer een zootje van gemaakt! ::)
-
Valt wel mee hoor ;)