P2P Cat5e ethernet haalt niet volledig potentieel via Samba3

[Razor_]

Mijn vraag
Vandaag ging ik wat onderzoek doen waarom mijn rsync backups vanaf m'n MacBook Pro naar Windows via Samba veel trager is dan het zou moeten zijn. Het gaat hier om een P2P netwerkje met IP range 10.0.0.*, subnet 255.255.0.0.

Relevante software en hardware die ik gebruik
Windows 10 Pro PC met Gigabyte Z370M D3H moederbord (Intel 1Gbps adapter) met Samba 3
MacBook Pro 15-inch 2015 met Thunderbolt 1GB Ethernet adapter en macOS Catalina
Cat5e 1Gbps 2 meter kabel

Wat ik al gevonden of geprobeerd heb
Rsync haalde eerst max maar 19.5MegaByte/s. Bleek dat compressie er voor zorgde dat de snelheid afnam.
Nu zonder compressie is de snelheid 63,22MegaByte/s. Een grote verbetering!

Daarna ontdekt dat de Intel netwerkkaart in de BIOS op Auto Negotiate staat. Helaas kan bij de custom opties niet meer dan Full 100Mbps gekozen worden. Gelukkig kon dit in Windows in de Netwerk Adapter instellingen wel op Full 1Gbps. Nu nogmaals een rsync test en haal nu 72,19MegaByte/s.

Als ik op macOS met Finder direct een transfer doe krijg ik nog iets meer speed; 82,69MegaByte/s.

Nu om uit te sluiten dat de Cat5e kabel misschien niet goed is, heb ik een paar andere uit m'n netwerkkabel-tas geprobeerd (allemaal geklinkd (t?)). Zit praktisch geen verschil tussen de kabels. De 2 meter is net zo snel als de 5, 10 en 20 meter (hoogstens een paar honderd KB variatie).

Nu om uit te sluiten dat de lijn op zichzelf niet capped is heb ik iperf server/client test gedaan:

code:

G:\Downloads\iperf-3.1.3-win64>iperf3.exe -c 10.0.0.4
Connecting to host 10.0.0.4, port 5201
[  4] local 10.0.0.3 port 54432 connected to 10.0.0.4 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   113 MBytes   946 Mbits/sec
[  4]   1.00-2.00   sec   113 MBytes   944 Mbits/sec
[  4]   2.00-3.00   sec   112 MBytes   944 Mbits/sec
[  4]   3.00-4.00   sec   113 MBytes   944 Mbits/sec
[  4]   4.00-5.00   sec   112 MBytes   944 Mbits/sec
[  4]   5.00-6.00   sec   113 MBytes   944 Mbits/sec
[  4]   6.00-7.00   sec   112 MBytes   943 Mbits/sec
[  4]   7.00-8.00   sec   113 MBytes   945 Mbits/sec
[  4]   8.00-9.00   sec   112 MBytes   944 Mbits/sec
[  4]   9.00-10.00  sec   113 MBytes   944 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  1.10 GBytes   944 Mbits/sec                  sender
[  4]   0.00-10.00  sec  1.10 GBytes   944 Mbits/sec                  receiver

iperf Done.

Hier lijkt de verbinding toch wel duidelijk z'n max potentieel te halen.

Nu is de vraag; wat kan ik nog meer op Windows en/of macOS tweaken om richting die 112MegaByte te komen? Misschien is Samba 4 een optie? Maar weet niet of dat handig is, omdat Windows 10 zelf standaard 3 wil gebruiken vanuit Verkenner.

Alvast bedankt voor de input!

[Ben(V)]

Het probleem zit in je mac.
In het verleden was er een kleine security risc in de smb stack en Apple heeft dat toen opgelost door smb client signing aan te zetten in hun default samba configuratie.

Het probleem in smb is reeds lang gefixed, maar Apple heeft nooit de moeite genomen het weer uit te zetten.
Die signing maakt smb file transfer enorm traag.

Oplossing:
Maak een bestandje aan /etc/nsmb.conf aan met daarin deze regels en reboot je mac daarna.
[default]
signing_required=no

[Wim-Bart]

