• [gelöscht]

  • Beitrag Nr. 1
Moin Moin,

folgendes Setting:

i7 2600k @ 8 x 4,6Ghz (CPU laeuft stabil 😉)
2 x 4GB DDR3 1600 (Memtest lief 48h, also i.O)
2 x 1920x1080 Displays anner GTX570
Audigy 2
Dazu 6 aktuelle Fesplatten (alle verschlüsselt mit AES) via SATA2 u. 3 ( 1 x 60gb ssd ocz vertex2, 2 x 2TB Samsung , 1 x 1TB Samsung , 2 x 1,5TB Samsung , Badblocks sagt alles fein, Smart sagt 0 Errors (Auf allen Platten)),
GBIt Lan.

Wie ihr seht ein potentes Kerlchen ABER:

Sobald ich was via USB (ca 30MB/s) / NFS (Quelle issn Atom mit cryptet HDD daher nur 10MB/s) kopiere lagt der PC in ca 10-15sekunden Abständen. Besonders schlimm ist es wenn ich von USB kopiere. Verschieb ich die Daten innerhalb der Festplatten (ca 115MB/s) gibts zwar auch lags aber nicht so viele.

Lags: PC bleibt hängen. Das Bild hängt, ein Video was läuft bleibt auch vom Sound stehen.

Problem besteht seit dem 2.6.39er Kernel inkl. aller späteren Updates (atm 3.1.1). Nvidia Treiber schließe ich soweit auch aus, habe schon geupdatet / gedowngraded. Zudem besteht das Problem nur unter Arch (Windows 7, ebenfalls auf der SSD, Fedora15 u. GRML haben das Problem nicht). Ebenfalls auch ohne Overclocking probiert.

Daher denke ich das es am Scheduler liegt. Aber wie kann ich den ändern. Muss ich dafür zwangsläufig den Kernel neu bauen?! Oder gibts Tweaks und Tricks für die FSTAB die das ganze angenehmer macht?!

Hat irgendwer ne Idee?

Grüße
De Oescher-Jong
Dein System läuft außerhalb der Spezifikationen. Da ändern auch irgendwelche Tests ob es stabil ist nicht viel. Es gibt hier einfach zu viele Fehlerquellen. Wer übertaktet usw., sollte das auch wissen und akzeptieren.

Lasse dein System innerhalb der Spezifikationen laufen und schau mal dann mittels top, oder Alternativen ob da was auffällig ist, wenn du USB nutzt. Wäre zumindest ein erster Ansatz.

P.S.:
Quelle issn Atom mit cryptet HDD daher nur 10MB/s)
Verstehe ich nicht. Benutzt zu ein USB zu USB Kabel, oder USB Ethernetadapter, oder was? Erläutere mal den Aufbau genauer.

  • [gelöscht]

  • Beitrag Nr. 3
Hi Star,

danke für die Antwort.

Wenn du genau gelesen hättest:

"Ebenfalls auch ohne Overclocking probiert."

Zudem besteht das Problem _ausschlißelich_, egal ob OC / NonOC bei Archlinux! Top sagt: nichts über 20% beim kopieren.

Daher ja auch IO-Lag und nicht: Habe ungewöhnlich hohe CPU-Last beim kopieren 😉

Die Quelle ist bei NFS angegeben. Ergo wirds wohl ne NFS-Verbindung sein.

  • [gelöscht]

  • Beitrag Nr. 4
Das Problem konnt ich aufm Arbeitspc (C2D 2x2Ghz, 4gb Ram, SSD Gbitlan, gleicher Softwarestand) wiederholen.

Dort half ebenfalls kein Down/Upgrade. Mit GRML wars Problem nicht vorhanden.

Grüße
Wäre evtl. noch interessant, welche Archikektur(i686, x86_64) und welche Dateisysteme.

Ich kann das hier z.B. nicht nachvollziehen, obwohl mein System wesentlich schlechter ist.
Gleichzeitig mit me-tv DVB-S geschaut, nebenbei noch per VLC ein h.264 Video und dann 20GB von meiner externen USB-HD nach /tmp kopiert. Keine "Lags", durchgehende Kopiergeschwindigkeit von ~25MB/s...
Hier x86_64, aktueller Kernel und ext4 als beteiligte FSe.

