Dotaz: latence při čtení zařízení, přetečení bufferu

[Jan Martinek]

Ahoj, čtu data z měřící karty National Instruments 6251 a používám comedi drivery, které kartu zpřístupňují prostřednictvím znakového zařízení/dev/comedi0. Když sampluju plnou rychlostí, tak data tečou 2MB za sekundu a občas se stane, že je nestihnu dost rychle číst, přeteče buffer a dostanu Broken pipe. Buffer karty má velikost 4096 bytů a přerušení se vyvolává, když je z poloviny plný. Program tedy musí zareagovat za méně než milisekundu a ne vždy se to podaří. Procesor stíhá bez problémů - je zatížen na 25% a to převážně čeká (IOWAIT). Zkoušel jsem mmap() i read() a chová se to víceméně stejně. Zjistil jsem naprostou záhadu, že když na začátku programu počkám desetinu sekundy, problémů je podstatně méně. Naopak pomalý terminál (třeba gnome-terminál) dokáže čtení překazit skoro vždycky, a to ani nemusím nic vypisovat na stdout.
Co mám dělat? Real-time jádro si nechávám až jako poslední zoufalství.

Odpovědi

[michich]

Běží ten tvůj program s realtimeovou prioritou (SCHED_FIFO)? Méně než 1ms už dá normálnímu jádru asi docela zabrat. Když nechceš RT jádro, tak se ujisti, že máš zapnutý aspoň běžný CONFIG_PREEMPT. Ale toho realtimeového jádra se neboj. Na takové potřeby je to jak dělané. Navíc je tam skvělý latency tracer, který by ti napověděl, v čem je problém.

[Jan Martinek]

Asi jsem kecal s velikostí toho bufferu. Dokumentace ke kartě říká "4095 samples" (nikoli bajtů, přehlídl jsem se). Takže buffer bude asi 65536 bajtů, což je rozumnější. Zkusil jsem taky nastavit tu SCHED_FIFO a světe div se, když to pustím jako root, buffer se mi nepodařilo nikdy zaplnit víc než na cca 9800 bajtů ani když jsem současně pouštěl kdeco, takže tvá rada pomohla úplně zázračně DÍK!
Jako obyčejný user na to nemám práva a měření pak padá jako dřív. Ještě pro jistotu:

int set_fifo_sched(void){
    int r;
    struct sched_param* my_sched_param = NULL;

    my_sched_param = (struct sched_param*) malloc (sizeof(*my_sched_param));
    printf("%d\n", sizeof(*my_sched_param));
    my_sched_param->sched_priority = 99;
    r = sched_setscheduler(getpid(), SCHED_FIFO, my_sched_param);
    free(my_sched_param);
    if (r == -1){
        perror("sched_setscheduler() failed");
        return -1;
    }
    return 0;
}

Co dělá jádro s tím sched_priority?

[michich]

sched_priority je statická priorita. V třídě SCHED_FIFO vždycky dostane přednost proces s vyšší statickou prioritou. To je rozdíl oproti běžné třídě SCHED_OTHER, kde se k CPU aspoň občas dostane i ten nejvíce reniceovaný proces.

Nepotřebuješ být root. Stačí když pro tvého uživatele nebo skupinu nastavíš v /etc/security/limits.conf potřebnou hodnotu rtprio.

[Jan Martinek]

OK, už to mám i jako obyč. user. A přece jen existuje způsob, jak to čtení přinutit k pádu - stačí, když se přepnu z grafiky do konzoly (a zpátky) nebo když strkám různé věci do USB. Ale člověk nesmí být zas tak úplný vepř.

[michich]

No vidíš, tohle by vyřešilo RT jádro Máš aspoň to normální preemptivní?

[Jan Martinek]

Zatím mám tohle:

# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y

Asi si s tím zkusím pohrát.

[petris]

A frekvence přerušovače? zkusil bych 1000Hz

[pavel]

Mám podobný problém (také karta od Ni, ale ovladač Ni-Daqmx-Base). V /ect/security/limits.conf mám:

@audio - rtprio 70
@audio - nice -10

Stačí tedy přiřadit program do skupiny audio a spustí se s prioritou rtprio70? V /etc/pam.d nemusím nic nastavovat? Jak prosím zjistím, že program běží s rtprio 70?

[michich]

Do skupin se nepřiřazují programy, nýbrž uživatelé.

Pokud ten program neumí o RT prioritu požádat sám, zkus ho spustit přes utilitu chrt takto:

chrt -f 70 <program>

Výpis procesů a jejich RT priorit ti dá třeba ps -eo pid,cmd,rtprio.

[pavel]

Děkuji za odpověď, zkusil jsem chrt a funguje. Bylo by možné to spustit i pod normálním (ne - root) uživatelem?

[michich]

Jo, když bude ten uživatel ve skupině audio (podle toho tvého limits.conf).

[pavel]

Díky, vyřešeno.