Daarnaast heb je ook nog een stuk overhead, dus je zou Jumbo Frames aan kunnen zetten. Tevens zou ik je netwerk segment van een /16 naar een /24 verkleinen, waarom een 10.0.0.0/16 en geen 10.0.0.0/24 omdat dit ook invloed heeft op gebruikte arp/ip tabellen die groter zijn in de diverse componenten, je wil namelijk je broadcast domain zo klein mogelijk houden.

[Ben(V)]

Jumbo frames zou ik sterk afraden, het levert zeker niets op en vaak wordt het er alleen slechter door.
En netwerk segmenten verkleinen is micro optimalisatie en kan nooit meetbare verschillen opleveren.

[Razor_]

Bedankt voor de reactie beide!

Ik heb het segment alvast aangepast naar 10.0.0.1 10.0.0.2 255.255.255.254 en de smb settings geüpdatet. Op macOS Catalina moet je vgm ook `~/Library/Preferences/nsmb.conf` hebben om het te laten werken.

Experiabox V10 lijkt het aanpassen van de MTU niet geactiveerd te hebben in de build van de kernel.

Ik ga morgenvroeg even een nieuwe reeks snelheid testen doen en zal dan een status update geven.

[Wim-Bart]

Ben(V) schreef op vrijdag 19 juni 2020 @ 00:35:
Jumbo frames zou ik sterk afraden, het levert zeker niets op en vaak wordt het er alleen slechter door.
En netwerk segmenten verkleinen is micro optimalisatie en kan nooit meetbare verschillen opleveren.

Ik draai zowel prive als zakelijk overal 9K Jumbo frames en nooit issues meegemaakt op bekabelde netwerken. En wanneer je met hobby SAN gaat werken zoals iSCSI en NFS dan merk je het verschil al helemaal. Misschien wanneer je oude zooi gebruikt heb je issues, maar zelfs met een goedkope Netgear of TP-Link unmanaged switch werkt het goed.

Afgezien van wat oude legacy meuk is er geen enkele reden om geen Jumbo Frames te gebruiken.

[Razor_]

Wim-Bart schreef op vrijdag 19 juni 2020 @ 00:50:
[...]

Ik draai zowel prive als zakelijk overal 9K Jumbo frames en nooit issues meegemaakt op bekabelde netwerken. En wanneer je met hobby SAN gaat werken zoals iSCSI en NFS dan merk je het verschil al helemaal. Misschien wanneer je oude zooi gebruikt heb je issues, maar zelfs met een goedkope Netgear of TP-Link unmanaged switch werkt het goed.

Afgezien van wat oude legacy meuk is er geen enkele reden om geen Jumbo Frames te gebruiken.

Ik ben niet zo'n netwerk wonder als jullie; maar als de Experiabox het niet specifiek kan instellen, maar ik kan m'n clients allemaal wel naar 9000 zetten, dan werkt het wel? Of omdat de router niet hoger dan 1500 gaat is het al game over?

p.s. ik gebruik geen directe router-connected-devices, zoals USB-disks, printers etc.

[Voor 5% gewijzigd door Razor_ op 19-06-2020 00:52]

[Wim-Bart]

Experiabox v10 kan er mee overweg, v8 weet ik niet.

[Razor_]

Wim-Bart schreef op vrijdag 19 juni 2020 @ 00:54:
Experiabox v10 kan er mee overweg, v8 weet ik niet.

Heb idd een V10 ZTE H369A

[Wim-Bart]

Razor_ schreef op vrijdag 19 juni 2020 @ 00:55:
[...]


Heb idd een V10 ZTE H369A

Zou gewoon moeten werken.

Zet gewoon 1 device op Jumbo en test. Dan volgende, dan volgende. Devices die niet werken laat je gewoon staan. Niet alles binnen netwerk hoeft Jumbo te zijn, IP protocol kan heel mooi er mee omgaan.

[Ben(V)]

Ik heb uitgebreide testen met jumbo frames in allerlei omgevingen gedaan en het levert echt helemaal niets op.

Maar als je in je netwerk een device hebt dat geen jumboframes aankan vertraagt dat de boel enorm omdat dan eerste alle frames weer afgebroken moeten worden als de zender er achter komt dat de ontvanger het niet aankan.
En als je pech hebt kan het zelf je hele netwerk ophangen.

