AppleTalk / Linux bonding.o zu langsam

Dieses Thema im Forum "Mac OS X - Unix & Terminal" wurde erstellt von Puste-Blume, 04.12.2004.

  1. Puste-Blume

    Puste-Blume Thread Starter MacUser Mitglied

    Beiträge:
    20
    Zustimmungen:
    0
    MacUser seit:
    02.09.2004
    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
     
  2. maceis

    maceis MacUser Mitglied

    Beiträge:
    16.647
    Zustimmungen:
    596
    MacUser seit:
    24.09.2003
    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.
     
  3. 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 von einem Moderator bearbeitet: 05.12.2004
  4. ratti

    ratti MacUser Mitglied

    Beiträge:
    1.515
    Zustimmungen:
    56
    MacUser seit:
    09.05.2004
    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
     
  5. maceis

    maceis MacUser Mitglied

    Beiträge:
    16.647
    Zustimmungen:
    596
    MacUser seit:
    24.09.2003
    Weisst Du zufällig, welche Methode der Kolissionskontrolle hier verwendet wird ?
    Läuft das überhaupt noch auf AppleTalk oder inzwischen auch auf TCP/IP ?
     
  6. ratti

    ratti MacUser Mitglied

    Beiträge:
    1.515
    Zustimmungen:
    56
    MacUser seit:
    09.05.2004
    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.
     
  7. Heiho, das ist neu.
    Wurde aber auch langsam mal Zeit, wo Apples Implementation schon ein paar Jahre OpenSouce ist.
     
  8. Puste-Blume

    Puste-Blume Thread Starter MacUser Mitglied

    Beiträge:
    20
    Zustimmungen:
    0
    MacUser seit:
    02.09.2004
    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
     
  9. maceis

    maceis MacUser Mitglied

    Beiträge:
    16.647
    Zustimmungen:
    596
    MacUser seit:
    24.09.2003
    @ 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: 07.12.2004
Die Seite wird geladen...

Diese Seite empfehlen