PCI Parport-Karte DMA zuweisen?

[Jan 'RedBully' Seiffert]

So, ich bin mit Stefan das Problem mal ein bischen durchgegangen.

Jan-Benedict Glaw schrieb:
> On Mon, 2010-02-22 21:00:38 +0100, Stefan U. Hegner <stefan at hegner-online.de> wrote:
>> Jan 'RedBully' Seiffert schrieb:
>>> Ist es denn irgendwie zu langsam fuer deinen Anwendungsfall?
>> Nicht direkt.
>>
>> Will damit unter lenny (amd64) einen alten Batronix Parport Eprommer ans
>> Rennen bekommen. Am Notebook (lenny, i686; das hat noch einen
>> ISA-Parport) tut das Ding. Einziger augenscheinlicher Unterschied war
>> die Parport Konfiguration und da, dass am Notebook ein DMA-Kanal belegt war.
>>
>> Jedenfalls wolle zprommer (http://www.zut.de/zprommer.html) und
> 
> zprommer: Die machen direkt inb()/outb(), kein DMA. (Und dummerweise
> fummeln die direkt an der Hardware rum, sind nicht portabel und
> nichts, statt einfach mal die ppdev API zu nutzen.)
> 

Jupp, deshalb hab ich zprommer mal grad auf ppdev umgeschrieben
-> keine besserung

Daten landen da wo sie sollen, es dauert aber immer noch ewigkeiten.

[snip]
Nach meinung des Authors sollte man wohl mal ein blick darauf werfen:

   	sched_setscheduler(0,SCHED_FIFO,&schedhigh);
    	nanosleep(&waitxns,&restwait);
    	sched_setscheduler(0,SCHED_OTHER,&schednormal);

Das ist der Code um einen Wait hinzubekommen damit die Logikbausteine "draussen"
mitkommen.
Das der nanosleep etwas zu lange schlaeft, geschenkt, aber...
Auf dem Notebook:
     0.000056 sched_setscheduler(0, SCHED_FIFO, { 99 }) = 0
     0.000034 nanosleep({0, 120}, {3086673120, 0}) = 0
     0.000033 sched_setscheduler(0, SCHED_OTHER, { 0 }) = 0

Alles im microsekunden bereich.
Auf dem AMD64:
     0.000029 sched_setscheduler(0, SCHED_FIFO, { 99 }) = 0
     0.000030 nanosleep({0, 120}, {100, 4211167}) = 0
     0.003577 sched_setscheduler(0, SCHED_OTHER, { 0 }) = 0

Rein in SCHED_FIFO geht fix, schlafen, nagut, nen tuken zu lang, aber raus aus
SCHED_FIFO... Da laesst einen der Kernel erstmal ne strafrunde drehen von 3,6
MILLIsekunden, teilweise noch mehr.
Bei 131077 calls:
	131077 * 0,0036 = 471,8772 sekunden / 60 = 7,86 Minuten

Tja, was tun.
Am anfang des Programms auf SCHED_FIFO gehen und erst am ende wieder raus? Das
koennte den Rechner etwas lahmlegen... sched_yield ist boese...
Es einfach als SCHED_OTHER versuchen und die nice ins negative drehen?
SCHED_RR und da dauerhaft drin bleiben, man hat ja ein Quantum?

Fuer vorschlaege offen...

> 
> MfG, JBG
> 
Gruss
	Jan

-- 
assert(!"The excrement has collided with the air circulation device");