Come limitare il tempo impiegato da Linux per un'azione?

La domanda può sembrare sfocata poiché è difficile descrivere un problema in una riga, quindi ecco qui. Uso Debian su Raspberry Pi per eseguire un regolatore PID, il che significa che dt (differenza di tempo tra le esecuzioni del ciclo) si ottiene ogni volta che viene calcolata l'uscita PID. Fondamentalmente dt è calcolato in questo modo.Come limitare il tempo impiegato da Linux per un'azione?

oldtime_ = time_; 
    clock_gettime(CLOCK_MONOTONIC, &time_); 
    Timer.dt = ((static_cast<int64_t>(time_.tv_sec) * 1000000000 + static_cast<int64_t>(time_.tv_nsec)) - (static_cast<int64_t>(oldtime_.tv_sec) * 1000000000 + static_cast<int64_t>(oldtime_.tv_nsec)))/1000000000.0;

PID viene aggiornato circa 400 volte al secondo e va bene, ma a volte Linux decide di prendere molto più tempo per fare un'azione. Il risultato è un grande numero di dt, diciamo, non 1/400 = 0,0025 ma uno 0,8 che è 320 volte più del necessario. Il risultato è un calcolo errato del PID. Sembra così. enter image description here

Mi piacerebbe avere una risposta su come spostare raspbian un po 'più vicino a un sistema in tempo reale.

EDIT

Grazie, anaken78 e chiunque che hanno aiutato. L'utilizzo della pianificazione RR_FIFO ha funzionato perfettamente e la velocità di elaborazione è sempre di 380-400 hz. enter image description here

fonte

2015-03-15 user3081123

Se è necessario un timer economico di alta precisione, suggerisco di utilizzare il TSC direttamente (se disponibile) e collegare il processo a un singolo core (se il sistema è multiplo) per evitare l'inclinazione di TSC. – erenon

Cosa hai provato finora? Non è che questo requisito sia totalmente nuovo e unico, e sembra che tu sappia già le parole chiave da cercare. Inoltre, il timer non è preciso o lo scheduler si confonde con la tua logica? –

Il sistema è a singolo core. Il problema è che l'utilità di pianificazione non funziona, quindi non sono sicuro che l'utilizzo diretto di TSC potrebbe essere d'aiuto, ma proverò se il funzionamento di TSC fornisce direttamente una priorità più alta a uno schedulatore. Come ho detto, la domanda sembra sfocata per me su Google. L'unica parola chiave che ho provato è "in tempo reale", ma non ho ancora usato i kernel RTlinux o in tempo reale. Lo farò se ballare intorno a Debian non dà risultati. – user3081123

Sto presupponendo che utilizza pi lampone originale e non pi lampone 2. Il problema con pi lampone originale è che utilizza un singolo core ARM11 CPU che in effetti significa che qualsiasi tipo di calcolo RT (il modo si sta facendo) sono tenuti ad avere errori a causa di interruzioni hardware. Ad esempio, i pacchetti provenienti dal Wifi potrebbero interrompere il sistema, causando un problema.

Una possibile cosa che si potrebbe provare, se si sta bene senza connettività di rete, è aumentare la priorità del processo e arrestare le interfacce wifi e eth. Queste, direi, sono le principali fonti di interrupt asincroni che potrebbero finire per interrompere l'esecuzione del processo. Ci saranno altri interrupt che continuano a sparare, puoi dare un'occhiata a/proc/interrupts e/proc/softirq per avere un'idea dell'attivazione degli interrupt, ma in una piattaforma come raspberry pi, dovrebbero essere priodici (timer) o faranno molto breve (ad esempio interruzioni USB) non dovrebbe causare ritardi nel processo, nell'ordine di pochi ms.

fonte

2015-04-24 23:39:17 anaken78

Come limitare il tempo impiegato da Linux per un'azione?

risposta

Problemi correlati