Als Tools zum messen gäbe es vmstat, iostat ggf. in Verbindung mit top/htop um z.B. evtl. bei einem deiner Hänger zu sehen ob ein aktiver Prozeß die ursache wäre.
bei meinem Test habe ich eine durchscnittliche CPU-last von 62%, ein iowait von ~15-20%.

  • [gelöscht]

  • Beitrag Nr. 6
Danke Gebra für die Antwort.

Der C2D istn 32Bit, der I7 "natürlich" 64bit.

Als FS kommt ausschließlich ext4 (der usbstick vfat) zum zuge.

Dabei ist es egal ob ich unter X bin oder konsole (x ist derweil dann ganz aus) die hänger bleiben.

htop/top sagen immer <20% cpu last auf allen Kernen (normale Hintergrundrauschen wie X / Firefox etc pp)

iotop sagt bisher nur alles rennt gut. iostat und vmstat werd ich mal testen und dann schauen.

Danke und Grüße

  • [gelöscht]

  • Beitrag Nr. 7
Das Problem kommt mir ein wenig bekannt vor aber bei mir ist das normal.

Bei mir laggt das System nur wenn ich von der ersten Festplatte auf die zweite kopiere - oder umgekehrt -, wobei beide Platten intern angeschlossen sind und mit ~70 MB/s durchziehen.

Kopiere ich von USB und/oder NFS kann ich dein Problem nicht nachvollziehen.

Sagen die Logs /var/log/messages und /var/log/syslog irgendwas? Vielleicht liegt ein Problem mit der Hardware vor, so dass das gesamte System sprichwörtlich ausgebremst wird.

  • [gelöscht]

  • Beitrag Nr. 8
Mosche Lin2Core,

auch dir Danke!

Nein logs etc sind vollkommen "leer" was die Sache angeht.

Hab nun ein drittes Gerät mit Lags. Mein T60 verhält sich ebenfalls vollkommen identisch.

Dabei hab ich schon usb-Sticks (ca 11 stück) und usb-hdd gewechselt.

