I looked into the problem that jdavis had and found that the conversion of the timeval_to_jiffies was off by one.
To convert tv.tv_sec = 0, tv.tv_usec = 10000 to jiffies, you come up with an answer of 11 (assuming 1000 HZ). Here's the patch: --- ./include/linux/jiffies.h.orig 2005-04-20 22:30:34.000000000 -0400 +++ ./include/linux/jiffies.h 2005-04-20 22:39:42.000000000 -0400 @@ -231,7 +231,7 @@ * in jiffies (albit scaled), it is nothing but the bits we will shift * off. */ -#define USEC_ROUND (u64)(((u64)1 << USEC_JIFFIE_SC) - 1) +#define USEC_ROUND (u64)(((u64)1 << (USEC_JIFFIE_SC - 1))) /* * The maximum jiffie value is (MAX_INT >> 1). Here we translate that * into seconds. The 64-bit case will overflow if we are not careful, I wrote a user program that copies all of the jiffies.h and shows the output of the conversion. Without this patch you get: usec=10000 jiffies = 11 usec=10010 jiffies = 11 usec=10020 jiffies = 11 . . . usec=10980 jiffies = 11 usec=10990 jiffies = 11 usec=11000 jiffies = 12 With the patch, you get: usec=10000 jiffies = 10 usec=10010 jiffies = 10 usec=10020 jiffies = 10 . . . usec=10480 jiffies = 10 usec=10490 jiffies = 10 usec=10500 jiffies = 11 usec=10510 jiffies = 11 . . . usec=10990 jiffies = 11 usec=11000 jiffies = 11 Which I believe is the more desired result. I've kept jdavis original email to show where this was discovered. -- Steve On Fri, 2005-04-08 at 10:39 -0700, [EMAIL PROTECTED] wrote: > > Hello, > > I've created a pretty straight forward timer using setitimer, and noticed > some odd differences between 2.4 and 2.6, I wonder if I could get a > clarification if this is the way it should work, or if I should continue to > try to "fix" it. > > I create a RealTime Thread( SCHED_FIFO, maxPriority-1 ) (also tried > SCHED_RR) ... > > that creates a timer ...setitimer( ITIMER_REAL, SIGALRM) with a 10 milli > period. (I've also tried timer_create with CLOCK_REALTIME and SIGRTMIN) > > and then the thread does a sem_wait() on a semaphore. > > the signal handler does a sem_post() . > > > on 2.4.X the (idle) worst case latency is ~40 microseconds, > on 2.6.X the (idle) latency is about the same plus 1 tick of the scheduler > ~1000 micro seconds... Always.. Every time. > So to work around this on 2.6 I simply subtract 1 millisecond from my timer > as a fudge factor and everything works as expected. > > I've tried compiling various kernels (2.6.9, 2.6.11) with kernel pre-empting > on, etc.. > > Is this the correct behavior? If so I'm curious who is using up the extra > Tick? > Does the asynch signal handler use up the whole tick even though it only has > to sem_post()? > > I am not subscribed to the list, so I would appreciate a CC. > Thanks, > -JD > - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
