iBook: Ethernet langsam?

[satta]

Hallo!

Habe mal ne Frage:
Ich habe mein iBook (600er, mid-2002) unter OS X 10.2.6 hier per SMB mit meinem FreeBSD-Fileserver verbunden, um dort abgelegte Mediendateien (DivX, MPG, MP3 etc.) abzuspielen.
Ich verwende Fast Ethernet (also 100Mbit/s).
Leider werden vor allem DivX-Filme (per Mplayer) übers Netz sehr langsam abgespielt (Einzelbilder über ca. 5 Sekunden, reine Slideshow!).
MenuMeters zeigt auch nur einen sehr geringen Netzwerkdurchsatz an. Wenn ich die Datei auf die lokale Platte kopiere und dann abspiele, läuft alles in akzeptabler Geschwindigkeit.
Nun meine Frage: Ist unter OS X eine Verbindung per SMB wirklich SO langsam? Ein Linux-Notebook, das die gleiche Share gemountet hat, erreicht da ungeahnte Geschwindigkeiten.
Wird evtl. das BS durch den Netzwerkzugriff derart ausgelastet, dass eine Wiedergabe verzögert wird? Das iBook 600 scheint mir im Allgemeinen ohnehin recht träge zu reagieren (z.B. beim Scrollen durch SMB-gemountete Verzeichnisse in der Listen- oder Spaltenansicht). Das nervt ungemein, wenn man bedenkt, dass bei Fast Ethernet theoretisch zumindest mehrere MB/s drin sein müssten.
Wenn es an SMB liegt, gibt es Alternativen, und hat jemand Erfahrung damit (NFS oder netatalk). Vor allem würde mich die clientseitige Einrichtung von AppleTalk unter OSX interessieren (komme aus der DOS- und Unixwelt und habe daher bisher noch nichts mit diesem Apple-Zeug zu tun gehabt :-()

Danke schon einmal für Antworten,
Satta

P.S. Die üblichen Verdächtigen, wie z.B. kaputtes 10/100-Autosensing bei der (würg) Realtek-Karte auf dem Fileserver habe ich schon ausgeschlossen.

 

[abgemeldeter Benutzer]

Es liegt am SMB.
SMB ist allgemein langsam (Samba ist ein nachprogrammiertes Microsoft-Protokoll)
Zusätzlich wird es dadurch, dass der Mac mit Metadaten arbeitet, die SMB nicht liefert, gebremst. Außerdem ist SMB als x86-Protokoll Little-Endian, dass heißt dass für den Mac, der Big-Endian ist, sämtliche Bytes einmal umgedreht werden müssen.
Netatalk als Implementation des nativen Mac-Filesharing-Protokolls AppleTalk und NFS als UNIX-FileSharing-Protokoll sind sicher die bessere Alternative.
Cleintseitig gibt es bei AppleTalk nichts einzurichten, man verbindet sich mit dem Server, welcher in der Liste angezeigt wird. (Wie immer bei dem Apple-Zeug)

Zum Abspielen von Mediadateien über Netzwerk bietet sich VLC an. Der baut selber ftp- oder http-Verbindungen auf.


P.S. die Trägheit von OS X beschränkt sich auf die Benutzeroberfläche. die Internen Vorgänge laufen fix.

 

[satta]

Danke. Dann weiss ich ja jetzt Bescheid. Um Samba werd ich wohl auf dem Server nicht herumkommen, da auch Dosenclients bedient werden sollen (Mitbewohner mit PC).
Werd mich dann mal mit Netatalk beschäftigen. Ist auch in den FBSD-Ports vorhanden. Mal sehen, was es so an Doku gibt...

Gruss,
Satta

 

[satta]

So, hab jetzt Netatalk laufen und die Geschwindigkeit hat sich in der Tat vervielfacht.
Leider werden jetzt aber auf dem gemounteten Share nur noch Dateien angezeigt, deren Namen kürzer als 32 Zeichen sind. Alle Dateien mit längeren Namen sind so nicht mehr erreichbar. Ich vermute, dass das historische Gründe hat (Beschränkung unter OS9 und früher?). Ist es irgendwie möglich, Netatalk so zu konfigurieren, dass das nicht mehr berücksichtigt wird (habe nur meinen OSX-Client). Oder ist dies eine Eigenart des verwendeten Protokolls und nicht konfigurierbar?

Vielleicht hat hier ja einmal jemand sich damit beschäftigt und kann mir weiterhelfen. Ansonsten bleibt mir nur noch, die Dateien periodisch zu prüfen und die Namen wenn erforderlich zu verkürzen (per Skript) oder NFS zu verwenden (was jedoch wieder zu Firewall-Gefrickel führt, da der Fileserver zugleich auch DSL-Router ist und ich nicht meine NFS-Shares dem Internet bereitstellen will).

Gruss,
Satta

 

[abgemeldeter Benutzer]

Original geschrieben von satta
So, hab jetzt Netatalk laufen und die Geschwindigkeit hat sich in der Tat vervielfacht.
Leider werden jetzt aber auf dem gemounteten Share nur noch Dateien angezeigt, deren Namen kürzer als 32 Zeichen sind. Alle Dateien mit längeren Namen sind so nicht mehr erreichbar. Ich vermute, dass das historische Gründe hat (Beschränkung unter OS9 und früher?). Ist es irgendwie möglich, Netatalk so zu konfigurieren, dass das nicht mehr berücksichtigt wird (habe nur meinen OSX-Client). Oder ist dies eine Eigenart des verwendeten Protokolls und nicht konfigurierbar?

Bei AppleShare zwischen zwei Mac OS X-Rechnern besteht diese Beschränkung nicht. Es liegt also entweder an der netatalk-Implementation von AppleShare oder es ist irgendwo in den configdateien so eingestellt worden.

P.S. Gibt es für BSD eigentlich mittlerweile einen auf Apples AppleFileServer-Sourcen basierenden AppleShare-Server?

P.P.S. Die Beschränkung auf 32 Zeichen bezieht sich tatsächlich auf Mac OS 9, dessen Finder nur 32 Zeichen lange Dateinamen darstellen konnte. Was wiederum daher kam, dass HFS nur 32 Zeichen lange Dateinamen kannte. Bei AppleShare von einem Mac OS X Server stellt Mac OS 9 jedoch die Dateinamen, die länger, als 32 Zeichen sind trotzdem dar, zeigt aber nur 25 Zeichen plus eine Prüfsumme bestehend aus einer # und 5 Zeichen. HFS+ und der Mac OS X Finder kennen 255 Zeichen lange Dateinamen.