Durchsatz Heimnetzwerk

[Insulaner]

Die 40MB/s ist der Durchsatz, der gemessen worden ist.

Wenn die Interfaces sich nicht verständigen können und die Physik nicht stimmt, dann führt das in der
Regel zu Interfaces-Fehlern. Diese Fehler führen
1. zu Retransmitts
2. zu einem Herunterregeln der WindowsSize

Insgesamt ist das Resultat ein absinken des Netto-Durchsatzes.

 

[ottomane]

Das sind m.E. zwei Paar Schuhe. Wenn die Autonegotiation fehlschlägt, habe ich z.B. nur 100 Mbit/s statt 1Gbit/s, aber nicht 400Mbit/s. Wenn hingegen z.B. ein Kabel fehlerhaft ist, kommt es zu Retransmits usw.

Letzteres kann natürlich die Ursache für ersteres sein. In diesem Fall hat aber die Autonegotiation auf 1Gbit/s geklappt, sonst hätten wir nicht die 400Mbit/s sondern 100Mbit/s.

Fazit: Autonegotiation klappt. Entweder stört ein Kabel oder ein Interface (Physik) oder eine/beide der beteiligten Komponenten schaffen nicht mehr.

Die Messung erfolgt gegen ein (vermutlich sehr mittelmäßiges) NAS mit mehr oder weniger gut von Apple und Zyxel implementierten Anwendungsprotokollen, das sollten wir bedenken. Ockhams Razor sagt mir, dass es klug ist, hier mit der Suche zu beginnen.

 

[Insulaner]

Das ist leider nicht so.
Es gibt Chipsätze, wo die Autonegotioation eben nicht klappt.
Und dann hat man eben nicht die niedrigere Bandbreite, sondern es funktioniert halt NICHT.

Das Resultat sind eben, wie ich geschrieben habe, Paketfehler auf dem Physical-Layer.
Solange man dann nicht versucht, die Interfaces manuell irgendwie abzustimmen, geht
die Performance baden. Mit den von mir oben beschriebenen Mechanismen.
Man mag es gleuben oder nicht.
Wir haben das in unserem Unternehmen genügend recherchiert.

 

[Wuchtbrumme]

ich kann nichts gegen Schrott machen. Fakt ist, in Gigabit ist Autonegotiation mandatory und meine Netzwerkkollegen bestätigen mir, dass sie nur noch Autoneg on als Default verwenden - bei FastEthernet war die fixe Einstellung standard. Anyway, 40MBps sind eine wenngleich niedrige, aber doch normale Geschwindigkeit unter Verwendung langsamer Komponenten, nicht etwa die Geschwindigkeit, die man bei einem Duplex Mismatch erwarten kann (zumal ja lesend auch mehr erreicht wird, wenn ich das oben richtig im Kopf habe). Wir können also von der überflüssigen, weil hier unnötigen Fachsimpelei an der Stelle abkehren und uns wieder dem TE widmen.

 

[frameworker]

Also auf dem NAS sehe ich bspw. folgendes:

/etc $ ifconfig -a
egiga0    Link encap:Ethernet  HWaddr 5C:F4:AB:65:74:DA  
          inet addr:192.168.2.101  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6667057 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3944237 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3637274132 (3.3 GiB)  TX bytes:910132672 (867.9 MiB)

Wo kann man noch schauen?

 

[ottomane]

Damit scheidet die Theorie "schlechte physikalische Bedingungen" als Fehlerquelle also aus, zumindest wenn du da nicht noch einen Switch dazwischen hattest. Somit alles wie erwartet :/

 

[Insulaner]

An ottomane:

Ich hab da mal ne Frage bzgl. des Erkennens von TX-Fehlern:
Welche TX-Fehler werden hier erkannt. Ich kenne aus den Ethernet-/Fastethernet-Szenarien nicht,
dass alle Sende-Fehler beim Sender erkannt werden können.
Gibt es bei Gigabit irgendwelche Informationen, die zwischen den Layer-2-Interfaces ausgetauscht werden,
die dem sendenden Interface mitteilen, dass beim Senden auf der anderen Seite etwas schief gegangen ist,
so dass alle TX-Fehler dargestellt werden?

 

[frameworker]

