Raspberry Pi: Totzeiten (Bus)

[Mikro 7. (mikro77)]

Hi,

ich spiele zur Zeit ein bisschen mit dem RPi 2 rum, insbesondere gucke 
ich was über GPIO an Sampling möglich ist. Dabei ist mir aufgefallen, 
dass es Totzeiten gibt. Nicht nur beim GPIO Sampling, sondern generell 
beim Polling der BCM Register (also auch beim Timer).

Grundsätzlich kommt man (aus dem User Space) auf ca 10 Mio. Samples/s 
(polling, busy loop). Die Totzeiten kann man gut beim Sampling des 
Timers (CL0) beobachten. Das angehangene Programm liest den Timer (1us 
Auflösung) 100 Mio. Mal und guckt wenn zwei aufeinanderfolgende Werte 
mehr als 1us auseinanderliegen. Bspw.

prompt> sudo taskset -c 3 chrt -f 99 ./test
time=7.63435s cnt=766 min=5 max=82 avg=10.2755

Es gibt also 100 Totzeiten/s die durchschnittlich 10us dauern (die 
Totzeiten erfolgen tatsächlich im genauen Abstand von 10ms, was man hier 
jedoch nicht sehen kann).

Ich lass dass auf Raspbian laufen, und mir ist bewußt, dass es kein 
real-time System ist. Ich bin allerdings neugierig, was genau die 
Totzeiten verursacht. Ich spekuliere auf Cache-Faults oder auf 
Aktivitäten der GPU auf dem (shared) Bus.

Hat jemand eine Idee, um was es sich hier handelt? Freue mich auf 
Rückmeldungen! (Im RPi Forum gab es nur Stille.)

Edit: Spelling

[PittyJ (Gast)]

Ich dachte, es wäre normal, dass auch mal andere Prozesse Rechenzeit 
bekommen. Und wenn ich mir meinen Raspi so anschaue, dann sind da noch 
ein Dutzend andere Prozesse. (Netzwerk, Filesystem, Shell, Daemonen ...)

Letztens war hier schon eine Diskussion über Bare-Metal-Programmierung 
auf dem Raspi. Damit sollte es dann keine Totzeiten mehr geben. Einfach 
mal googlen.

[Mikro 7. (mikro77)]

PittyJ schrieb:
> Ich dachte, es wäre normal, dass auch mal andere Prozesse
> Rechenzeit
> bekommen. Und wenn ich mir meinen Raspi so anschaue, dann sind da noch
> ein Dutzend andere Prozesse. (Netzwerk, Filesystem, Shell, Daemonen ...)

Das ist imho unwahrscheinlich. An welchen Prozess denkst du denn im 
Speziellen, der auf einem idlen 4-Kern-System den laufenden Prozess (auf 
Kern 3 mit der höchsten real-time Priorität) alle 10ms für ca. 10µS 
verdrängt?!

Wahrscheinlicher wären da Kernel-Interrupts. Aber die laufen im Kern 0 
auf.

Cache Faults, die durch einen anderen Prozess oder den Kernel verursacht 
wurden, sind denkbar, da der Cache wohl geshared ist. Das wird zumindest 
über den L2 Cache gesagt. Ob das auch für den hier eher relevanten L1 
Data/Instruction Cache gilt weiß ich nicht.

Und dann bleibt noch die GPU, die wenig dokumentiert ist und quasi alles 
machen kann.

> Letztens war hier schon eine Diskussion über Bare-Metal-Programmierung
> auf dem Raspi. Damit sollte es dann keine Totzeiten mehr geben. Einfach
> mal googlen.

Sollte es tatsächlich die GPU sein, dann wird es auch mit Bare Metal 
schwer. Ist aber egal, dahin möchte ich eh nicht. Ich bin einfach 
neugierig, was genau die o.g. Totzeiten verursacht.