sysctl hw.ata.* und trotzdem kein "dma"

zoidb3rg

zoidb3rg

Well-Known Member
Hallo zusammen,

ich habe mal eine Frage zu sysctl hw.ata

bei mir sind folgende Optionen gesetzt:

hw.ata.ata_dma: 1
hw.ata.wc: 1
hw.ata.atapi_dma: 1

trotzdem ist scheibar der DMA-Modus nicht aktiv. Es macht sich wie folgt bemerkbar:
bei einem portsclean -C bzw. make install von openoffice sind viele Zugriffe auf der Festplatte zu verzeichnen und waehrend dessen ist kein normales arbeiten mehr moeglich (Mauszeiger ruckelt etc...).

Hat jemand eine Idee, was ich noch tunen koennte? Hier noch die entsprechende dmesg Aussgabe:

ad0: 152627MB <SAMSUNG SP1614N/TM100-24> [310101/16/63] at ata0-master UDMA100
ad1: 114498MB <SAMSUNG SP1213N/TL100-24> [232632/16/63] at ata0-slave UDMA100
acd0: DVDR <SONY DVD RW DRU-500A/2.1a> at ata1-master UDMA33
acd1: DVDROM <LITEON DVD-ROM LTD163/GH4W> at ata1-slave UDMA33


Danke,
zoidb3rg
 
atacontrol info [channel]

Dies zeigt dir an, welcher Mode derzeit von den Geräten genutzt wird. Bitte beachten, dass S-ATA 150 teilweise als UDMA133 erkannt wird!

atacontrol mode [channel] [mastermode] [slavemode]

Hiermit kannst du den genutzten Mode manuell setzten. Dies muss allerdings nach einem Neustart wiederholt werden, oft kann man die Modes direkt im BIOS erzwingen!

Weitere Infos in der Man-Page: http://www.freebsd.org/cgi/man.cgi?...ath=FreeBSD+5.3-RELEASE+and+Ports&format=html
 
Hi OOZE,

hier mal die Ausgaben von atacontrol:

atacontrol mode 0 (Festplatten)
Master = UDMA100
Slave = UDMA100

atacontrol mode 1 (DVD-Laufwerke)
Master = UDMA33
Slave = UDMA33

atacontrol info 0
Master: ad0 <SAMSUNG SP1614N/TM100-24> ATA/ATAPI revision 7
Slave: ad1 <SAMSUNG SP1213N/TL100-24> ATA/ATAPI revision 7

atacontrol info 1
Master: acd0 <SONY DVD RW DRU-500A/2.1a> ATA/ATAPI revision 6
Slave: acd1 <LITEON DVD-ROM LTD163/GH4W> ATA/ATAPI revision 0

Und trotzem will es nicht so richtig funktionieren :(

FreeBSD ist auf ad1 installieret. Hast du noch eine Idee (vielleicht die Festplatten jeweils an einen eigenen Controller haengen - jede als Master?)

Danke schon mal
 
Bei einem portsclean oder make install laufen noch ganz andere Sachen! Dass kein Arbeiten mehr moeglich ist liegt viel mehr am Scheduler.

Teste das ganze entweder mit einem I/O-Benchmark oder vertraue der Ausgabe von dmesg.
 
S-ATA und kein UDMA 133 ?

Tach,

ich hab ein ähnliches problem, da beim kolleg mit nForce4 board und Serial-ATA nur folgendes in dmesg steht:

(2x Maxtor 300 GB S-ATA)

Code: 
ata1-master: DMA limited to UDMA33, non-ATA66 cable or device
acd0: DVDR <PLEXTOR DVDR PX-716A/1.02> at ata1-master UDMA33
acd1: DVDROM <PLEXTOR DVD-ROM PX-116A3/1.00> at ata1-slave UDMA66
ad8: 286188MB <Maxtor 6B300S0/BANC1980> [581463/16/63] at ata4-master UDMA33
ad10: 286188MB <Maxtor 6B300S0/BANC1980> [581463/16/63] at ata5-master UDMA33

und vmstat mir verzeichnet das max. 6000 KB/s drüber laufen, wenn was kopiert z.b.

Hat wer ne ahnung was da faul sein könnte ?

hier die komplette dmesg: dmesg.today

thx,
Final
 
so hier noch die Ausgabe von bonnie:

bonnie -d /tmp -s 2048
File '/tmp/Bonnie.933', size: -2147483648
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
2048 50587 55.0 51632 23.9 20393 10.2 40554 49.4 50562 17.8 185.0 1.9

der Datendurchsatz sieht gut aus :) Was ich jedoch bemerk habe, ist dass bei
'Reading with getc()...done' die Performanceprobleme auftraten (xmms setzte aus, etc.)
 