Noch ein letztes Update hierzu: Ich hab nicht locker gelassen, mittlerweile wird ja das NAS520 in Deutschland offiziell gar nicht mehr angeboten. Ich bekomme seitens Zyxel Support das NAS520 in ein NAS542 getauscht, da man sich technisch nicht in der Lage sieht die beworbenen 80MB/s Writespeed auf dem 520 zu erreichen. Das 542er hat einen anderen Chipsatz, beworben bei RAID5 (!) mit 79 (warum eigentlich nicht round about 80?) MB/s Write.
Diesmal steht auf der Webseite für beide Vorgänge Read/Write vorher "up to" - gut, das ist jetzt Wortklauberei, ich bin jedenfalls mal gespannt ob ich da bei meiner simplen NAS-Switch-IMac Konfiguration bessere Schreibwerte erreiche als wie mit dem 520er.

Letzte Bemerkung dazu: Ich sehe halt nicht ein, das ich bei Gigabitverkabelung einen Wert noch unterhalb FW800 erreiche, so hatte ich mir die neue Medienwelt im Heimnetzwerk nämlich nicht vorgestellt.

 

[frameworker]

Und hier noch ein Update für alle Interessenten: Ich habe nun ein NAS542 und das funktioniert genauso gut und schlecht wie das NAS520.
Ich habe nun auch ein Windows 10 Lenovo G70 - also durch aus schon betagtes Modell - hier und es ist unglaublich: Dieselbe Verkabelung, derselbe Weg Rechner-Switch-NAS, und man kann eine 1GB große Datei auf das NAS in weniger als 15 Sekunden schreiben (80-100MB/s) wofür AFP oder SMB (ohne Signierung) auf dem Mac doppelt solange brauchen, was den im Thread ganz am Anfang aufgeführten Write-Geschwindigkeiten um die 35-40MB/s entspricht.
Wie macht das Windows? Wieso werden nur dort die vom Hersteller kolportierten Richtwerte auch tatsächlich erreicht?
Ich habe mir noch mal alles durchgelesen, es gab ja die eine oder andere Rückmeldung das gute Write Performance mit Synology Geräten erreicht wird, ich verstehe nur nicht wo da die Abhängigkeit ist.

Der letzte Test wäre eine Windows 10 Bootcamp Installation auf der iMac 9.1 Hardware, aber ich glaube das geht nur bis Win7 oder?

 

[access]

Welchses Protokoll wird denn da benutzt? Samba?

 

[frameworker]

Ja, auch, steht oben (SMB). Das ist aber völlig egal. Auch bei SAMBA mit signing_required=no bleibt der Schreibdurchsatz mies.

 

[frameworker]

Mir lässt das keine Ruhe, ich experimentiere mal mit eigenen Routinen (POSIX) aber was der Kernel macht ist natürlich nicht änderbar. Die Wahrheit ist momentan aber auch, das es ja *zig* verschiedene Möglichkeiten gibt Dateihandling zu betreiben, da bleibt ja kein Auge trocken wenn man da mal in der Apple Dokumentation stöbert.
Aber wahrscheinlich war ich einfach zu blöd um dies hier zu erkennen:
https://www.linkedin.com/pulse/apple-os-x-cant-handle-standard-filesystems-protocols-craig-hubley

Da ist schon ein Körnchen Wahrheit dabei.
Der Artikel sagt einfach genau was Sache ist, ich möchte den Mac mit aktuellem Yosemite+ System sehen, welches nachweislich im Vergleich mit Windows auf ein NAS mit 80MB-100MB/s schreiben kann. So richtig glaube ich das nämlich nicht.
Es ist wohl so, das sehr viele Nutzer den Unterschied beim Kopieren von bspw. 1GB über 30Sekunden vs. 12 Sekunden gar nicht mitbekommen oder das einfach hinnehmen.

Das bringt einen noch zum Wahnsinn - einerseits will man Apple, andererseits wenn solche Backend-Sachen nicht funktionieren, ich fange da als Apple-Jünger der letzten 25 Jahre wirklich daran zu zweifeln.
Das Thema NAS ist natürlich nicht neu, aber ich habe eben erst jetzt Bedarf daran. Aber aufgefallen ist mir das gleich am ersten Tag...

 

[tjp]

Das bringt einen noch zum Wahnsinn - einerseits will man Apple, andererseits wenn solche Backend-Sachen nicht funktionieren, ich fange da als Apple-Jünger der letzten 25 Jahre wirklich daran zu zweifeln.
Das Thema NAS ist natürlich nicht neu, aber ich habe eben erst jetzt Bedarf daran. Aber aufgefallen ist mir das gleich am ersten Tag...

