Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]

[Florian Schmidt <mista.tapas@gmx.net>]

On Mon, 1 Nov 2004 14:42:35 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > new max. jitter: 4.3% (41 usec)
> > new max. jitter: 4.9% (47 usec)
> 
> a couple of conceptual questions: why does rtc_wakeup poll() on
> /dev/rtc? Shouldnt a read() be enough?

well, it works like this:


while(!stopit) {
	// returns when data is ready
	poll(on /dev/rtc);

	// when ready generate the timestamp
	cycles = get_cycles();

	// now read the data	
	read(on /dev/rtc);			

	// and now stuff the data (including timestamp) into the ringbuffer

	// rinse and repeat
}

i get the timestamp before reading because i figured i want to take the
timestamp as close as possible to data being available. The read() and
passing the data to the other thread done after the timestamp generation (in
that ca. 1 - 0.1 ms (1024 - 8192 hz) time window which we have until the
next irq occurs)

> 
> i'm seeing some weird traces, which show rtc_wakeup doing this cycle:
> 
> 	[~900 usecs pass]
> 
> 	hardirq 8 comes in, wakes IRQ 8 thread
> 	IRQ 8 thread wakes up rtc_wakeup
> 
> 	rtc_wakeup fast-thread returns from sys_read()
> 	rtc_wakeup fast-thread enters sys_poll() and returns immediately
> 	rtc_wakeup fast-thread enters sys_read() and blocks

weird. why could poll return immeaditly? Only when data should be available
right? Ahh, maybe there's less data available than which is needed by
read(). I suppose i need to check if enough data is available. If not,
repoll(), then generate the timestamp. Then read(). I had the impression
that this small amount of data which rtc delivers (4 bytes i think) would
not be split into smaller parts.

It never occured to me that poll() could return with incomplete rtc data
available..

As i don't know of any way of finding out how much data is available i
suppose we can just make the poll() a read(). I suppose overhead is
neglectable right?

> 
> 	rtc_wakeup slow-thread runs and does the calculations.
> 
> 	[repeat]
> 
> this i think shows that the logic is wrong somewhere and that read()
> will achieve the blocking. This also means that the sys_read()-return +
> sys_poll() overhead is added to the 'IRQ wakeup' overhead!
> 
> removing the poll() lines doesnt seem to impact the quality of the data,
> but i still see roughly 50 usecs added to the 'real' latency that i see
> in traces.