`I looked into the problem that jdavis had and found that the conversionof the timeval_to_jiffies was off by one. To convert tv.tv_sec = 0, tv.tv_usec = 10000 to jiffies, you come upwith 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 theoutput of the conversion.  Without this patch you get:usec=10000  jiffies = 11usec=10010  jiffies = 11usec=10020  jiffies = 11   .   .   .usec=10980  jiffies = 11usec=10990  jiffies = 11usec=11000  jiffies = 12With the patch, you get:usec=10000  jiffies = 10usec=10010  jiffies = 10usec=10020  jiffies = 10   .   .   .usec=10480  jiffies = 10usec=10490  jiffies = 10usec=10500  jiffies = 11usec=10510  jiffies = 11   .   .   .usec=10990  jiffies = 11usec=11000  jiffies = 11Which I believe is the more desired result.I've kept jdavis original email to show where this was discovered.-- SteveOn Fri, 2005-04-08 at 10:39 -0700, jdavis@accessline.com 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" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at  http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at  http://www.tux.org/lkml/`