Apple macht seit vielen Jahren Ärger beim Filesharing, und seit dem es auch keine eigenen Server mehr gibt, ist man Apple Willkür total ausgeliefert. Apple supportet weder SMB noch NFS in irgend einer Form brauchbar. Z.B. NFS beinhaltet mittlerweile auch pNFS, aber doch nicht bei Apple.

 

[ottomane]

Ich denke, es kommt auch auf den Server an, den man verwendet. Das sind bei NASen ja in der Regel Linux-Derivate, deren Implementierung zusätzliche Risiken in Bezug auf die Kompatibilität mitbringen.

 

[tjp]

Ich denke, es kommt auch auf den Server an, den man verwendet. Das sind bei NASen ja in der Regel Linux-Derivate, deren Implementierung zusätzliche Risiken in Bezug auf die Kompatibilität mitbringen.

Das Problem ist macOS und nicht Linux. Wenn man NFS betrachtet ist mittlerweile die Referenzimplementation unter Linux realisiert. Fakt ist Apple hat AFP beerdigt und alle Server Hardware aus dem Programm genommen. Man ist nun darauf angewiesen, dass macOS mit einem anderen OS als Fileserver koopeieren kann. Leider verwendet Apple irgend eine verhackstückelte Implementation einer älteren SMB Version und harmoniert aus diesem Grund weder mit SMB noch NFS Server gut. Was soll das? Die proprietäre Erweiterung des SMB Protokolls damit eine Apple eigenen Suche auf dem Fileserver möglich ist, hilft dabei auch nicht. Weshalb wird nicht ein separater Suchserver implementiert und dessen Protokoll frei und offen von Apple publiziert?

Eine solche Lösung würde mit jedem beliebigen Fileserver Protokoll harmonieren z.B. auch einem ClusterFS.

 

[ottomane]

Das Problem ist macOS und nicht Linux. Wenn man NFS betrachtet ist mittlerweile die Referenzimplementation unter Linux realisiert.

Das hat doch gar nichts miteinander zu tun.

Mit Winows-Clients gegen Linux-Samba gibt es auch immer wieder Schwierigkeiten. Ich will Linux da nichts in die Schuhe schieben, aber beide Implementierungen sind leider immer nur "Nachbauten". Leider!

 

[tjp]

Mit Winows-Clients gegen Linux-Samba gibt es auch immer wieder Schwierigkeiten. Ich will Linux da nichts in die Schuhe schieben, aber beide Implementierungen sind leider immer nur "Nachbauten". Leider!

Die Frage ist doch eher, weshalb Apple nicht NFS benutzt? Das Protokoll ist offen und sogar Apple Suchserweiterungen hätten sich über die Jahre integrieren lassen, wenn man einen standardkonformen Weg gesucht hätte. NeXT hat noch standardmäßig NFS genutzt. Es gab für die Übergangszeit (Stichwort Resource Forks) die Notwendigkeit AFP weiter zu nutzen, aber nachdem man das alle entsorgt hat, wäre es sinnvoller gewesen auf ein POSIX Network FS zu setzen. macOS selbst ist auf dem POSIX Design entwickelt. Mir scheint da verlieren einige bei Apple die Übersicht was sinnvoll ist und was nicht.

 

[ottomane]

NFS spielt weder im Home-Bereich noch in der Wirtschaft eine große Rolle, egal wie gut es ist.

 

[franky273]

Kommt auf den Bereich an, bei uns auf Arbeit (Infotainment Softwareentwicklung) wäre Arbeiten ohne NFS nicht möglich... wir entwickeln allerdings auch unter Linux.

 

[tjp]

NFS spielt weder im Home-Bereich noch in der Wirtschaft eine große Rolle, egal wie gut es ist.

Du glaubst doch wohl nicht, dass Twitter, Facebook & Co. SMB auf deren Linux Systemen einsetzen? SMB wurde vor der Entscheidung Apples für SMB nur für Windows Systeme verwendet. Große *I*X oder Linux Installationen laufen i.d.R. mit NFS als Basisnetzwerkfilesystem. Für spezielle Jobs werden anderen FS eingesetzt, für die es weder unter Windows noch macOS brauchbaren Ersatz gibt.