Synology-Forum.nl
OS Specifieke ondersteuning => Mac OS X => Topic gestart door: TonVH op 26 september 2016, 09:45:08
-
Bijgaand wat metingen. M.n. Helios Lantest is interessant want die meet meer dan alleen transfersnelheden. Duidelijk blijkt hieruit dat AFP 2 * zo snel is als SMB. NB: SMB instelling in DSM6 maakt niets uit. Geen wezenlijk verschil.
Metingen met Blackmagic heb ik achterwege gelaten. Visueel leuk maar inhoudelijk van weinig waarde.
-
Zo'n groot verschil kan niet kloppen. Ik meet nooit een groot verschil met dat programma Helios.
Ik heb ooit wel een groot verschil gemeten, maar dat kwam omdat ik file-logging aan had staan voor SMB. Dan was hij tijdens de smb-test nog druk bezig met het wegschrijven van alle acties die tijdens het testen gebeurden. ;)
-
YMMV maar ik heb vaker dit soort vergelijkingen gemaakt en altijd zijn de verschillen dermate groot dat ik SMB niet gebruik. Volledigheidshalve de instellingen. Op de Mac is er geen enkel instelling handmatig gedaan, die verkeert wat dat betreft haast in maagdelijk staat. Ben te lui om moeizaam met de Terminal te gan klooien. Iets teveel gedaan in mijn werkzame leven.
[attach=1]
-
Ton, ik heb dit maar even van de rest afgesplitst omdat het niets met inloggen te maken heeft.
Maar je hebt gelijk, Helios geeft een heel groot verschil tussen AFP en SMB. Ik heb het nagemeten en vind het zelfde vanaf mijn IMac die aan dezelfde switch hangt als de nas. Ik heb gemeten met een basisbelasting van 7 IP camera's die ook nog naar deze nas toe streamen. De absolute snelheden zouden dus hoger kunnen worden, maar voor de verschillen mag het niets uitmaken. Dus echt een meting onder praktijk condities.
[attachimg=1]
[attachimg=2]
Nu ik dit zie herinner ik me dat ik dit toch eerder ook gemeten had. Volgens mij was dat sinds DSM 6 toen er opmerkingen waren dat SMB zo traag geworden was.
-
Bijgaand wat metingen.
Bedankt, ik ga toch maar weer even wat metingen doen omdat ik na mijn LACP avontuur in 2013, het 'idee' heb dat mijn netwerk behoorlijk is ingekakt. Maar zoals ook aangegeven in het draadje over het inloggen, ga ik eerst mijn netwerk maar weer eens nalopen. Het zal vast wel weer mijn eigen gebruikersfout zijn! ;D
Cheers
-
Ik heb de metingen voor de aardigheid herhaald tussen mijn twee iMacs, die ook aan dezelfde switch hangen als de nas.
Ook hier zie ik een verschil van bijna een factor 2. Bij de nas zat het bij mij dichter bij een factor 3 dan een factor 2.
[attach=1]
[attach=2]
Dan ga je je afvragen waarom Apple nu zo inzet op SMB en je iMac/MacBook zelfs de voorkeur geeft boven AFP als hij kan kiezen.
-
Een interessant feit is het volgende:
Ik synchroniseer tegenwoordig de inhoud van sommige folders op mijn Mac (zoals de iTunes folder) met mijn NAS automatisch vanuit een kleine PC. De reden is dat rechtstreekse synchronisatie tussen mijn Mac en de NAS veel langzamer gaat.
Voorbeeld: Kopieer ik op de Mac met Finder een 100 Gb folder naar de NAS dan duurt dit ongeveer een uur (met een verschil van 10 minuten afhankelijk of AFP of SMB gebruikt wordt).
Koppel ik nu de harde schijf van dezelfde Mac als een share aan mijn PC, en kopieer ik dezelfde 100 Gb folder vanaf de share naar de NAS ben ik in minder dan een half uur klaar.
-
Dan ga je je afvragen waarom Apple nu zo inzet op SMB en je iMac/MacBook zelfs de voorkeur geeft boven AFP als hij kan kiezen.
Een van de voordelen van Mac is dat je niet hoeft te kiezen.
Toch zal ik vrijwel altijd de voorkeur geven aan zelfkiezen.
Contradictie, ik weet't.
-
Ik heb geen mac en kan er dus niet over meepraten, maar misschien kan iemand kijken welke smb versie door de mac gebruikt wordt.
De verschillen die ik zie treden ook op tussen smb 1 en smb 2(of3) als je een PC gebruikt.
Op mijn PC kan ik met SMB 3 naar een DS414 praktisch het hele 1Gb/s dichttrekken.
Ik kom tot snelheden van 110 MByte/s
-
De share "Macintosh" op mijn nas (=GedeeldeData) is via SMB 3.0 verbonden:
iMac-DDR2:~ Briolet$ smbutil statshares -a
==================================================================================================
SHARE ATTRIBUTE TYPE VALUE
==================================================================================================
Macintosh
SERVER_NAME GedeeldeData.local
USER_ID 501
SMB_NEGOTIATE AUTO_NEGOTIATE
SMB_VERSION SMB_3.0
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
LARGE_FILE_SUPPORTED TRUE
OS_X_SERVER TRUE
CLIENT_REQUIRES_SIGNING TRUE
QUERYINFO_NOT_SUPPORTED TRUE
DFS_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
ENCRYPTION_SUPPORTED TRUE
SIGNING_ON TRUE
-
Hier een heel draadje over dit onderwerp: https://discussions.apple.com/thread/7565683?start=45&tstart=0
Zie bijlagen.
[attach=1]
PS: meerdere plaatjes wil niet lukken. Zie de 1e link.
-
Het draadje met het inlogprobleem is een ander draadje.
-
De share "Macintosh" op mijn nas (=GedeeldeData) is via SMB 3.0 verbonden:
Dat is, op de keeper beschouwd, niet wat smbutil aangeeft. smbutil zegt niet meer dan dat smb3.0 ondersteund wordt en dat hij het protocol onderhandelt. Wat de uitkomst van die 'onderhandeling' is, zie je niet.
Ik heb voor de aardigheid nog eens met wireshark gekeken:
[attachimg=1]
Die geeft SMB2 aan als gebruikt protocol. Maar ik gebruik Wireshark weer te weinig om met zekerheid te kunnen zeggen of hij niet alles SMB2 noemt.
Edit: In de menus kent Wireshark alleen AFP, SMB en SMB2 dus ik denk dat SMB3 ook als SMB2 weergegeven wordt.
-
Vanaf Yosemite is SMB3 de default bij OS X.
-
Het draadje met het inlogprobleem is een ander draadje.
Link -> Apple forum gaat over traagheid SMB versus AFP en niet over inlogprobleem.
-
Hier een heel draadje over dit onderwerp: https://discussions.apple.com/thread/7565683?start=45&tstart=0
Dat draadje geeft aan dat de SMB 'problemen' een bewuste keuze van Apple is sinds OSX El Capitan 10.11.5. Toen is standaard de " SMB signing" aangezet om de "Badlock (https://en.wikipedia.org/wiki/Badlock)" exploit te voorkomen. Dat was toen een snelle fix waar de vertragende werking van bekend was op dat moment (Ik begin het me weer te herinneren). Met de huidige OSX 10.11.6 is er echter nog geen betere fix.
-
Volgens mij ben je ietwat kort door de bocht want Apple speelt het balletje terug naar Synology e.e.:
[attachimg=1]
Wie er gelijk heeft? Geen idee, ik gebruik gewoon AFP en dan nergens last van.
Dit zou overigens een oplossing voor het traagheidsprobleem zijn:
defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist SigningRequired -bool false
-
Om dit bij Synology neer te leggen is tamelijk vreemd van apple.
Synology gebruikt gewoon Samba en kan zelf dus helemaal niets aanoassen.
Verder blijkt het voornamelijk en hype geweest te zijn en heeft Samba het allang gepatched.
Zie:
https://threatpost.com/badlock-vulnerability-falls-flat-against-its-hype/117349/
-
Volgens mij ben je ietwat kort door de bocht want Apple speelt het balletje terug naar Synology e.e.:
Nee, want ook tussen 2 iMacs meet ik een factor 2 snelheidsverschil bij afp/smb. In de eerdere link staat dat de snelheid weer terug komt als je de smb-Signing uitschakelt.
-
Interessant, ga ik ook testen.
-
Ik merk ook een factor 2+ verschil tussen SMB en AFP in het voordeel van AFP.
Verder valt me op dat SMB2 Large MTU ietsje sneller is dan SMB3.
Helaas is AFP niet geschikt in een multiuser omgeving (2 gebruikers op 1 iMac met een te koppelen home map op de NAS), dus dan maar trager maar wel geschikt voor multiuser gebruik (Of weet iemand een truc om gekoppelde shares niet dubbel weer te geven in finder?)
-
Begrijp niet echt wat je bedoelt want meerdere gebruikers is op zich geen probleem. En op een iMac draait er feitelijk maar 1 user tegelijkertijd (afgezien van het systeem).
-
als mijn vrouw en ik tegelijk zijn aangemeld op de iMac dan lukt het niet om met AFP de home folder voor beide tegelijker tijd te koppelen.
Via het hulp programma mountain lukt het dan wel, maar dan zijn alle gemounte shares onder beide accounts te zien in finder.
Dus 2x home, 2x photo etc zichtbaar in finder waarvan er dan maar 1 te benaderen is omdat je niet geautoriseerd bent voor de andere.
staat alleen zo irritant 12 gekoppelde shares waarvan je er met 6 niets kan.
-
Op een iMac is toch normaliter maar 1 gebruiker tegelijkertijd actief/ingelogd?
Of is dit iets specifieks met de Home folder? Gebruik ik niet. Heb je datzelfde probleem ook als je met HTTP inlogt?
-
Op de mac kun je met meerdere users gelijktijdig ingelogd zijn. Dat is ergens rond Leopard of Snow leopard ingevoerd. Met shares werkt dat inderdaad niet optimaal.
Als dat niet aan staat moet je dat bij de accountinstellingen aan zetten:
[attachimg=1]
Dan kun je naar een volgende gebruiker overschakelen zonder dat je hoeft uit te loggen.
-
Dat kende ik maar dacht aan 2 gebruikers die tegelijkertijd actief zijn.
-
Probleem doet zich helaas voor zodra er twee gebruikers zijn ingelogd.
Er is bij ons altijd 1 gebruiker actief bezig, de andere is op de achtergrond nog steeds aangemeld op de iMac en dus ook verbonden met de shares. Dit is ook wenselijk omdat de niet actieve gebruiker nog bestanden open kan hebben staan.
Onder windows hier nooit problemen mee gehad, valt mij eerlijk gezegd toch een beetje tegen dat OS-X zoiets basic niet goed ondersteund.
-
Vreemd dat het afhankelijk van het protocol is. Heb je al eens op het Apple forum gekeken wat daar te vinden is?
Ik heb ze niet geheel doorgewerkt maar hier (https://discussions.apple.com/thread/2805070?start=0&tstart=0) en hier (https://discussions.apple.com/thread/6691912?start=0&tstart=0) gaat het denk ik over hetzelfde probleem en uit mijn snelle lezing krijg ik de indruk dat NFS een oplossing zou kunnen zijn.
-
De oplossing om nagenoeg AFP snelheden bij mij thuis te krijgen was het volgende:
Van de website https://dpron.com/os-x-10-11-5-slow-smb/ het volgende terminal commando uitgevoerd op SMB signing op de client uit te zetten: printf "[default]\nsigning_required=no\n" | sudo tee /etc/nsmb.conf >/dev/null
Daarna in DSM onder de SMB 3 instellingen transportcoderingsmodus op "Uitschakelen" gezet.
Hierna verwaarloosbaar verschil in snelheid tussen AFP en SMB3 onder OSX El Capitan
-
Inmiddels hebben we DSM 6.1, daar kun je in de geavanceerde instellingen in het config. scherm, bonjour-service detectie inschakelen voor time machine. Welke broadcast kun je voor time-machine nu het beste kiezen: AFP of SMB ?
-
Ik zou ze beide aan laten en de mac laten kiezen wat hij het beste vindt.
Backups zijn toch achtergrondtaken die niet snel hoeven te gaan. Zelfs al zou dit trager gaan, dan houdt je meer netwerksnelheid over voor je voorgrond taken.
-
Dank voor je reactie.
-
Inmiddels hebben we DSM 6.1, daar kun je in de geavanceerde instellingen in het config. scherm, bonjour-service detectie inschakelen voor time machine. Welke broadcast kun je voor time-machine nu het beste kiezen: AFP of SMB ?
Ik zou ze beide aan laten en de mac laten kiezen wat hij het beste vindt.
Allebei dus...
hm, ga ik dan maar doen, want met AFP en het recentste macOS wil een Time Machine backup niet vlotten.
Had nu net SMB aangevinkt en kreeg een bericht dat ik niet begrijp.
Zie bijlage.
-
Wat snap je niet aan dat bericht. Volgens mij is dat bericht vrij eenduidig en niet voor meerdere uitleg vatbaar. (Allemaal features die Apple eist voor TimeMachine via SMB)
-
@Briolet: 'opportunistic locking', 'SMB duurzame ingangen', smb2-lease'.. nooit eerder gezien.
Maar goed, allebei gewoon aanzetten dus.
Is er trouwens een maximum capaciteit dat Time Machine op een NAS aankan?
Ik heb nu op één 8TB WD Red HD's een 4 en 3,5 TB quota ingesteld voor twee Mac mini's.
-
Als je ooit SMB3 aangezet had, dan staat dat alles al aan, want ik heb dat dialoog nooit gezien toen ik Time Machine via smb aanvinkte in de 6.1 RC. (Of dat dialoog is toegevoegd na de RC versie)
In de specificaties voor Time Machine via smb geeft Apple aan welke features smb moet ondersteunen. Blijkbaar doet Synology die controle heel netjes door de bonjour broadcast niet klakkoos aan te zetten.
-
Ik heb de test ook eens even uitgevoerd op mijn NAS.
Het verschil tussen SMB3 en AFP is wel erg groot in het voordeel van AFP.
Maar binnen AFP zag ik ook verschillen. En dat heeft weer te maken met hoe je de shares van je NAS aanroept.
De standaard methode die Synology voorschrijft is: afp://Naamvanje_NAS.local/Sharenaam
Echter, als je in de finder je NAS opent (onder 'Shared' in de sidebar links) en daar vervolgens een share opent, dan wordt die op de volgende manier aangeroepen: afp://Naamvanje_NAS._afpovertcp._tcp.local/Sharenaam. Het verschil zit dus in die '_afpovertcp._tcp'.
Nu was ik benieuwd of dat een verschil uitmaakte kwa snelheid, en wat denk je? Een redelijk verschil, niet schokkend maar toch...
Ik heb drie bestanden bijgevoegd. Op de screenshots zie je of het SMB of AFP is.
De SMB test is volgens het SMB3 protocol (waar Apple de voorkeur aan geeft)
De AFP test 1 is een share die gemount is op deze manier: afp://Naamvanje_NAS._afpovertcp._tcp.local/Projects
De AFP test 2 is een share die gemount is op deze manier: afp://Naamvanje_NAS.local/Projects
Ik begrijp werkelijk niet waarom Apple de voorkeur geeft aan het SMB protocol als de verschillen zo groot zijn.
Vooralsnog blijf ik op AFP zitten en het lijkt me wel duidelijk waarom ;).
-
Die traagheid van SMB is ontstaan toen er de badock bug in SMB ontdekt is en de mac, na een update, nu constant extra testen doet. (SIGNING = true) Op internet zijn wel terminal-comando's te vinden om dat weer uit te zetten en de oude snelheid terug te krijgen. Eigenlijk had ik verwacht dat Apple dit bij een OS update weer terug zou zetten.
Zie ook eerder in dit topic.
-
Als ik de attributen opvraag via de terminal, zie ik wel kleine veranderingen t.o.v. vorig jaar:
briolet$ smbutil statshares -a
==================================================================================================
SHARE ATTRIBUTE TYPE VALUE
==================================================================================================
home
SERVER_NAME nas (Mijn nas)
USER_ID 501
SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED
SMB_VERSION SMB_3.02 <---------------
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
LARGE_FILE_SUPPORTED TRUE
OS_X_SERVER TRUE
CLIENT_REQUIRES_SIGNING TRUE
DFS_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
ENCRYPTION_SUPPORTED TRUE
SIGNING_ON TRUE
--------------------------------------------------------------------------------------------------
Briolet
SERVER_NAME iMac-DDR2.local (Mijn iMac)
USER_ID 501
SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED
SMB_VERSION SMB_3.0 <---------------
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
SIGNING_REQUIRED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
UNIX_SUPPORT TRUE
LARGE_FILE_SUPPORTED TRUE
OS_X_SERVER TRUE
CLIENT_REQUIRES_SIGNING TRUE
FILE_IDS_SUPPORTED TRUE
FILE_LEASING_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
ENCRYPTION_SUPPORTED TRUE
SIGNING_ON TRUE
Ik zie ook verschillen tussen een mount met de nas en mijn iMac (Beide vanaf mijn MacBook). De nas verbind met smb 3.02 en de iMac via smb 3.0. (Even omlaag scrollen in de listing) Op zich vreemd dat hij met de nas een nieuwere smb versie gebruikt omdat op beide macs de nieuwste Os Sierra versie draait.
Ook vreemd. Als je op de nas instelt dat SMB 2 het laagste te gebruiken protocol is, vind je nog steeds "SMB_NEGOTIATE : SMBV_NEG_SMB1_ENABLED" in de attributen.
-
Ok, ik heb dat nsmb.conf bestandje aangemaakt, en vervolgens weer een test gedaan.
Is inderdaad behoorlijk sneller, maar nog steeds niet de AFP snelheid.
-
Let er bij dit soort tests wel op dat de logging op de nas uit staat. Een paar jaar geleden vond ik ook een heel groot verschil tussen afp en smb. Maar dat kwam toen omdat smb al het openen etc van files logde en afp niet. Voor het testen worden veel kleine files gecreëerd en gelezen. Toen ik logging uit zetten, verdubbelde mijn snelheid. ;)
Dat was nog op mijn trage 212j nas.
Toevoeging:
Overigens zijn de verschillen tussen twee mac's even groot. Als ik 2 iMac's via afp verbind, dan is het schrijven 2,5 en het lezen 3 maal zo snel als via smb verbonden. Dat is alles sinds de aanpassing tegen de badlock bug. Maar ik zou inmiddels een aanpassing van de smb instellingen verwachten omdat alle smb apparaten inmiddels wel een fix hebben voor de badLock bug, of teruggang naar afp als default protocol.
-
https://dpron.com/os-x-10-11-5-slow-smb/