En in zakelijke omgevingen is het idee van jumbo frames echt al heel lang achterhaalt, als het zo'n goed idee zou zijn zou dat allang de standaard instelling van professionele apparatuur zijn wat echt nooit het geval is en geen enkele leverancier geeft als aanbeveling dit aan te zetten.

Maar als je gaat testen zul je daar zelf ook wel op uitkomen.

Verder is het bekent dat rsync behoorlijk wat overhead heeft en met name veel cpu verbruikt, dat zie je ook aan de sterke terugval als je gaat encrypten en dus meer cpu nodig hebt.
Ik denk dat er dus gewoon niet veel meer inzit.

[Voor 16% gewijzigd door Ben(V) op 19-06-2020 08:43]

[MissingDog]

Waarom gebruik je rsync met een SMB share als target? Je hebt hier een enorm inefficiënt geïmplementeerd protocol als tussenlaag geïntroduceerd.
Je kunt op zowel Windows (via cygwin) als Mac rsync als daemon draaien met het native protocol en indien je hier nog kiest voor een only delta's transfer enorme winsten in effectieve snelheid behalen. Ik heb dit jarenlang in zakelijke omgevingen gebruikt voor grootschalige datamigraties zonder een centje pijn.

Check hier even: https://www.aaroncurley.c...g-using-rsync-on-windows/

Een van de voordelen van deze constructie is dat je client niet via het netwerk de doellocatie hoeft te kunnen enumereren of browsen; dit verkeer kan dus lekker van de lijn blijven waardoor je veel beter van de caching op je doelserver profiteert.

[Voor 18% gewijzigd door MissingDog op 19-06-2020 08:47]

[Ben(V)]

Alhoewel ik zou willen bestrijden dat smb een inefficiënt protocol is heb je wel een punt.
Als smb zo inefficiënt zou zijn zou hij die 86,69 MB/s nooit halen want dat is ongeveer het maximale wat je uit een 1Gb (= 125MB/s) verbinding haalt als je de netwerk overhead eraf trekt.

Laag op laag is indien mogelijk het beste te vermijden, alhoewel je dan weer een extra laag in de vorm van cygwin gaat toevoegen dus of het iets oplevert is nog maar de vraag want cygwin brengt erg veel overhead met zich mee en smb op windows is bijzonder efficient geïmplementeerd, de beperking zit duidelijk in de mac samba implementatie.

Ik haal met een directe filetransfer tussen twee window systemen of tussen een window systeem en een Synology Nas snelheden van rond de 95Mb/s.
Ik heb wel eens rsync geprobeerd tussen Windows en Nas maar dat was qua performance dramatisch.

[Voor 47% gewijzigd door Ben(V) op 19-06-2020 09:00]

[Razor_]

Goedemorgen,

De reden dat ik rsync over Samba doe kwam meer uit convenience. Ik ben niet zo thuis in de Windows tooling en had in het verleden wat disks op Windows shared (gewoon via Verkenner). Later had ik op m'n Linux' en Mac rsync gebruikt om af en toe folders te syncen/backups te maken.

Ik heb voor sanity sake even een tussentest gedaan met /26 prefix en en IP .1 en .2 gebruikt (lager vind zowel Windows als de Mac niet ok (geeft ongeldig bereik error)). Dit geeft (zoals natuurlijk wel verwacht) geen echte afwijking in de average speed. Maar wel een handige improvement gezien het maar een communicatie tussen 2 specifieke devices is.

Ik heb op zowel de Windows LAN kaart als de Thunderbolt Ethernet Jumbo packets aangezet (9000). Met een grote file van ~940MB haal ik ongeveer 105MB/s (wat bijna de cap is, dus ik denk dat daarmee de piek is behaald).

Rsync blijft nog wel steeds stuiteren tussen 72 en 82 MB/s. Een rsync waarbij juist honderdduizenden files in een folder (2,51GB) zitten krijgt zelfs een gigantische drop naar ~4,8MBs (waarschijnlijk net als bij compressie, door veel disk/cpu overhead). Heb dezelfde copy met zoveel files in Finder geclocked en dan haalt ie ongeveer 7,25MBs.

Gezien direct Samba nu goed is voor wat m'n dagelijks gebruik is (0,5~8GB file copies) wil ik de cygwin methode evt. zo ook nog wel even gaan proberen voor rsync. Zijn er evt. ook alternatieven voor Samba waarmee ik Windows en Mac makkelijk Verkenner/Finder native aan elkaar kan knopen? NFS oid?

