Re: Good performance (hard realtime ??) on 2.6.16 patched with patch-2.6.16-rt29 from Ingo Molnar

[Carl]

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/