Netatalk ist langsam

kasy

Rouge
Hallo,
habe folgendes problem mit meinem Fileserver:
Wenn ich mich von OS-X auf meinen Fileserver verbinde, ist die verbindung Zwar recht schnell, 600MB ca. 30 sekunden, doch wenn ich eine Datei übers netz öffne dauert das Bei 20MB Illu Datei ca. 10 Minuten... hab keine Ahnung woran das liegen könnte

aufgefallen ist mir bei nem ping an localhost, das da 17% packet loss sind,
is das normal? Können irgendwelche geräte die verbindung zum localhost stören?
Code:
>ping -f 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
............................
--- 127.0.0.1 ping statistics ---
1447 packets transmitted, 1194 packets received, 17% packet loss
round-trip min/avg/max/stddev = 0.038/0.106/12.436/0.715 ms

hier noch n paar infos nachden ihr immer fragt wo ich leider nicht wirklich was mit anfagen kann =))

Code:
> uname -am
FreeBSD andromedar.kassiopeia 5.4-RELEASE-p7 FreeBSD 5.4-RELEASE-p7 #1
Code:
> netstat -m
530 mbufs in use
512/17088 mbuf clusters in use (current/max)
0/4/4528 sfbufs in use (current/peak/max)
1156 KBytes allocated to network
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
9 calls to protocol drain routines
Code:
> netstat -i
Name    Mtu Network       Address              Ipkts Ierrs    Opkts Oerrs  Coll
em0    1500 <Link#1>      00:e0:81:56:fa:0c   429428     0   292232     0     0
em0    1500 192.168.1     andromedar          428534     -   312867     -     -
em0    1500 fe80:1::2e0:8 fe80:1::2e0:81ff:        0     -        6     -     -
em0    1500 atalk:65280-65534  65280.10            -     -        -     -     -
em1    1500 <Link#2>      00:e0:81:56:fa:0d        0     0        0     0     0
em1    1500 192.168.1     server.buk               0     -        0     -     -
em1    1500 fe80:2::2e0:8 fe80:2::2e0:81ff:        0     -        5     -     -
plip0  1500 <Link#3>                               0     0        0     0     0
lo0   16384 <Link#4>                           24170     0    24170     0     0
lo0   16384 your-net      localhost.buk         3496     -     3496     -     -
lo0   16384 localhost.buk ::1                      0     -        0     -     -
lo0   16384 fe80:4::1     fe80:4::1                0     -        0     -     -
lo0   16384 atalk:0            0.0                 -     -        -     -     -
Code:
> ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=b<RXCSUM,TXCSUM,VLAN_MTU>
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        inet6 fe80::2e0:81ff:fe56:fa0c%em0 prefixlen 64 scopeid 0x1 
        atalk 65280.10 range 65280-65534 phase 2 broadcast 0.255
        ether 00:e0:81:56:fa:0c
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=b<RXCSUM,TXCSUM,VLAN_MTU>
        inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
        inet6 fe80::2e0:81ff:fe56:fa0d%em1 prefixlen 64 scopeid 0x2 
        ether 00:e0:81:56:fa:0d
        media: Ethernet autoselect
        status: no carrier
plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000 
        inet6 ::1 prefixlen 128 
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 
        atalk 0.0 range 0-0 phase 2

hoffe Ihr habt ne idee, und danke schonmal für den huth und die hilfe :)
 
danke für die Antworten :)

An was für einen Switch hast du die Kiste hängen? Manche Switche mögen Autosensing nicht wirklich...
Noname 10/100 Switch, die OS-X Rechner mit Autosensing stören sich da nicht dran, ka ob FBSD da anders handelt.

Riecht nach Kabelbruch oder schlechter Hardware.
denke auch, werd mal die Kiste direkt an n anderen Switch hängen mit neuen kabeln, mal sehen was er dann sagt.

packetloss auf dem lo0-interface? o_O

von sowas hab ich nicht nie gehört

interupts?
versuch da was rauszubekommen, weiss net wie ich das nachschau ;)
 
kasy schrieb:
Hallo,
habe folgendes problem mit meinem Fileserver:
Wenn ich mich von OS-X auf meinen Fileserver verbinde, ist die verbindung Zwar recht schnell, 600MB ca. 30 sekunden, doch wenn ich eine Datei übers netz öffne dauert das Bei 20MB Illu Datei ca. 10 Minuten... hab keine Ahnung woran das liegen könnte

Bei mir ist die netatalk Performance auch sehr mies. Ftp, Samba und SFtp rennen wie sau, aber netatalk hat einen Durchsatz von vielleicht 200 kb/s zum G5 und iBook mit jeweils Tiger.


