Esistono strumenti del kernel disponibili per misurare la latenza degli interrupt con una precisione ragionevole?

Sto provando a misurare il jitter nella latenza di interrupt per vari kernel Linux (con patch RT abilitata, ecc.). So che il modo migliore è quello di usare un oscilloscopio per fare questo, generando un'interruzione con il pin GPIO e attivando un altro pin GPIO nella routine del servizio di interrupt, ma mi stavo chiedendo se ci sono degli strumenti del kernel di Linux per farlo, e potrebbe essere posso fare un confronto dei numeri.Esistono strumenti del kernel disponibili per misurare la latenza degli interrupt con una precisione ragionevole?

fonte

2013-03-13 Nuetrino

See: [Come in tempo reale è Linux 2.6] (http://stackoverflow.com/questions/1362906/how-real- time-is-linux-2-6). –

Un metodo tipico sarebbe quello di impostare un orologio ad alta precisione (come il contatore di cicli della CPU) per attivare un'interruzione di un tempo casuale ma noto in futuro e misurare nell'ISR la differenza tra il tempo l'orologio era impostato per spegnersi rispetto al tempo in cui l'ISR veniva effettivamente raggiunto.

(La parte "casuale" di questo è garantire che si evitino sistematicamente le misurazioni durante i periodi di silenzio o di intenso --- ad esempio, non si desidera che l'interrupt del timer si avvii sistematicamente contemporaneamente a una rete card interrupt, spingendo slealmente i numeri di latenza.)

Uno strumento che implementa in qualche modo questo è Cyclictest, anche se sembra misurare il tempo all'interno di un thread del kernel anziché l'ISR stesso, che aumenterà leggermente i numeri di latenza misurati.

fonte

2013-03-14 03:49:18 davidg

Sto pensando di utilizzare un generatore di segnali per generare l'interrupt su un GPIO in modo da poter ottenere il jitter nei tempi di risposta dell'interrupt generando l'interrupt più volte e misurando l'intervallo IRQ più volte. I registri di conteggio PMCR e Cycle per la corteccia ARM lo faranno per me. Ora la parte di registrazione è ciò che è necessario esaminare. – Nuetrino

@Nuetrino Il problema con il fare questo come * davidg * propone che tu sia sempre * sincronizzato * con un orologio di sistema. Una fonte esterna è migliore. Inoltre, il codice dello spazio utente può influire sulla latenza degli interrupt. Alcune istruzioni richiedono più tempo di esecuzione rispetto ad altre. Ma davvero se hai bisogno di questo tipo di latenza, probabilmente c'è qualcosa di sbagliato nell'hardware. DMA, ecc. Sarebbe meglio. Rif: [U-boot interrupts] (http://stackoverflow.com/questions/15829601/enabling-interrupts-in-u-boot-for-arm-cortex-a-9) –

Utilizzare l'utilità "cyclictest" per misurare la latenza, ho effettuato ricerche e sto utilizzando cyclictest per misurare il jitter di RT linux su piattaforma powerpc.
E 'utility semplice ma potente per misurare la latenza

fonte

2013-08-28 05:58:17

Un altro modo è quello di collegare un'uscita GPIO del vostro scheda target ad un altro ingresso GPIO, tirare il segnale di uscita GPIO e gestire questo evento nella routine ISR di GPIO. Controllare la differenza di orario tra il segnale di trazione e il trigger dell'ISR dell'ingresso GPIO. Ecco l'open source per fare questo, per il bordo Lampone:

Linux GPIO IRQ latency test

fonte

2015-06-02 03:14:37 Houcheng

Esistono strumenti del kernel disponibili per misurare la latenza degli interrupt con una precisione ragionevole?

risposta

Problemi correlati