AppleTalk / Linux bonding.o zu langsam

P

Puste-Blume

Mitglied
Thread Starter
Dabei seit
02.09.2004
Beiträge
20
Reaktionspunkte
0
Hat jemand schon mal mehr als 3mb/sec mit netatalk übers Netzwerk geschafft ?

Ich setze als Server Debian mit netatalk 1.6.4 ein ( 4x3com 100 FDX mit bonding.o ).
Verbinde ich den Mac per nfs komme ich auf 25mb/sec ( ist o.k., da dann die HDU den geist aufgibt ). Hat sich jemand schon mal mit der Problematik auseinander gesetzt ?
Danke.

Gruss
Puste-Blume
 
Das Apple Talk-Protokoll ist veraltet und bekanntermaßen sehr langsam.
Das liegt u. a. an der Art der Kolissionskontrolle (Kolissionsvermeidung anstelle von Kolissionserkennung), die dazu führt, dass immer nur eine Station gleichzeitig senden kann und dies vorher ankündigen muss.
 
Außerdem implementiert netatalk eine Uralt-Version von Apple Talk aus System 7 (oder noch älter). NFS ist schon die richtige Wahl um OS X mit Linux zu verbinden. Also, wenn Du keinen System-7.x-Mac im Netz versorgen musst, dann schmeiß netatalk einfach raus.
 
Zuletzt bearbeitet von einem Moderator:
._ut schrieb:
Außerdem implementiert netatalk eine Uralt-Version von Apple Talk aus System 7 (oder noch älter). NFS ist schon die richtige Wahl um OS X mit Linux zu verbinden. Also, wenn Du keinen System-7.x-Mac im Netz versorgen musst, dann schmeiß netatalk einfach raus.

netatalk implementiert das brandaktuelle AFP2.0 und rechtfertigt u.a. seine Existenz (trotz OS X) u.a. damit, daß es deutlich schneller sei als Samba. Generell sollte man allerdings eine so alte netatalk-Version meiden und auf die stabile 2.0 zurückgreifen.

NFS ist natürlich "das" unixoide Netzwerk-Filesystem, allerding finde ich persönlich das Rechte-Management inakzeptabel UND schwierig. Ich habe jedenfalls mit NFS, OSX-Clients und Debian-Servern noch nie ein schreibend-und-lesen-für-alle-Gastvolume hinbekommen.


Ich würde vorschlagen, in die netatalk-Mailingliste zu schreiben. Die Hilfe dort ist sehr schnell und kompetent.

Gruß, Ratti
 
ratti schrieb:
netatalk implementiert das brandaktuelle AFP2.0
...
Weisst Du zufällig, welche Methode der Kolissionskontrolle hier verwendet wird ?
Läuft das überhaupt noch auf AppleTalk oder inzwischen auch auf TCP/IP ?
 
maceis schrieb:
Weisst Du zufällig, welche Methode der Kolissionskontrolle hier verwendet wird ?
Läuft das überhaupt noch auf AppleTalk oder inzwischen auch auf TCP/IP ?

TCP.

Das einzige, was noch nebenherläuft, sind die DDP-Geschichten, um z.B. den Namen im Netz zu publizieren. Ohne die werden die Kisten nicht automatisch aufgelistet. Aber das braucht der OS X Server auch.
 
ratti schrieb:
netatalk implementiert das brandaktuelle AFP2.0
Heiho, das ist neu.
Wurde aber auch langsam mal Zeit, wo Apples Implementation schon ein paar Jahre OpenSouce ist.
 
Das Problem was ich aber auch mit netatalt 2.0 sehe, ist der port-channel von 4x100mbit.
Alles was ich bislang gelesen habe, geht netatalt nicht mit bonding.o
 
@ ratti
Vielen Dank für die Info.
Was die Verwendungen von DDP bei OS X angeht, so ist das meines Wissens nicht ganz richtig.
Spätestens ab OS 9 kann auf DDP komplett verzichtet werden. Dies ist auch sinnvoll, da DDP Unmengen von Broadcasts versendet, die eigentlich nicht wirklich gebraucht werden und speziell in größeren Netzen problematisch werden können.
Bei OS X werden Rechnernamen und Dienste afaik über Multicasts publiziert (mDNSResponder bzw. Rendevouz), die mit wesentlich geringerem Datenverkehr aufwarten.
Wie das aussieht, wenn man zusätzlich Apple Talk aktiviert, weiss ich nicht genau (müsste man bei Interesse mal testen).
 
Zuletzt bearbeitet:
Zurück
Oben Unten