kasy schrieb:
aufgefallen ist mir bei nem ping an localhost, das da 17% packet loss sind,
is das normal? Können irgendwelche geräte die verbindung zum localhost stören?
Code:
>ping -f 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
............................
--- 127.0.0.1 ping statistics ---
1447 packets transmitted, 1194 packets received, 17% packet loss
round-trip min/avg/max/stddev = 0.038/0.106/12.436/0.715 ms

Der Kernel von FreeBSD und OS X limitiert die Anzahl der empfangenen Packete, daher der Paketverlust:

Code:
root@marvin# ping -f 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
......................................................................................^C
--- 127.0.0.1 ping statistics ---
484 packets transmitted, 398 packets received, 17% packet loss
round-trip min/avg/max/stddev = 0.056/0.065/0.313/0.015 ms

root@marvin# dmesg
[...]
Limiting icmp ping response from 244 to 200 packets/sec
Limiting icmp ping response from 245 to 200 packets/sec



Ich komme mit dem Problem allerdings auf keinen grünen Zweig. Hat sonst noch jemand ein Performanceproblem mit netatalk? Auf Debian ist es ganz flott gelaufen, aber meine FreeBSD Kiste will ich ungern aufgeben.
;)


UPDATE: Schreiben klappt komischerweise sehr gut (>5 MB/sec). Ich habe auch schon drei Netzwerkchipsätze durchprobiert. Keine Besserung.
 
Zuletzt bearbeitet:
Also, ich glaube ich habe den Fehler gefunden. Warum nich früher? Wahrscheinlich Dummheit...

1.) Mac OS X scheint im Gegensatz zu OS 9 irgendwelche Daten über AppleTalk nicht so zu mögen, deswegen hatte ich schon ziemlich von Anfang an in der "/usr/local/etc/rc.d/netatalk.sh" die AppleTalk Dienste gekillt:

Code:
[...]
# other processes.
#

netatalk_enable=${netatalk_enable-"YES"}
atalkd_enable=${atalkd_enable-"NO"}
papd_enable=${papd_enable-"NO"}
cnid_metad_enable=${cnid_metad_enable-"NO"}
afpd_enable=${afpd_enable-"YES"}
timelord_enable=${timelord_enable-"NO"}
[...]

2.) Allerdings hatte ich in "/usr/local/etc/afpd.conf" den Parameter "-transall" drin. D.h. AppleTalk und TCP. seit "-noddp -tcp" drinsteht, rennt das Ding ganz schön flott (>7 MB/sec).
 
Zuletzt bearbeitet:
hi,
danke für die info, werds am Dienstag mal versuchen, da ich vorher nicht in der Firma bin, hoffe es hilft :)
 
kasy schrieb:
Code:
>ping -f 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
............................
--- 127.0.0.1 ping statistics ---
1447 packets transmitted, 1194 packets received, 17% packet loss
round-trip min/avg/max/stddev = 0.038/0.106/12.436/0.715 ms

Nix für ungut, aber mein FreeBSD hat das selbe "Problem".

Code:
icecube# ping -f 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
[...]
--- 127.0.0.1 ping statistics ---
1908 packets transmitted, 1393 packets received, 26% packet loss
round-trip min/avg/max/stddev = 0.069/0.078/1.250/0.043 ms

icecube# uname -mrs
FreeBSD 6.0-BETA5 i386

Dagen meine Linux Box.

Code:
acex5@struct ~ $ sudo ping -f 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.

--- 127.0.0.1 ping statistics ---
2366584 packets transmitted, 2366584 received, 0% packet loss, time 295833ms
rtt min/avg/max/mdev = 0.004/0.008/168.794/0.213 ms, pipe 3, ipg/ewma 0.125/0.008 ms

acex5@struct ~ $ uname -mrs
Linux 2.6.12-gentoo-r10 i686

Das scheint mir eher ein Problem vom Flood-Ping unter FreeBSD zu sein. Ein Hardware-Fehler kannst du nur durch ansprechen von realer Hardware erreichen. Mit ping 127.0.0.1 testest du maximal den TCP/IP Stack.

Wenn du deine dmesg durchschaust, wirst du auch dahinter kommen, warum dir Pakete verloren gehen.

Code:
Limiting icmp ping response from 282 to 200 packets/sec
Limiting icmp ping response from 282 to 200 packets/sec
Limiting icmp ping response from 282 to 200 packets/sec
 
Zuletzt bearbeitet:
Zurück
Oben