Wed, 10 Jan 2001 Alexander Lichius wrote:
[...]
> i found that that there is jitter on the scheduling, at least on one
> system, up to 60 us (before or after the set period), dependent on the
> system load.
How frequent are the peaks, and what kind of system load are we talking about?
> now i wonder how it could be possible to guarantee a
> worst-case-scenario deadline, independent of the system load.
Well, it's at least theoretically possible to calculate a conservative
theoretial worst case latency by summing up the effects of all hardware and
software "latency sources" that could possbly occur one at a time in direct
sequence.
A more realistic approach is to just stress test the system seriously for
several hours, and then multiply the worst observerd latency peak with a some
safety factor. This factor would depend on the characteristics of your
software, the drivers and hardware used, the CPU speed, bus architecture etc,
and of course, how good a guarantee you need. (At some point you'll have a
missed deadline probability that's lower than the probability of your CPU or
main board spontaneously frying; if you end up in that range, you'd better
look for solutions that don't use PC hardware or operating systems...)
> i assume that by increasing the system load, my period derivations get
> increased to.
Not necessarilly. It's entirely possible that the system load just triggers the
worst latency peaks you can get on your system. In that case, you could get
*more* latency peaks, but not higher worst case latency, when increasing the
load. (This would be the case if the latencies are caused by some hardware that
blocks the bus for a certain amount of time every now and then, frequency
depending on how heavily the device is used.)
> in the rtlinux papers, one can find rtlinux should have a maximum
> interrupt response time of under 25 us. is that contradictive to what
> i discovered?
Yes and no: No software can ever guarantee better performance than is
physically possible on any certain hardware configuration. If something causes
the CPU to stall for more than 25 �s, then obviously, no software can ever
guarantee 25 �s worst case latency.
Latency peaks can be caused by "super NMI" (used for power management
implemented in software in the BIOS), misbehaving PCI cards, PCI cards being
allowed to grab the bus for too long (usually configurable in the BIOS, AFAIK),
chipset components that mess with the bus occasionally, or simply crappy
hardware on some card or on the main board.
Another common reason for latency trouble with x86 in general is code that uses
inlined CLI/STI instructions, thus making the attempts from RTL or other RTK to
guarantee latencies futile. Examples of problematic software in the case of
RTL would be X servers (some versions of some servers of XFree86, for
example), binary only kernel modules, kernel modules compiled in a tree without
the RTL patch, and IIRC some functions of svgalib.
[...]
> one thing i should mention: it could be possible, that my disc was
> full at the time of writing the measured timestamps to a rt-fifo.
> could this have some negative influence on the timings?
Not if the RT thread is implemented correctly. If the FIFO is full, it should
report an error, or just drop the data - not try to sleep, or do other things
that will invalidate the current or subsequent data points.
> some timings in us, where i generate system load by:
> # top -q
> # ping -f localhost
> # while [ true ]; do ls -lR /; done
>
> Environment Derivation of period
> Average Min Max
> -----------------------------------------------------
> load, X started: 10.750 0.0 54.848
> no load, X started: 1.169 0.0 21.152
> load, no X: 10.508 0.0 56.544
> no load, no X: 1.020 0.0 13.984
How many measurements do these figures describe? I think the averages look
very, very high... (And the latency is obviously not caused by X in your case.)
//David
..- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
..- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> [EMAIL PROTECTED] -'
.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