zoidb3rg schrieb:
der Datendurchsatz sieht gut aus :) Was ich jedoch bemerk habe, ist dass bei 'Reading with getc()...done' die Performanceprobleme auftraten (xmms setzte aus, etc.)
Zum Vergrößern anklicken....
Das ist normal, da bei diesem Test die CPU besonders intensiv gefordert wird. Bei dir liegt das Ergebnis aber um 50% Auslastung. Hast du irgendwie ein HTT oder ein Dualsystem? Ist das FreeBSD 5.3? Benutzt du SCHED_ULE oder SCHED_4BSD?
 
ist ein Athlon XP 2400 mit 1024 MB Ram unter FreeBSD 5.3.

Benutzt du SCHED_ULE oder SCHED_4BSD? - keine Ahnung ist eine minimal Installation von FreeBSD 5.3 (noch dem GENERIC Kernel), bei der ich alles notwendige aus den Ports nachinstalliert habe. So langsam bin ich gluecklich mit meinem System (gewechselt von Gentoo).
 
Er wird den SCHED_4BSD verwenden, da
1. Standardinstallation
2. SCHED_ULE ist in FreeBSD 5.3 "broken"

Zu dem Problem:
Ähnliche Probleme wie Mausruckeln usw. habe ich auch unter einem P4-System mit HT allerdings unter Linux. Dort tritt das sogar bei reiner Netzwerklast auf, also unabhaengig vom IDE-Treiber.


Mich würde nun auch interessieren, warum sowas passiert.
Auch der SCHED_4BSD wurde weiterentwickelt und erkennt z.B. interaktive Tasks und erhöht deren Antwortzeiten.
Aber selbst ohne das muessten selbst 486 unter Hochlast schnell genug antworten.


Kann das ein Hardwareproblem sein?
 
Also welcher scheduler du einsetzt kannst du in deiner kernel Konfigurationsdatei sehen:

cat /usr/src/sys/<arch>/conf/DEINEKERNELCONFIG | grep SCHED

Code: 
options         SCHED_4BSD              # 4BSD scheduler
options         _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions

Das ist der standard scheduler der bei jeder installation standard mässig im Generic Kernel schlummert.
 
Mal anders gefragt:

Worauf zielt die die Frage nach dem Scheduler ab?
Wenn ich das Konzept des BSD Scheduling richtig verstanden habe, dann ist der grobe Unterschied zwischen ULE und 4BSD, dass ULE dazu gedacht war, dass bei mehreren CPUs die Tasks/Threads zu dieser CPU Affinität besitzten.
D.h. möglichst wird der Task beim nächsten Mal wieder auf der gleichen CPU gerechnet, damit die Taskdaten nicht von CPU-Cache zu CPU-Cache migriert werden muss (durch Invalidieren des Inhalts derer, was aber auch ein Busmasterzugriff von Hardware macht). Das trifft hier aber nicht zu, da es kein SMP-System ist.
Der andere Vorteil des ULE sollte sein, dass die Auswahl des nächsten zu rechnenden lauffähigen Task mit fast konstanter Rechenzeit (O(1)) statt bisher mit einer Rechenzeit auskommt, welche linear Abhaengigkeit von er Anzahl der Tasks war (O(n)). Ausserdem soll der Scheduler "Event-Driven" sein, d.h. nur bei Bedarf aufgerufen werden und nicht kontunuierlich.
Man kann im Netz aber dazu Benchmarks finden, wo kein wirklicher Vorteil zu SCHED_4BSD zu erkennen ist bei vielen Tasks.
Man führte gerade in 5.x "fine graned kernel locking", was nun auch die zusätzlichen CPUs im Kernel-Mode nutzbar machte. Damit hat(te) der SCHED_ULE aber Probleme und ist deswegen "broken" in der offiziellen 5.3 . Aber ich habe auch gelesen, dass SCHED_4BSD ebenso Probleme damit hat, es trat aber nur bei wenigen Leuten auf.

Letzteres könnte das Problem hervorrufen?
 
Also wäre für mich P4 HT 3 GHz der ULE Scheduler interessant da dieser von SMP systemen profitiert und das HT mehr oder weniger nen SMP system ist, seh ich das richtig ?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben