"Michael B. Rash" wrote:
>
> Suppose that I have a process that generates a timestamp every time it
> loops through some task, and assume that this process is not running with
> real time support. Is there any way to guarantee that the timestamping
> will be accurate to within some bound? That is, my task ends at some
> absolute time t0, and my timestamp gets assigned some short time t1 after
> t0 (if there is a context switch before the timestamp is assigned then the
> delay will be greater I guess). So, is there any way to bound t1-t0?
>
> My guess is that trying to _guarantee_ that t1-t0 < n for some n would
> be useless since my process could get swapped out with some higher
> priority process, or a bunch of interrupts happen, etc. But on _average_
> what would n be? It would be related to the processor speed, the machine
> load, and the jiffie that has been compiled into the machine correct?
>
> Michael B. Rash
> http://www.math.umd.edu/~mbr
>
If you don't use the "soft" real-time process support, the latency will
vary a lot, mostly depending on your workload. If you have a light
workload, the latency would be close to the case when you use "soft"
real-time process (on average in 40 ms range), although the worst-case
latency can still be very bad (such as in 200 ms range).
Why don't you use real-time process?
I did a test to test preemptoin latency for a real-time process. See
the preliminary results below. On average, you should expect your
(t1-t0) smaller than those numbers since they are the worst-case
numbers.
The CPU speed probably does not have much to do with the worst-case
latency, I suspect.
Jun
preemption latency (start/check/break points) :
breakCount : 0
logFlag : 1
panicFlag : 0
syncFlag : 0
numIntrs : 232737039
S<-S S<-C S<-B C<-S C<-C C<-B B<-S B<-C B<-B
0 0 230698583 231191408 1545631 0 0
231191408 0
log entry : 0
latency : 560317 (2106 us)
startFileName : entry.S - system_call
startFileLine : 999
startCount : 3 (sys_read)
endFileName : entry.S - ret_with_reschedule
endFileLine : 555
endCount : 1708377051
log entry : 1
latency : 363569 (1366 us)
startFileName : do_IRQ start
startFileLine : 1868515666
startCount : 15 (ide1)
endFileName : entry.S - ret_with_reschedule
endFileLine : 555
endCount : 3297223115
log entry : 2
latency : 434928 (1635 us)
startFileName : sched.c
startFileLine : 692
startCount : 5555
endFileName : entry.S - ret_with_reschedule
endFileLine : 555
endCount : 1012926531
log entry : 3
latency : 320526 (1204 us)
startFileName : entry.S - system_call
startFileLine : 999
startCount : 118 (sys_fsync)
endFileName : sched.c
endFileLine : 692
endCount : 3047403150
log entry : 4
latency : 344386 (1294 us)
startFileName : sched.c
startFileLine : 692
startCount : 5555
endFileName : process.c
endFileLine : 80
endCount : 1207202312
log entry : 5
latency : 2737250 (10290 us)
startFileName : process.c
startFileLine : 80
startCount : 5555
endFileName : process.c
endFileLine : 98
endCount : 2769072804
log entry : 6
latency : 408419 (1535 us)
startFileName : error_code start
startFileLine : 1920102258
startCount : 1111
endFileName : entry.S - ret_with_reschedule
endFileLine : 555
endCount : 1547257731
log entry : 7
latency : 2463962 (9263 us)
startFileName : sched.c
startFileLine : 692
startCount : 5555
endFileName : sched.c
endFileLine : 692
endCount : 2720906020
log entry : 8
latency : 483034 (1815 us)
startFileName : entry.S - ret_with_reschedule
startFileLine : 555
startCount : 5555
endFileName : sched.c
endFileLine : 692
endCount : 2191736692
log entry : 9
latency : 2890499 (10866 us)
startFileName : process.c
startFileLine : 129
startCount : 5555
endFileName : sched.c
endFileLine : 692
endCount : 3814604792
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:20 EST