[Ben(V)]

Nfs is antiek en op sterven na dood en zal zeker geen verbetering opleveren.
Veel kleine bestanden is gewoon de bottleneck voor alle opties of het nu rsync, smb of welk protocol dan ook is.
Dat zit gewoon in de overhead administratie van al die bestanden.

En Samba is tegenwoordig het native lan protocol van Apple en smb is dat voor Windows natuurlijk altijd al.

Jumbo frames kwamen uit de tijd dat de cpu vele malen trager waren dan zelfs de kleinste cpu's van de huidige generatie en het in en uitpakken van netwerk pakketjes de cpu aan het belasten was, want nu echt peanuts voor een cpu is.

Het enige wat in de toekomst meer snelheid op zou kunnen leveren als Samba "smb multichannel" gaat implementeren (en Apple dat overneemt), Windows heeft dat al beschikbaar sinds smb 3.
Uiteraard moet je dan wel aan beide kanten twee netwerk interfaces hebben en twee kabels aansluiten.
Maar dan nog blijven al die kleine bestanden de bottleneck.

[Voor 3% gewijzigd door Ben(V) op 19-06-2020 11:22]

[Razor_]

Bedankt voor de duidelijke uitleg! Ik heb eerst wel vrede met zoals het nu is. Heb nu iets van 4x snellere Finder transfers en 4,3x snellere rsync. Ook allemaal goede stof om te weten als ik evt. in de toekomst wil gaan upgraden naar 10Gbps+ omgeving.

[vanaalten]

Ben(V) schreef op vrijdag 19 juni 2020 @ 11:20:
Nfs is antiek en op sterven na dood en zal zeker geen verbetering opleveren.

@Ben(V), Het staat wat los van het probleem van TS, maar: hoe zou je dan twee linux-machines aan elkaar koppelen? Ik heb een linux NAS en daarbij een directory via NFS op een andere Linux machine gemount. Ik weet geen betere manier dan NFS voor zo'n situatie - dus als dat op sterven na dood is, wat is daarvoor het alternatief?

[Ben(V)]

Gewoon smb gebruiken.
Elke Linux distributie heeft Samba aan boord.

https://www.linuxnix.com/...mba-file-system-in-linux/

Welk merk Nas heb je?
Als je een Synology heb kun je heel simpel in FileStation een remote folder mounten via de tools pulldown.

[Voor 67% gewijzigd door Ben(V) op 19-06-2020 15:16]

[igmar]

Ben(V) schreef op vrijdag 19 juni 2020 @ 11:20:
Nfs is antiek en op sterven na dood en zal zeker geen verbetering opleveren.

En wat is de onderbouwing hiervan ? Het is nog steeds actueel, en een van de weinige implementaties die brede ondersteuding heeft vanuit diverse OS'sen. Het heeft zeker challenges, vooral op gebied van HA, maar het is verre van dood.

Veel kleine bestanden is gewoon de bottleneck voor alle opties of het nu rsync, smb of welk protocol dan ook is.
Dat zit gewoon in de overhead administratie van al die bestanden.

Je kan vrij veel tunen. Is het optimaal : Nee, zeker niet.

[Ben(V)]

Het door Sun ontworpen en volledig antieke Nfs wordt enkel op Unix varianten ondersteund juist omdat het zo antiek is.
De default standaard op zowel Windows, Mac als Linux is tegenwoordig smb.

En met tuning het probleem van veel kleine bestanden oplossen is natuurlijk gewoon onzin.
Dat ligt gewoon in de inherente beperkingen van elk filesysteem

[igmar]

Ben(V) schreef op zaterdag 4 juli 2020 @ 21:16:
Het door Sun ontworpen en volledig antieke Nfs wordt enkel op Unix varianten ondersteund juist omdat het zo antiek is.
De default standaard op zowel Windows, Mac als Linux is tegenwoordig smb.

En met tuning het probleem van veel kleine bestanden oplossen is natuurlijk gewoon onzin.
Dat ligt gewoon in de inherente beperkingen van elk filesysteem