Zudem faellt die Hardware ja nun auch aus. Weil wäre es nur auf einer Kiste okay, aber auf 3 mit völlig unterschiedlicher Hardware (einzige was bei allen 3 gleich ist ist die Tatsache das dort Intel-CPUs verbaut worden sind 😉

Grüße

  • [gelöscht]

  • Beitrag Nr. 9
Ich glaube weniger, dass es an den Intel CPUs liegt. Mein IBM Thinkpad T43 macht keinerlei Mucken, was ggf. an Kubuntu liegen könnte.

Da meine Mutter aber den Laptop zur Zeit noch hat, muss ich mit Archlinux dort erstmal warten ... wobei, die spielt so oder so nur ihre komischen Spiele.

Irgendwas muss die Lags deines Systemes verursachen. Vielleicht doch Intel? Ich wusste es schon immer :-P

Naja, irgendwann findet sich der Wurm und kann eliminiert werden.
Also ich habe das Problem hier auch.

core i3 2100
8GB RAM

Wenn ich auf USB Sticks / oder Festplatten was kopiere, hängt das System auch ab und zu.
Besonders bei USB Sticks an USB 2.0

Weiss nicht mehr genau aber so extrem war das vor einiger Zeit noch nicht (Evtl. liegts ja a Kernel ? )

  • [gelöscht]

  • Beitrag Nr. 11
Hi SID,

jo das hab ich ja oben schon vermutet. Das es der Scheduler im kernel ist.

Andere Distributionen (Hab F15 komplett installiert gehabt, GRML als LiveCD) haben das Problem nicht.

Gibts Kernelalternativen die sich lohnen? ck-Patches sollen ja gan gut sein.

Probier ich heut abend ma.

Grüße
Für alle Blockdevices kannst du den scheduler per Kernelparameter (an die kernel-Zeile im Botloader anhängen) ändern:
elevator=deadline
(wechselt vom default cfq auf deadline).

Du kannst die IO-Scheduler auch per Blockdevice wechseln. verfügbar sind noop, deadline und cfq(default).
Siehe: 
zgrep -i sched /proc/config.gz
Für jedes Blockdevice (evtl. mal konzentrieren auf das USB-Device und die Zielplatte) kannst du den Scheduler erfahren/wechseln: 
# < /sys/block/sdc/queue/scheduler
noop deadline [cfq]

# echo deadline > /sys/block/sdc/queue/scheduler
# < /sys/block/sdc/queue/scheduler
noop [deadline] cfq
Eine Übersicht über die IO-Scheduler sollte sich in der kernel-Dok finden, einen Artikel auf Deutsch(von 2005!) habe ich für den 2.6er gefunden (Als Einstieg sicher noch ok):
http://www.linux-magazin.de/Heft-Abo/Ausgaben/2005/04/Kern-Technik2
und ggf.
http://forums.gentoo.org/viewtopic-t-619496.html

//Edit: der Anticipatory-Schedulerb ist seit 2.6.33 nicht mehr im Kernel, für langsamere Flah-Medien(evtl. dein Problem mit Sticks) soll der "dumme" noop evtl. der bessere sein...
//Edit2: Selbst mit "langsameren" U/SB-Flashmedien habe ich hier (selbe testumgebung wie oben) keine Probleme - weder lesend noch schreibend. Auch an Intel Atoms nicht, allerdings habe ich dort kein Video+Sound zum testen. kann es gerne heute abend nochmal an einem T60 probieren...
GerBra schriebFür alle Blockdevices kannst du den scheduler per Kernelparameter (an die kernel-Zeile im Botloader anhängen) ändern:
elevator=deadline
(wechselt vom default cfq auf deadline).
habe das mal gemacht, zumindest jetzt grad hängt nix beim kopieren von großen Dateien auf USB Stick.
Sonst wurde zum Beispiel ab und zu mal das Firefox Fenster "gegraut" und hat nicht mehr reagiert.

  • [gelöscht]

  • Beitrag Nr. 14
Cool ..

habs nu auch ma geändert und ich sach ma: läuft gut!

Ich behalte das mal ein paar Tage im Auge 🙂

Grüße
Hmm, wundert mich ein wenig.
Der deadline IO-Scheduler ist laut Dokus eher für Systeme mit "wilden", nicht sequentiellen Diskzugriffen (z.B. datenbankserver) geeignet. Gut, auch für Systeme mit vielen Disks (die aber dann mehr oder weniger gleichzeitig IO haben sollten und/oder kein TCQ beherrschen)...

Aber für eine "einfache" Kopieraktion...?
Der cfq ist eigentlich von seiner Intention her auf Desktop-Systeme ausgelegt...
@SiD: Der Noop, ja (schrieb ich ja auch im ersten Posting). Aber ich denke, ihr nutzt doch jetzt den daedline?? /Me verwirrt....
Den Noop will man aber doch nicht als Default-Scheduler für alles....
Ja stimmt, also ich habe jetzt deadline zur Kernelzeile hinzugefügt und das hier in die rc.local 
echo "cfq" > /sys/block/sda/queue/scheduler
echo "cfq" > /sys/block/sdb/queue/scheduler
Das sind meine internen System-SSD und Datenfestplatte. Hatte mal eine große Datei von sdb nach sda (SSD) kopiert. mit den verscheidenen Schedulern.
cfq -> cfq war am schnellsten.

Angesteckte geräte bekommen ja jetzt den deadline 😉

EDIT://
hmm habs grad nochmal getestet mit den gleichen Dateien und dem gleichen Stick, Problem tritt trozdem auf. Auch mit "deadline only".

EDIT://
Also, nach reboot mit elevator=deadline (einträge aus rc.local wieder entfernt) bleibt jetzt wieder nichts hängen.
Scheinbar hat das Umschalten, des Schedulers was ausgemacht.
Also das kann ihc mir zwar nicht vorstellen, aber könnte es was mit den 8GB RAM zu tun haben. Bin mir jetzt nicht sicher, aber ich meine als ich noch "nur" 4GB verbaut hatte trat das nicht auf.
Also ich habe gleiches Verhalten bei nur 2 GB RAM. Hab jetzt die scheduler noch nicht weiter ausprobiert