From: Eric Piel <Eric.Piel@Bull.Net>
To: george anzinger <george@mvista.com>
Cc: davidm@hpl.hp.com, linux-kernel@vger.kernel.org, jim.houston@ccur.com
Subject: Re: POSIX timer syscalls
Date: Fri, 07 Mar 2003 13:14:33 +0100 [thread overview]
Message-ID: <3E688D29.F2E48939@Bull.Net> (raw)
In-Reply-To: 3E68573A.4020206@mvista.com
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
next prev parent reply other threads:[~2003-03-07 12:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-06 23:06 POSIX timer syscalls David Mosberger
2003-03-06 23:53 ` george anzinger
2003-03-07 1:27 ` David Mosberger
2003-03-07 1:39 ` george anzinger
2003-03-07 1:42 ` David Mosberger
2003-03-07 8:24 ` george anzinger
2003-03-07 10:09 ` Eric Piel
2003-03-07 12:14 ` Eric Piel [this message]
2003-03-07 18:16 ` george anzinger
2003-03-07 18:20 ` george anzinger
2003-03-07 0:15 ` Ulrich Drepper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E688D29.F2E48939@Bull.Net \
--to=eric.piel@bull.net \
--cc=davidm@hpl.hp.com \
--cc=george@mvista.com \
--cc=jim.houston@ccur.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.