public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox