Bill,
Bill Unruh wrote:
Now of course I suspect that the kernel has to wake itself even more often
than once a second (eg the timer interrupt) and if it did not, the effect
on the time discipline would be pretty bad.
The Linux kernel has recently gone tickless, meaning that it only
Jan Ceuleers wrote:
The Linux kernel has recently gone tickless, meaning that it only
schedules a wakeup for itself at the first time that it knows a timer
will expire. A quick intro on that can be found here:
Given the Linux kernel developers' past history of breaking NTP, have
they
David Woolley wrote:
Have they considered the resulting increased processing time, and more
importantly, variability in processing time of gettimeofday?
That's why I'm raising the question here. If anyone on the ntpd team has
contacts at Red Hat, a brief discussion about this would be of
In article
[EMAIL PROTECTED],
jlevine [EMAIL PROTECTED] wrote:
Hello,
While it's unlikely that I will soon get to build such an instrument, I
am quite interested in how they are built, if only to understand what
can happen and why. Can you suggest some articles and/or books and/or
I've built some RPMs for CentOS using the latest SRC from the FC9 branch.
They include that patch and I've noticed no discernable difference in time
keeping and everything appears to be functioning as it should.
Jason
I came across the following page:
Bill,
I have no idea what you are talking about in the timer interrupt issue.
By timer interrupt I mean the kernel facility to create a program
interrupt at specified times, in this case once each second. Even if the
kernel discipline is in use the one-second interrupt is still used to
scan
David L. Mills [EMAIL PROTECTED] writes:
Bill,
I have no idea what you are talking about in the timer interrupt issue.
The 18 or 100 or 250 or 1000 Hz timer interrupt.
And if they do not occur (lost ticks) problems arise.
By timer interrupt I mean the kernel facility to create a program
Miroslav,
You said it exactly slam-dunk right on the head.
Timer queue facilities are tricky and can be absolutely awful to debug
when something doesn't work right. I know this, as I built what might
now be called a tickless kernel for the PDP11 fuzzball in 1979. It did
avoid program
On May 16, 12:29 pm, David L. Mills [EMAIL PROTECTED] wrote:
In modern machines a timer interupt takes about one microsecond and to
scan through the one-second code is really quick. So, we are talking
about an overhead in the order of .1 percent.
In terms of performance, yes, but in terms
On May 15, 9:28 pm, David L. Mills [EMAIL PROTECTED] wrote:
A timer interrupt is required each second to update the clock frequency
no matter what. In addition, a sweep is made through the associations to
see if a poll is pending. It would be in principle posssible to
implement a system of
Bill,
I've have reports of folks using kernel timer interrupts at 10,000 Hz in
Linux. That has nothing to do with ntpd, only the fact that ntpd expects
to be called by the kernel timer routines once per second.
Dave
David L. Mills [EMAIL PROTECTED] writes:
Bill,
I have no idea what
Evandro,
With respect, you miss the point. The ntpd does not require a tickle
every second just to scan for polls; it requires that tickle in order to
discipline the clcok frequency. The additional cycles necessary to link
to the next association structure, then increment and test a variable,
I'm fine with that as long as it doesn't break the current usage. This
all belongs in the parser and the ntp_config.c code.
Danny
David L. Mills wrote:
Danny,
You might recall the message that started the discussion was from a dude
that wanted to selectively listen on one broadcast subnet
Evandro and others,
Now it's me that missed the point. I didn't realize you were concerned
about a milliwatt or two every second. My first kneejerk reaction was
why would you use ntpd on a laptop under conditions where it might
sleep? Better to kill it before sleeping and restart when waking
14 matches
Mail list logo