Niet echt wat ik in de praktijk zie. Ik zie in de praktijk vooral NFS, en geen SMB. Alle storage providers hebben een volwaardige NFS implementatie. Voor servers die LDAP gebruiken is NFS bijna native, en da's voor SMB wel anders.
Voor client machines is het inderdaad vooral SMB, voor servers zie ik het eigenlijk zelden gebruikt worden.

Tuning is wel degelijk relevant, voor zowel het netwerk gedeelte het onderliggende FS.

[Ben(V)]

Misschien kijk je dan verkeerd, smb is echt de main stream en nfs is op sterven na dood.

[MainframeX]

Ben(V) schreef op woensdag 8 juli 2020 @ 14:03:
Misschien kijk je dan verkeerd, smb is echt de main stream en nfs is op sterven na dood.

Vooral ongefundeerd je mening als waarheid blijven verkondigen. Mij overtuig je er in ieder geval niet mee.

In de praktijk zie ik toch ook dat nfs nog echt _overal_ gebruikt wordt. Vooral op hosting en datacentergebied snijd je stelling helemaal geen hout.

[Ben(V)]

Misschien weet je het nog niet maar de wereld bestaat voor een heel groot gedeelte uit Windows en daar wordt helemaal nooit NFS gebruikt.
En in de Linux wereld is bijna iedereen al lang overgestapt op Samba dus smb en zelfs Apple is afstapt van zijn default AFP naar smb.

En ik heb al heel wat datacenters en de daar aanwezige systemen gezien, maar ben de laatste10 jaar nergens meer een fileserver met Nfs tegengekomen, niet meer sinds de tijden dat er nog Sun servers waren.

[MainframeX]

Ben(V) schreef op woensdag 8 juli 2020 @ 19:17:
Misschien weet je het nog niet maar de wereld bestaat voor een heel groot gedeelte uit Windows en daar wordt helemaal nooit NFS gebruikt.
En in de Linux wereld is bijna iedereen al lang overgestapt op Samba dus smb en zelfs Apple is afstapt van zijn default AFP naar smb.

En ik heb al heel wat datacenters en de daar aanwezige systemen gezien, maar ben de laatste10 jaar nergens meer een fileserver met Nfs tegengekomen, niet meer sinds de tijden dat er nog Sun servers waren.

Als je werkelijk denkt dat ze in de linux wereld overgestapt zijn van nfs naar samba, dan snap je er echt gewoon geen ene hol van. Spreek dat maar eens uit in irc kanaal en dan rolt zo ongeveer iedereen over je heen.

[igmar]

Ben(V) schreef op woensdag 8 juli 2020 @ 14:03:
Misschien kijk je dan verkeerd, smb is echt de main stream en nfs is op sterven na dood.

Als ik naar de grote IT omgevingen kijk is het alles behalve dood. Ik krijg gelijke antwoorden van de grote vendors op dit gebied.

[Ben(V)]

Ik kom in geen enkel datacentrum nog nfs tegen.
SMB is gewoon overal de standaard voor filesharing.

[vanaalten]

Ben(V) schreef op maandag 13 juli 2020 @ 21:33:
Ik kom in geen enkel datacentrum nog nfs tegen.
SMB is gewoon overal de standaard voor filesharing.

Wellicht dat dat meer een kwestie is van in welke 'bubble' je je bevindt. Als je in een snoepfabriek werkt zou je niet kunnen bedenken dat er nog mensen bifi-worst of cherry-tomaatjes als snack wegbunkeren. Wellicht dat als je werkt in een omgeving met veel Microsoft Azure, je de indruk krijgt dat Linux volledig dood is.

Ik zat mij na een vorige opmerking over NFS af te vragen of ik een trend gemist had, dus daarom dit topic begonnen: Toekomst NFS, alternatieven
...en toch genoeg mensen die voor zowel SMB als NFS een toekomst zien.

[jvanhambelgium]

Ben(V) schreef op woensdag 8 juli 2020 @ 19:17:
En ik heb al heel wat datacenters en de daar aanwezige systemen gezien, maar ben de laatste10 jaar nergens meer een fileserver met Nfs tegengekomen, niet meer sinds de tijden dat er nog Sun servers waren.

You got to be kidding right ?
SMB,NFS en object storage hebben nog steeds allemaal evenzeer hun plek in functie van de use-case.