Datentransfer zu langsam

[pHiLiPp]

Hallo,
ich habe ein Problem mit dem Datenstransfer vom iMac zum PC (WinXP). Beide Computer sind per Netzwerk verbunden.

Wenn ich Dateien vom PC auf den iMac ziehe, habe ich eine Transferrate von 10MB/s. Das ist meines Wissens nach für ein Netzwerk normal oder zumindest ausreichend.
Will ich jedoch Dateien vom iMac auf den PC schieben, dann bekomme ich höchstens eine Transferrate von 20KB/s zu Stande.

Pinge ich die beiden Computer gegenseitig an, so sind die Zeiten normal (hat das damit überhaupt was zutun?).

Könnt ihr mir eventuell auf die Sprünge helfen?

Gruß, Philipp

 

[petjek]

Da kann ich mich anschliessen. Allerdings liegt das Problem bei mir ein bischen anders.
Ich kann von beiden Rechnern aus Daten vom Mac zum PC mit voller Bandbreite übertragen. Keine Ahnung wie schnell das nun wirklich ist aber ein CD-Image braucht nur ein paar Minuten.
Wenn ich aber Daten vom PC zum Mac übertragen will kann könnte ich k_tzen. 16h für 700MB sind da kein Problem.
Ich habe zudem auch noch ein olles Laptop mit Win2k im Netz. Da kann ich aus allen Richtugnen drauf hoch- & runterladen, kein Problem.
Alle Rechner hängen per Kabel (100MBit) am Netgear FM114P-Router. Das Laptop auch mal per WLan aber nicht wenn ich wirklich Daten übertragen will.
Hab schon mal in einem anderen Forum das Problem geschildert und bis jetzt leider keinen Hinweis bekommen.
Hier vielleicht?

Gruß, petjek

 

[petjek]

Ne, die Anderen waren schneller )

sudo sysctl -w net.inet.tcp.delayed_ack=0

im Terminal ausführen und wundern. Keine Ahnung was da passiert aber es wirkt.

Gruß,
petjek

 

[pHiLiPp]

Ich habe es selber noch nicht ausprobiert.

Könnte eventuell jemand erklären, was da gemacht wird? Ich würde gern wissen, was genau ich da eigentlich eintippe, wenn ich es eintippe...

 

[Cyrics]

anscheinend wird da sysctl genutzt. Damit kann man Werte im Kernel ändern. mit dem Attribut -w wird genau das eingeleitet...
dann wird irgendwie eine net.adresse reingesetzt und die Wartezeit bis zum Auruf dieser auf 0 gesetzt...

ich weiss nun nicht was der Standardwert ist... aber vielleicht verweist es auf irgendeine Seite mit einer bestimmten Wartezeit... wenn nun ein Netzwerkzugriff kommt, dann wartet es immer diese Zeit ab und arbeitet dann weiter... mit dem sysctl setzt man diese Wartezeit auf 0. So versteh ich das. Also eigentlich nichts böses bei.

 

[thrillseeker]

ich weiss nun nicht was der Standardwert ist...

Der Standardwert ist offensichtlich "1".

Ich habe nämlich auf meinem PowerBook an diesem Wert bisher nichts verändert, und sysctl -A zeigt mir an:
net.inet.tcp.delayed_ack: 1

Sorry -- mehr kann ich dazu nicht sagen - bin im Terminal nämlich auch nicht besonders fit. Mehr Infos bekommt man allerdings in der manpage (man sysctl).

 

[electribus]

hi,

was benutzt du für ein protokoll? smb? aus eigener erfahrung liegt es daran. smb ist nicht so der hin in sachen speed und stabilität bei größeren dateien.

als lösung solltest du ftp in betracht ziehen. nutzen kannst du ftp zwischen 2 computern im netzwerk mittels "filezilla server" (pc) und mac os x kann das von haus aus. ip-adressen vergeben, benutzernamen & passwörter bleibt gleich.

