Re: Good performance (hard realtime ??) on 2.6.16 patched with patch-2.6.16-rt29 from Ingo Molnar
From: Carl
Date: Mon Jun 12 2006 - 07:06:15 EST
Felix Oxley writes:
Could you explain to me, in nice easy steps, how you got the measurement?
1) for details see: http://tapas.affenbande.org/?page_id=6.
2) Sending box and sending process
* periodically sends udp message using broadcast adress 192.168.2.255
* this process at RT priority FIFO (using chrt tool)
* put IRQ of network card to RT 99 FIFO prio
* box is idle (to create sort of 'stable') reference timing
3) receiving box
* blocking read on udp socket
* put to RT FIFO 99 (chrt tool)
* process cannot be swapped out (mlockall call)
* while [1] do make -j100 && make clean; done;
* put softiqr-net-rx to RT FIFO 99 (using chrt)
* watchdog/0 not RT (i'm not sure this is mandatory)
* put IRQ of network card to RT FIFO prio 99
* Time measurement the cpu clock using gettimeofday calls
Specifically what triggered the 'start' of your time slice?
on sending box: usleep with 20000 interval (20 millisecond)
on receiving box: blocking read on udp socket
BTW, where you using hi resolution timers?
No, only usleep (maye it uses highres timers in the libs/kernel)
You say the max latency was 512usecs. What were the mean and mode?
Not measured...
(Regarding Hard Real Time, my understanding is that that depends on a
_guarantee_ that the system will always be able to produce the 'result'
within the required interval. Ingo's -rt patches may give exceedingly
good responsiveness but they offer no guarantees, so they cannot be
considered Hard Real Time)
Correct. In my case the repsonsiveness is acceptable in a real time control
system where sporadic deadline misses are acceptable.
Thanks
Carl.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/