Re: [RFC] Scheduler issue 1, RT tasks ...

[Victor Yodaiken <yodaiken@fsmlabs.com>]

On Sun, Dec 23, 2001 at 05:31:11PM -0800, Davide Libenzi wrote:
> On Sun, 23 Dec 2001, Victor Yodaiken wrote:
> 
> >
> >
> > Run a "RT"  task that is scheduled   every millisecond (or time of your
> > choice)
> > 	while(1`){
> > 		read cycle timer
> > 		clock_nanosleep(time period using aabsolute time
> > 		read cycle timer - what was actual delay? track worst
> > 			case
> > 		}
> >
> > Run this
> > 	a) on aaaaaaaaan unstressed system
> > 	b) under stress
> > 	c) while a timed non-rt benchmark runs to figure out "RT"
> > 	overhead.
> 
> I've coded a test app that uses the LatSched latency patch ( that uses
> rdtsc ).
> It basically does 1) set the current process priority to RT 2) an ioctl()
> to activate the scheduler latency sampler 3) sleep for 1-2 secs 4) ioctl()
> to stop the sampler 5) peek the sample with pid == getpid().
> In this way i get the net RT task scheduler latency. Yes it does not get
> the real one that includes accessories kernel paths but my code does not
> affect these ones. And they add noise to the measure.


Seems to me that you are not testing what apps see. Internal benchmarks
are useful only for figuring out how to remove bottlenecks that 
effect actual user apps - in my humble opinion of course.
The nice thing about my benchmark is that it actually tests something
useful - how well you can do periodic tasks. BTW, on RTLinux we get 
under 100 microseconds on even 50Mhzx PPC860 - 17us on a 800Mhz K7.
I'd be happy to see some decent numbers in Linux, but you gotta 
measure something more applied. 

> 
> 
> 
> 
> - Davide
>