seitdem ich ftp/sftp nutze, läuft alles sehr stabil und schnell.

 

[QuickMik]

ich kann nicht verstehen, warum man das sharing überhaupt auf beiden kisten freigibt?
man kann ja nicht nur "hin" schieben sondern auch "her" ziehen.
sollte aber nur ein tipp sein...

 

[Trapper]

Könnte eventuell jemand erklären, was da gemacht wird? Ich würde gern wissen, was genau ich da eigentlich eintippe, wenn ich es eintippe...

Dieses Kommando schaltet wohl die Funktion "Delayed ACK" von TCP ab. Zum Verständnis dieser Funktion muss man wissen, dass TCP ein sicheres Protokoll ist. Es garantiert, dass verloren gegangene Pakete erneut gesendet werden. Dies wird durch Bestätigungsmeldungen (sog. ACKs) erreicht. Eine weitere Eigenschaft von TCP ist, dass diese ACKs in normalen Datenpaketen transportiert werden. "Delayed ACK" bedeutet nun, dass der Rechner nach dem Empfang eines Pakets max. 200ms wartet, bevor er ein eigenes ACK-Paket erzeugt. Die Wahrscheinlichkeit ist groß, dass innerhalb der 200ms ein weiteres Paket ankommt, dass gleich mit bestätigt werden kann oder der Rechner selbst Daten sendet und somit das ACK "huckepack" auf dem Datenpaket reitet.

Damit wird also die Zahl separater ACK-Pakete minimiert. Andererseits kann sich der End-to-end-Delay dadurch erhöhen. Ausschalten und sehen was passiert sollte also keinerlei Probleme mit sich bringen.

 

[Alex P.]

Ich habe das Problem das ich über eine 10mbit Leitung mit sftp nur ca. 400kb/s rüberbekomme! Benutze Cyberduck, und mit ftp bekomme ich volle 1000kb/s...
Der sftp-server ist ein Debian, und mit Windows und Filezilla gehen 1000kb/s rüber!!!

Woran liegt das???

Danke und Grüße

Alex P.

PS: CPU-Last liegt bei 60-70% während des Vorganges...

PPS: mit einem anderen Programm (Transmit) auch keinen Unterschied!

 

[QuickMik]

PPS: mit einem anderen Programm (Transmit) auch keinen Unterschied!

schon mal yummy versucht?
der soll auch flott sein.

 

[skywalker]

tja die tiefen von mac os.
danke für den tip mit dem parameter net.inet.tcp.delayed_ack.
auf meinem mini war der auf 3.
jetzt nachdem ich ihn auf 0 gesetzt habe bekomme ich die gleichen transferraten beim verschieben von daten auf smb-freigaben des mini.
klasse !

 

[Alex P.]

Auch mit yummy Fehlanzeige, oder besser, keine Änderung...

An dem Parameter, auch wenn er bei mir scheinbar auf sieben steht, liegt es leider nicht!

Noch Ideen???

PS: das Problem besteht nur bei SSH bzw. SFTP Verbindungen!

 

[Danyow]

Auch mit yummy Fehlanzeige, oder besser, keine Änderung...

An dem Parameter, auch wenn er bei mir scheinbar auf sieben steht, liegt es leider nicht!

Noch Ideen???

PS: das Problem besteht nur bei SSH bzw. SFTP Verbindungen!

Ähm...
Dir ist klar, daß das S in SSH und SFTP für secure, also verschlüsselte Datenübertragung steht?

Will heißen:
Was auch immer Du darüber überträgst möchte erst ver- und anschließend entschlüsselt werden und da sind die von Dir genannten Transferraten garnicht mal schlecht.

Gruß

D

P.S.:
Das hat mit Dateifreigaben übrigens nichts zu tun, deswegen wäre es eigentlich schöner gewesen, hättest Du für Deine Frage einen neuen Thread aufgemacht...