From: Tom Marshall <tmarshall@real.com>
To: George Anzinger <george@mvista.com>
Cc: Andrew Morton <akpm@osdl.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Fw: missed itimer signals in 2.6
Date: Wed, 15 Oct 2003 09:50:16 -0700 [thread overview]
Message-ID: <20031015165016.GA2167@real.com> (raw)
In-Reply-To: <3F8D63AA.9000509@mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1990 bytes --]
> >I understand what happens and why. I admit that I'm not familiar with the
> >POSIX standard on this issue. Questions:
> >
> > * I've heard that the kernel's timer resolution has increased from 10ms to
> > 1ms in 2.6. Why does the itimer have such a large granularity? I
> > expected it to be highly accurate in this range.
>
> I think it is. The missing understanding is, I think, that you expect the
> resolution to be exactly 1/HZ or 1ms. It is actually not exactly that
> because the PIC can not generate 1ms interrupts (close but not close enough
> for NTP). So the kernel figures out what the true PIC rate is and sets up
> the resolution for that. This results in a resolution of ~999,849
> nanoseconds (i.e. instead of 1,000,000 nano seconds per tick). Now there
> is some errors in converting this to micro seconds..., but the actual math
> is done with more precision with the conversion after (which is why the
> various times the program tries don't come out being exact multiples of
> each other, or of anything expressed as only microseconds).
I expect there are at least a few applications that will misbehave because
the developers did not expect a timer to behave this way (regardless of
whether it's proper according to the spec).
Is it possible to choose a timer resolution that errs on the high side of
1ms instead of the low side? [*] It seems to me that would result in the
application getting very close to the expected number of alarm signals. I
am not at all familiar with the kernel design so I don't know if this would
be feasible or not.
[*] If this is the 8254 timer, using 1192 as a divisor should result in a
resolution of ~1,000,686 nanoseconds.
--
I mean, if 10 years from now, when you are doing something quick and dirty,
you suddenly visualize that I am looking over your shoulders and say to
yourself, "Dijkstra would not have liked this", well that would be enough
immortality for me.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-10-15 16:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20031013163411.37423e4e.akpm@osdl.org>
2003-10-14 23:28 ` Fw: missed itimer signals in 2.6 George Anzinger
2003-10-14 23:52 ` Tom Marshall
2003-10-15 15:11 ` George Anzinger
2003-10-15 16:50 ` Tom Marshall [this message]
2003-10-15 16:55 ` Tom Marshall
2003-10-15 22:51 ` George Anzinger
2003-10-15 23:25 ` Tom Marshall
2003-10-16 0:20 ` George Anzinger
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=20031015165016.GA2167@real.com \
--to=tmarshall@real.com \
--cc=akpm@osdl.org \
--cc=george@mvista.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.