... as hard as you try to package everything up together, it just never works. here is the text file describing the itimer.c plots -- Steve Rosenbluth Jim Henson's Creature Shop 2821 Burton St, Burbank CA (818) 953-3030
These plots show the results of the itimer.c app under various test conditions. plots are the results of itimer.c as seen by gnuplot, grabbed by xv in postscript. Sorry they're sideways, print them. The process, itimer.c handles a SIGALARM at 60 Hz. It measure the time (in microseconds) since last invocation - this is seen in the Y axis. Itimer runs for 2 minutes, thus 7200 samples - seen in the Y axis. Itimer also writes pulses to the printer port for measurement of its actual period. Linux timeslicing causes a target period of 16.667msec to be recorded by itimer as 20msec when timeslicing is the normal 100 per second, 17ms when HZ is set to 1000 and the kernel is recompiled. Test instruments measured that what this process reports as 17 ms is _actually_ 16.667ms (1/60Hz) !! itimer-plot-100.ps: This is plain old linux. _Not_ POSIX soft real time scheduled. Note the scheduling delays of up to 22msec. I am running a "ls -Rl /" command in an xterm to stress the scheduling. X jobs on an unaccelerated XFree86 is the worst, in terms of messing up soft real time. itimer-plot-100nfs-sched.ps: This is POSIX soft real time scheduled with sched_setscheduler(). Note the reduced scheduling delays of 1 to 10msec. I am running a "ls -Rl /" command in an xterm to stress the scheduling. The ls has to recurse through a nfs filesystem over an NE-2000 PCMCIA 10baseT ethernet card. That is visible as the high density of timing errors beginning at sample 2000. itimer-plot-1k-pcs.ps: Here I am running a kernel doing 1000 timeslices per second. This allows me to get my frequency down to the desired 60 Hz. This is POSIX soft real time scheduled with sched_setscheduler(). Note the usual scheduling delays of 1 to 2.5msec, these occur only when I'm doing X jobs, otherwise the graph is flat (frequency stable). Note also there is one pair of bad glitches which increases the worst case to nearly +/-4msec. I see this several times an hour, this is a pair: one early, then one late. I'd love to know what causes it and why its so much worse than the rest. -Steve Rosenbluth [EMAIL PROTECTED]
