Re: [ntp:questions] Time reset
Andy Helten wrote: > >>> offset never went >128ms). With time steps enabled the drift value >>> settles <90ppm (and again, no step actually occurs). 90ms is a relatively bad static frequency error; a good machine will be around 10ms. That won't help a clean cold start. I didn't check, but did you have the default min and maxpoll values. A high minpoll might make it difficult to get the loop to converge from there without overflows. > > That is also my understanding, that the kernel does not perform the time > step but it is the kernel that updates the system time every tick. My > understanding of the kernel time discipline is that NTP sets the size of The kernel time discipline is turned off if you disable steps completely (i.e. you set the minimum error for a step to be more than half a second or you set it to zero). > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Windows Time with NTPv4
>> Martin Burnicki wrote: >> >>> Setting up peers requires that the admins of the involved machines >>> are willing to do so, since peers can ask the other peers to change >>> their time. NTP is a time pulling protocol. Peers make use of the time on the other peer as one term in the estimation of their time error, but the other peer doesn't demand that they use that time, and when it is used, it can be diluted by other information about the time. I think you may understand this, but the idea that a server sets the time on a client is one of the more common NTP misconceptions. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd oddness
Hello John, On Tuesday, April 1, 2008 at 20:18:19 +, John Oliver wrote: > timezone --utc GMT/London I don't know this tool, but the correct timezone name could rather be Europe/London, no? > [EMAIL PROTECTED] ~]$ date > Tue Apr 1 21:05:09 GMT 2008 > > [EMAIL PROTECTED] ~]$ /sbin/hwclock > Tue 01 Apr 2008 09:05:39 PM GMT -0.323329 seconds > > Why is my hardware clock 12 hours off from the system clock? Because you were unfortunate enough to check it on April 1st in the afternoon. Check it again in the morning of a normal day, and you'll see The Light. ;-) Serge. -- Serge point Bets arobase laposte point net ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Linux 11-minute mode (RTC update)
Hello, On Thursday, April 3, 2008 at 16:25:17 +0200, Noob wrote: > STA_UNSYNC (0x0040, clock unsynchronized) is 0. [...] Thus the kernel > should write the system time to the RTC every 11 minutes; but it does > not. Fine! Don't touch anything, happy man, or it might well "tomber en marche". Real men don't want the eleven-minutes mode. It is not only extremely inaccurate by itself, but it also steps on the toes of those tools that are able to manage the RTC properly. I previously posted some figures, comparing the accuracy of writing the RTC (not counting drift). Mean offset and dispersion: - eleven-minutes mode: -2150 µs +-5000 - hwclock util-linux-ng 2.13.1: -2500 µs +-170 - hwclock 2.32 from BJH: 0 µs +-10 Furthermore both hwclocks are able to evaluate and compensate the drift of the RTC. The eleven-minutes mode cannot do that, and instead it can perturbate hwclock's calculations. Serge. -- Serge point Bets arobase laposte point net ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Linux 11-minute mode (RTC update)
Serge Bets wrote: > Noob wrote: > >> STA_UNSYNC (0x0040, clock unsynchronized) is 0. [...] Thus the kernel >> should write the system time to the RTC every 11 minutes; but it does >> not. > > Fine! Don't touch anything, happy man, or it might well "tomber en > marche". Hello Serge, I was hoping you'd comment! If I don't want the kernel to update the RTC, I can always undef CONFIG_GENERIC_CMOS_UPDATE. > Real men don't want the eleven-minutes mode. :-) > It is not only extremely inaccurate by itself, but it also steps on > the toes of those tools that are able to manage the RTC properly. Our equipment is supposed to run 24/7 for months / years. I need to keep the RTC synchronized, in case of power failure. Do you believe that running hwclock --systohc periodically is better than using the kernel's 11-minute mode? > I previously posted some figures, comparing the accuracy of writing the > RTC (not counting drift). Mean offset and dispersion: > > - eleven-minutes mode: -2150 µs +-5000 > - hwclock util-linux-ng 2.13.1: -2500 µs +-170 > - hwclock 2.32 from BJH: 0 µs +-10 Point taken. ( I use http://giraffe-data.com/software/about_hwclock.html ) If I use hwclock to update the RTC, how often should I do it? What do you think about the following script? while true do sleep 660 # or some other value? hwclock --utc --systohc done > Furthermore both hwclocks are able to evaluate and compensate the drift > of the RTC. The eleven-minutes mode cannot do that, and instead it can > perturbate hwclock's calculations. Is the crystal of the RTC supposed to be more stable than the crystal of the CPU? Regards. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Linux 11-minute mode (RTC update)
Noob wrote: > > Is the crystal of the RTC supposed to be more stable than the crystal of > the CPU? > Neither is supposed to be particularly stable, although the RTC crystal may be a watch crystal, so may keep reasonably good time if maintained at wrist temperature. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
David Woolley wrote: > Andy Helten wrote: > offset never went >128ms). With time steps enabled the drift value settles <90ppm (and again, no step actually occurs). > > 90ms is a relatively bad static frequency error; a good machine will be > around 10ms. That won't help a clean cold start. > > I didn't check, but did you have the default min and maxpoll values. A > high minpoll might make it difficult to get the loop to converge from > there without overflows. > My current problem is that drift settles at 82ppm (what I called <90 in previous email) in one run and then 32ppm in another run (with a reboot between). This is similar to the problem I had with stepping disabled where drift would go from +500ppm in one run and then swing all the way to -500ppm in another run (usually with a reboot between). I am not going to spend another minute troubleshooting this problem until we get an updated linux kernel. I will dig into it more deeply if the new kernel exhibits this same drift instability. Our system is considered "real-time" and thus has many constraints on it, namely that it will run in an isolated environment with no Internet connection. Our setup runs one machine with NTP as a local stratum 1 server using an IRIG-B time source. On that machine I have minpoll set to the lowest (16 seconds). I had to do this so that NTP would begin serving sync requests in a reasonable amount. Startup time is another constraint and we have other boards running as NTP clients that must sync with the NTP server before they can finish initialization. I don't set maxpoll on the server because I've never caught the server changing the polling interval from 16 seconds -- maybe it's a reference clock feature. All other boards in the system run as NTP clients and I use "minpoll 5 maxpoll 9" for them. I'm not 100% sure why I chose those values, but I think the idea was to improve NTP reaction time to changes in the "synchronization environment". I'm not sure whether those poll settings achieve that, but it sounds like you are suggesting a lower minpoll may speed convergence in cases of higher drift. Andy ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
[EMAIL PROTECTED] (Andy Helten) writes: >David Woolley wrote: >> Andy Helten wrote: >> > offset never went >128ms). With time steps enabled the drift value > settles <90ppm (and again, no step actually occurs). > >> >> 90ms is a relatively bad static frequency error; a good machine will be >> around 10ms. That won't help a clean cold start. >> >> I didn't check, but did you have the default min and maxpoll values. A >> high minpoll might make it difficult to get the loop to converge from >> there without overflows. >> >My current problem is that drift settles at 82ppm (what I called <90 in >previous email) in one run and then 32ppm in another run (with a reboot >between). This is similar to the problem I had with stepping disabled >where drift would go from +500ppm in one run and then swing all the way >to -500ppm in another run (usually with a reboot between). I am not >going to spend another minute troubleshooting this problem until we get >an updated linux kernel. I will dig into it more deeply if the new >kernel exhibits this same drift instability. That is an incredibly unstable clock. It is hard to imagine that this is a kernel problem. This is on one of your machines? It is not the server connected to the IRIG-B is it? >Our system is considered "real-time" and thus has many constraints on >it, namely that it will run in an isolated environment with no Internet >connection. Our setup runs one machine with NTP as a local stratum 1 >server using an IRIG-B time source. On that machine I have minpoll set No need for internet if you have a local clock. >to the lowest (16 seconds). I had to do this so that NTP would begin >serving sync requests in a reasonable amount. Startup time is another >constraint and we have other boards running as NTP clients that must >sync with the NTP server before they can finish initialization. I don't >set maxpoll on the server because I've never caught the server changing >the polling interval from 16 seconds -- maybe it's a reference clock >feature. >All other boards in the system run as NTP clients and I use "minpoll 5 >maxpoll 9" for them. I'm not 100% sure why I chose those values, but I >think the idea was to improve NTP reaction time to changes in the >"synchronization environment". I'm not sure whether those poll settings >achieve that, but it sounds like you are suggesting a lower minpoll may >speed convergence in cases of higher drift. No. He meant if you had minpoll say 8 or 10 it would make settling down long if the ssytem did not start with a good drift value. However, even minpoll 5 means one data sample every 4 hours roughly(since ntp throws away roughly 7/8 of the samples in the clock_filter). That's a slow convergence. And even minpoll 4, the minimum, is only one sample every 2 hrs. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Linux 11-minute mode (RTC update)
Noob <[EMAIL PROTECTED]> writes: >Serge Bets wrote: >> Noob wrote: >> >>> STA_UNSYNC (0x0040, clock unsynchronized) is 0. [...] Thus the kernel >>> should write the system time to the RTC every 11 minutes; but it does >>> not. >> >> Fine! Don't touch anything, happy man, or it might well "tomber en >> marche". >Hello Serge, I was hoping you'd comment! >If I don't want the kernel to update the RTC, I can always undef >CONFIG_GENERIC_CMOS_UPDATE. >> Real men don't want the eleven-minutes mode. >:-) >> It is not only extremely inaccurate by itself, but it also steps on >> the toes of those tools that are able to manage the RTC properly. >Our equipment is supposed to run 24/7 for months / years. >I need to keep the RTC synchronized, in case of power failure. >Do you believe that running hwclock --systohc periodically is better >than using the kernel's 11-minute mode? >> I previously posted some figures, comparing the accuracy of writing the >> RTC (not counting drift). Mean offset and dispersion: >> >> - eleven-minutes mode: -2150 µs +-5000 >> - hwclock util-linux-ng 2.13.1: -2500 µs +-170 >> - hwclock 2.32 from BJH: 0 µs +-10 >Point taken. >( I use http://giraffe-data.com/software/about_hwclock.html ) >If I use hwclock to update the RTC, how often should I do it? >What do you think about the following script? >while true >do > sleep 660 # or some other value? > hwclock --utc --systohc >done >> Furthermore both hwclocks are able to evaluate and compensate the drift >> of the RTC. The eleven-minutes mode cannot do that, and instead it can >> perturbate hwclock's calculations. >Is the crystal of the RTC supposed to be more stable than the crystal >of the CPU? Nope. It is less stable. But what you really want is the drift rate of the crystal when the computer is shut off ( ie cooling or cold) and all you can measure is the drift rate when it is on (warm and constant) The sensitivity of the rtc crystal to temp can be up to 10 times worse than the cpu clock's sensitivity. (www.theory.physics.ubc.ca/chrony/chrony.html) However, even a crude drift compensation is probably better than none. Just don't expect any miracles from the RTC. >Regards. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
Unruh wrote: > [EMAIL PROTECTED] (Andy Helten) writes: > >> My current problem is that drift settles at 82ppm (what I called <90 in >> previous email) in one run and then 32ppm in another run (with a reboot >> between). This is similar to the problem I had with stepping disabled >> where drift would go from +500ppm in one run and then swing all the way >> to -500ppm in another run (usually with a reboot between). I am not >> going to spend another minute troubleshooting this problem until we get >> an updated linux kernel. I will dig into it more deeply if the new >> kernel exhibits this same drift instability. >> > > > That is an incredibly unstable clock. It is hard to imagine that this is a > kernel problem. This is on one of your machines? It is not the server > connected to the IRIG-B is it? > > I'm fairly certain the board's oscillator is stable. I wrote a simple perl script that keyed of a PPS print from a GPS-to-IRIGB box. When the PPS time was printed, I grabbed local system time as well as IRIGB time from the local IRIGB PMC. Using this approach, the system oscillator's drift (without NTP running) was measured to be within the +/-30ppm oscillator specifications. This procedure was reliable over several runs and was repeated on at least one other board with an IRIG-B receiver. Yes, there is a potential for problems in many different areas within this setup, however, after much troubleshooting to isolate the problem, the 2.6.18 kernel has always been involved in the non-working configuration. An older kernel worked fine with the same IRIG-B driver, the same version of NTP, but different hardware, so I haven't completely exonerated the hardware. At any rate, this has been put on the back burner until we can get the latest RedHawk release, which isn't due until mid April. >> All other boards in the system run as NTP clients and I use "minpoll 5 >> maxpoll 9" for them. I'm not 100% sure why I chose those values, but I >> think the idea was to improve NTP reaction time to changes in the >> "synchronization environment". I'm not sure whether those poll settings >> achieve that, but it sounds like you are suggesting a lower minpoll may >> speed convergence in cases of higher drift. >> > > No. He meant if you had minpoll say 8 or 10 it would make settling down > long if the ssytem did not start with a good drift value. > However, even minpoll 5 means one data sample every 4 hours roughly(since > ntp throws away roughly 7/8 of the samples in the clock_filter). That's a slow > convergence. And even minpoll 4, the minimum, is only one sample every 2 > hrs. > > Hmmm, clearly the more I learn about NTP, the less I know. Andy ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
>My current problem is that drift settles at 82ppm (what I called <90 in >previous email) in one run and then 32ppm in another run (with a reboot >between). This is similar to the problem I had with stepping disabled >where drift would go from +500ppm in one run and then swing all the way >to -500ppm in another run (usually with a reboot between). I am not >going to spend another minute troubleshooting this problem until we get >an updated linux kernel. I will dig into it more deeply if the new >kernel exhibits this same drift instability. I think we are talking about two different bugs here. The different drifts on reboot are due to a quirk in the tsc calibration code in the kernal. Grep your sys log for messages like these: Mar 30 21:56:23 shuksan kernel: Detected 2793.091 MHz processor. Mar 30 22:23:28 shuksan kernel: Detected 2793.067 MHz processor. Mar 30 22:42:31 shuksan kernel: Detected 2793.037 MHz processor. Mar 30 23:03:21 shuksan kernel: Detected 2793.085 MHz processor. Mar 31 00:07:37 shuksan kernel: Detected 2793.147 MHz processor. Those bottom bits jumping arround correspond to the different drift values. If you only have one system, you can pick one and hack your kernel to smash in a constant value at the right place. Or you can add something like this to your boot line: clocksource=acpi_pm That's assuming your hardware has acpi and whatever. I've been using it for a while. I haven't noticed any quirks, but who knows. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
Unruh wrote: > [EMAIL PROTECTED] (Andy Helten) writes: > > > >>David Woolley wrote: >> >>>Andy Helten wrote: >>> >>> >>offset never went >128ms). With time steps enabled the drift value >>settles <90ppm (and again, no step actually occurs). >> > >>>90ms is a relatively bad static frequency error; a good machine will be >>>around 10ms. That won't help a clean cold start. >>> >>>I didn't check, but did you have the default min and maxpoll values. A >>>high minpoll might make it difficult to get the loop to converge from >>>there without overflows. >>> >> > >>My current problem is that drift settles at 82ppm (what I called <90 in >>previous email) in one run and then 32ppm in another run (with a reboot >>between). This is similar to the problem I had with stepping disabled >>where drift would go from +500ppm in one run and then swing all the way >>to -500ppm in another run (usually with a reboot between). I am not >>going to spend another minute troubleshooting this problem until we get >>an updated linux kernel. I will dig into it more deeply if the new >>kernel exhibits this same drift instability. > > > > That is an incredibly unstable clock. It is hard to imagine that this is a > kernel problem. This is on one of your machines? It is not the server > connected to the IRIG-B is it? > > >>Our system is considered "real-time" and thus has many constraints on >>it, namely that it will run in an isolated environment with no Internet >>connection. Our setup runs one machine with NTP as a local stratum 1 >>server using an IRIG-B time source. On that machine I have minpoll set > > > No need for internet if you have a local clock. > > > >>to the lowest (16 seconds). I had to do this so that NTP would begin >>serving sync requests in a reasonable amount. Startup time is another >>constraint and we have other boards running as NTP clients that must >>sync with the NTP server before they can finish initialization. I don't >>set maxpoll on the server because I've never caught the server changing >>the polling interval from 16 seconds -- maybe it's a reference clock >>feature. > > >>All other boards in the system run as NTP clients and I use "minpoll 5 >>maxpoll 9" for them. I'm not 100% sure why I chose those values, but I >>think the idea was to improve NTP reaction time to changes in the >>"synchronization environment". I'm not sure whether those poll settings >>achieve that, but it sounds like you are suggesting a lower minpoll may >>speed convergence in cases of higher drift. > > > No. He meant if you had minpoll say 8 or 10 it would make settling down > long if the ssytem did not start with a good drift value. > However, even minpoll 5 means one data sample every 4 hours roughly(since > ntp throws away roughly 7/8 of the samples in the clock_filter). That's a slow > convergence. And even minpoll 4, the minimum, is only one sample every 2 > hrs. > > I must be missing something! Minpoll=5 means 2^5 seconds is the minimum poll interval. How are you getting to every four hours from that? ISTR that the default minpoll is 6 which gives 2^6 or 64 seconds. If the server lines in ntp.conf include the "iburst" keyword, the servers will be polled with an initial burst of eight requests sent at two second intervals. This fills the pipeline and "pacifies" the filter. Thereafter, ntpd adjusts the polling interval as it thinks best. Normally the poll interval will increase to somewhere between 256 and 1024 seconds once the clock is synchronized. In general, the better the network connection the higher the maximum poll interval. It's interesting to watch the performance of ntpd improve as the network quiets down during the hours when most people sleep! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Linux 11-minute mode (RTC update)
>Fine! Don't touch anything, happy man, or it might well "tomber en >marche". Real men don't want the eleven-minutes mode. It is not only >extremely inaccurate by itself, but it also steps on the toes of those >tools that are able to manage the RTC properly. Would somebody please collect this info on a wiki page. >From my view, it's dumb for the kernel to write to the RTC since I can do that from user land. Why add clutter to the kernel? On the other hand, the kernel probably wants to read the clock early in the boot sequence so that the time is close. I don't want the kernel cluttered up with code to correct the raw hardware reading (besides, the file with the info in it may not be mounted yet), so writing out the correct time occasionally seems like a reasonable idea. I'd be thinking of hours or days rather than 11 minutes, and I can do that from a cron job. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
On 3 apr, 23:10, "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote: ... > > DOES the time step backward? > > If ntpd is working properly it should NOT need to step the time at all > with the possible exception of a single step when ntpd is first started. > > If ntpd is stepping time regularly, you have some other problem. If you > find and fix that problem, ntpd should stop stepping the time. > > There are/were known issues with some Linux systems; during periods of > high disk usage, clock interrupts would be lost resulting in a FORWARD > step. AFAIK these issues were related to EIDE disks used in PIO mode > rather than DMA mode. ISTR reading that the problem has been fixed in > recent versions of Linux. YMMV I agree that ntpd should not stepping time regularly and that it points to a problem if it happens regularly. But we develop an appliance and we don't control how customers deploy it. Given the adverse effects of stepping time (especially if it moves backwards), I'd would have liked to be protected against badly set-up NTP infrastructure or time servers that are compromised. Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
jkvbe wrote: > On 3 apr, 23:10, "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote: > ... > >>DOES the time step backward? >> >>If ntpd is working properly it should NOT need to step the time at all >>with the possible exception of a single step when ntpd is first started. >> >>If ntpd is stepping time regularly, you have some other problem. If you >>find and fix that problem, ntpd should stop stepping the time. >> >>There are/were known issues with some Linux systems; during periods of >>high disk usage, clock interrupts would be lost resulting in a FORWARD >>step. AFAIK these issues were related to EIDE disks used in PIO mode >>rather than DMA mode. ISTR reading that the problem has been fixed in >>recent versions of Linux. YMMV > > > I agree that ntpd should not stepping time regularly and that it > points to a problem if it happens regularly. But we develop an > appliance and we don't control how customers deploy it. Given the > adverse effects of stepping time (especially if it moves backwards), > I'd would have liked to be protected against badly set-up NTP > infrastructure or time servers that are compromised. > > Jan It seems to me that, in the circumstance you describe, supplying correct time is the customer's problem! Having read this newsgroup for the last four or five years, I'm aware that people do some very strange things with computer clocks. I'm thinking, in particlar, of at least one individual who deliberately set his clock to an incorrect time in order to see if Ntpd would correct it. Ntpd did so, of course, but he was not happy with the way it was done or the amount of time it took! If it's not under your control, it's not your responsibilty! Your instructions for the appliance should point this out pretty explicitly; e.g. "IF YOUR TIME SERVERS CAUSE TIME TO STEP, THE FOLLOWING ADVERSE CONSEQUENCES CAN BE EXPECTED TO OCCUR: It is YOUR responsibility to ensure that this does not happen!" The only halfway legitimate thing I can think of that would cause time to step would be a leap second. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
Richard B. Gilbert wrote: > that people do some very strange things with computer clocks. I'm > thinking, in particlar, of at least one individual who deliberately set > his clock to an incorrect time in order to see if Ntpd would correct it. Many people do this. It is the naive users' way of testing that ntpd "works". > Ntpd did so, of course, but he was not happy with the way it was done or > the amount of time it took! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
Hal wrote: >> My current problem is that drift settles at 82ppm (what I called <90 in >> previous email) in one run and then 32ppm in another run (with a reboot >> between). This is similar to the problem I had with stepping disabled >> where drift would go from +500ppm in one run and then swing all the way >> to -500ppm in another run (usually with a reboot between). I am not >> going to spend another minute troubleshooting this problem until we get >> an updated linux kernel. I will dig into it more deeply if the new >> kernel exhibits this same drift instability. >> > > I think we are talking about two different bugs here. > > The different drifts on reboot are due to a quirk in the tsc > calibration code in the kernal. Grep your sys log for messages > like these: > Mar 30 21:56:23 shuksan kernel: Detected 2793.091 MHz processor. > Mar 30 22:23:28 shuksan kernel: Detected 2793.067 MHz processor. > Mar 30 22:42:31 shuksan kernel: Detected 2793.037 MHz processor. > Mar 30 23:03:21 shuksan kernel: Detected 2793.085 MHz processor. > Mar 31 00:07:37 shuksan kernel: Detected 2793.147 MHz processor. > Those bottom bits jumping arround correspond to the different > drift values. > > If you only have one system, you can pick one and hack your > kernel to smash in a constant value at the right place. > > Or you can add something like this to your boot line: > clocksource=acpi_pm > That's assuming your hardware has acpi and whatever. > > I've been using it for a while. I haven't noticed any quirks, > but who knows. > > YES! The slight variation in measured CPU speed seems to explain my continued drift instability (where "continued" means even with stepping enabled). I was able to retrieve four CPU speed measurements that had corresponding NTP loop logs. The table below shows the perfect correlation between linux-measured CPU speed and NTP-measured drift. Clearly the "real" CPU speed is somewhere around 2000.200 MHz. measured CPU speed | measured drift (MHz) | (ppm) --- 2000.153 | -23 2000.215 |8 2000.321 | 61 2000.367 | 84 As I've stated before, I don't believe the oscillator is really this unstable, but I could be wrong. After all, my CPU measurements varied much more than yours, especially from one run to the next. However, I'm still open to the possibility that linux's approach to speed measurement is less than perfect (at least for my version of linux). These measurements were on a core 2 duo (2 processors) running RedHawk linux 2.6.18.8. Hal, can you tell me which version of linux resulted in your list of speed measurements? I also wonder if the use of two processors has any impact on this behavior. I tried forcing CPU affinity for the NTP process, but it didn't have any effect on the measured drift value. This means that either there truly is no difference between CPUs (as in different speed/frequency characteristics) or I wasn't actually moving the process between CPUs (using /proc//affinity). I'm assuming both CPUs have the same oscillator, so it makes sense that they would measure the same drift. Thanks, Andy ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
>As I've stated before, I don't believe the oscillator is really this >unstable, but I could be wrong. After all, my CPU measurements varied >much more than yours, especially from one run to the next. However, I'm >still open to the possibility that linux's approach to speed measurement >is less than perfect (at least for my version of linux). These >measurements were on a core 2 duo (2 processors) running RedHawk linux >2.6.18.8. Hal, can you tell me which version of linux resulted in your >list of speed measurements? Your crystal is probably fine. At one point, I hacked my kernel to call the calibration routine several times and printout the answer. A batch of answers from the same time (and hopefully same temperature) had the same sort of scatter. I'm running 2.6.23 wih a few local hacks. 2.6.19 has similar problems. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] 771 bloqueador veicular sem mensal idades - http://bloqueadorgsm.vilabol.uol.com.br 7716005770854448303300200
Bloqueador veícluar com tecnologia gsm - Sem mensalidades Tenha toda segurança para seu carro com um preço justo. Apenas R$ 299,00 ( sem mensalidades ) http://bloqueadorgsm.vila.bol.com.br/ Compare e Compre. Rastreador de Veículo Rastreadores de Veículos Rastreador GPS Rastreadores GPS Rastreador Ituran Rastreadores Ituran Rastreador Portátil Rastreadores Portáteis. Assistência 24 Horas Visite agora mesmo nosso site. http://bloqueadorgsm.vila.bol.com.br/ Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores HTigfm&n(>'qai?5"!Co'IuTsX.5APO=7\pcuWJ6 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
