Messages in this thread | | | Date | Fri, 07 Mar 2003 13:14:33 +0100 | From | Eric Piel <> | Subject | Re: POSIX timer syscalls |
| |
george anzinger wrote: > > By the way, I am seeing some reports from the clock_nanosleep test > about sleeping too long or too short. The too long appears to be just > not being able to preempt what ever else is running. The too short > (on the x86) is, I believe, due to the fact that more that 1/HZ is > clocked on the wall clock each jiffie. > > Try this: > > time sleep 60 > > On the x86 it reports less than 60, NOT good. > I've run the test programs and they pass everything well (with my patchs) excepted the nanosleeps which seems to be finnished a bit too early. My system test is a 2.5.64 patched on a 4xItaniumII.
My main question is to know if it's a problem even if the difference between the wakeup time and the requested time is smaller than the resolution of the clock, 976562ns ? I mean, at the resolution of the clock we could consider we woke up right at the good time, couldn't we?
In addition time sleep 60 always gave me time over 1 minute, I guess it's a good point.
Here is a part of the log of 'do_test':
Testing behavor with clock seting... Retarding the clock Clock did not seem to move was: 1046969027s 703359000ns requested: 1046969023s 703359000ns now: 1046969022s 467072000ns diff is -1.236286998sec Cool clock_nanosleeptest.c,379:clock_nanosleep(clock, TIMER_ABSTIME, &ts, NULL)
Testing signal behavor... handler1 entered: signal 31 expected clock_nanosleeptest.c,227:clock_nanosleep(clock, 0, &ts, &rs): Interrupted system call Time remaining is 0s 989257306ns clock_nanosleeptest.c,245:slept too short! requested: 275s 207032000ns now: 275s 207030632ns diff is -0.000001368sec
Testing undelivered signal behavor... Cool clock_nanosleeptest.c,267:clock_nanosleep(clock, 0, &ts, &rs) clock_nanosleeptest.c,283:slept too short! requested: 275s 223633000ns now: 275s 223632698ns diff is -0.000000302sec
--Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |