Re: [ntp:questions] NTP + kernel frequency
David L. Mills wrote: Hal Murray wrote: There is a lot of work going on in the Linux kernel to avoid unnecessary timer interrupts in order to save power on laptops and other systems running off batteries. Any work on the Linux kernel to avoid timer interrupts is incompatible with NTP. This is not a bad or good judgement, just and engineering constraint. If timer interrupts are disabled, disable NTP. On the issue about timer interrupts at frequencies other than 100 Hz, this is easy to fix. The nanokernel code that left here uses a constant SHIFT_PLL that must be scaled inversely as the timer interrupt frequency. It does not need to be exact, but close. I don't know how or even whether this code is mangled in the Linux kernel, but there you have it. If provisions to fix this are not in the Linux kernel and the timer frequency is other than 100 Hz, then the Linux build and install process should not include ntpd; alternatively, the kernel discipline must be disabled. One can browse the Linux kernel NTP implementation here: http://lxr.linux.no/source/kernel/time/ntp.c The entire time directory might be of interest: http://lxr.linux.no/source/kernel/time/ The NTP_INTERVAL_FREQ macro is defined as: #ifdef CONFIG_NO_HZ #define NTP_INTERVAL_FREQ (2) #else #define NTP_INTERVAL_FREQ (HZ) #endif ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP + kernel frequency
David Woolley wrote: I'm not familiar with frequency scaling, but I would suggest that if the kernel interrupt rates are not constant, ntpd also won't be entirely reliable. Dave Mills complains from time to time that the Linux kernel doesn't adjust the kernel PLL parameters correctly when the clock rate is varied from 100 Hz to another fixed rate, so I very much doubt that the kernel PLL code has been correctly modified to cope with a dynamically variable interrupt rate. There is also an issue that the fixed speed code rounds things in a way that only certain rates are safe. The kernel interrupt rate is a better indication of what really matters (except that it will read low if you are losing interrupts) than HZ, if there is any systematic difference between them. If a developer for that code doesn't raise their head here, now, I think it pretty much safe to assume that the machine is not suitable for ntpd use for anything except a pure client with low time quality expectations. Basically, if the developers are not monitoring this news group, it is almost certain that they not properly taken into account ntpd's needs. As a user of ntpd on Linux, I find it disheartening to hear that Linux kernel hackers do not work more closely with NTP hackers. (It'd be nice to have PPS support in the vanilla kernel.) The latest patches to kernel/time/ntp.c can be seen here: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=history;f=kernel/time/ntp.c ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Reference clock all messed up?
Adam Bolte wrote: Hi Danny, Add iburst to this line for faster synchronization Thanks, but being an PDC I really didn't want the clock to change too quickly. This may seem strange not already having NTP, but the network setup has recently changed which is what broke NTP in the first place. The iburst option has nothing to do with changing quickly. It has to do with initial synchronization with the remote NTP server. If you are that worried about changes happening too quickly add the -x option to slew always. I don't recommend it even on a PDC. driftfile /var/db/ntpd.drift # by default ignore all ntp packets restrict default ignore Why would you want to ignore all packets? All but the exceptions underneath. I don't want untrusted networks messing with my NTP server. I don't control the firewall, so I want to do what I can in the NTP config. Even if I did, I would rather this in case the firewall ever breaks. If the firewall breaks NTP is the least of your problems. I'd hardly be worrying about that. Add -g to the command line to get it to initially no panic and to set the clock. Again, not sure if this is safe on a PDC. It's perfectly safe. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Inexpensive OEM GPS units?
Once upon a time, David Woolley [EMAIL PROTECTED] said: Normally, finding any systematic offset would require the temporary use of a time source that was better than your normal time sources. As I think you are using USB, which is likely to have a significant impact, you would also need to bypass this, either by temporarily feeding the system with time through a route with lower latency, or by outputting the system's idea of the time through a low latency route and comparing it outside of the system. Okay, that's what I figured. I've only got one serial port (and it is a console), so I don't have any other way to connect but USB (also, I'm using a USB to serial adapter to pull +5V from the USB port). Everyone keeps saying that USB must be bad, but I was trying to see just how much impact USB has. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Inexpensive OEM GPS units?
Once upon a time, Steve Kostecke [EMAIL PROTECTED] said: What does ntpq -p show? $ ntpq -p remote refid st t when poll reach delay offset jitter == -fly.hiwaay.net 192.5.41.40 2 u2 64 377 16.3519.846 1.449 +lashiir.sapros. 74.53.198.1463 u 36 64 377 48.5936.778 0.636 +newton.8086.net 209.51.161.238 2 u 39 64 377 27.0755.322 0.970 -ntp.unknowndevi 18.26.4.105 2 u 52 64 377 51.295 -9.173 6.805 LOCAL(0).LOCL. 10 l 52 64 3770.0000.000 0.002 xGPS_NMEA(0) .GPS.0 l 11 64 3770.000 143.198 56.164 *SHM(0) .SHM.0 l2 16 3770.000 -0.195 0.541 $ The PPS is run via shm_splc2, so the GPS_NMEA is guaranteed to be off (but it gets the date/time info). This is using pool servers plus an ISP server (across a DSL link from my box). -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Inexpensive OEM GPS units?
On 2007-11-19, Chris Adams [EMAIL PROTECTED] wrote: Once upon a time, Steve Kostecke [EMAIL PROTECTED] said: What does ntpq -p show? $ ntpq -p remote refid st t when poll reach delay offset jitter === snip xGPS_NMEA(0) .GPS. 0 l 11 64 3770.000 143.198 56.164 *SHM(0) .SHM. 0 l2 16 3770.000 -0.195 0.541 Compare your PPS over USB with PPS on a real serial port: rackety.udel.edu remote refid st t when poll reach delay offset jitter === +SPECTRACOM(1) .GPS1. 0 l 21 64 3770.000 0.004 0.004 oPPS(0).PPS.0 l5 16 3770.000 0.002 0.004 The GPS-18LVC connected to a real serial port on my Soekris would show jitter of 0.008 and a typical daily peersum (with peer.awk) looked like: ident cnt mean rmsmax delay dist disp 127.127.20.0 5235 0.000 0.002 0.014 0.000 0.270 0.248 -- Steve Kostecke [EMAIL PROTECTED] NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Inexpensive OEM GPS units?
Chris Adams wrote: Once upon a time, Steve Kostecke [EMAIL PROTECTED] said: What does ntpq -p show? $ ntpq -p remote refid st t when poll reach delay offset jitter == -fly.hiwaay.net 192.5.41.40 2 u2 64 377 16.3519.846 1.449 +lashiir.sapros. 74.53.198.1463 u 36 64 377 48.5936.778 0.636 +newton.8086.net 209.51.161.238 2 u 39 64 377 27.0755.322 0.970 -ntp.unknowndevi 18.26.4.105 2 u 52 64 377 51.295 -9.173 6.805 LOCAL(0).LOCL. 10 l 52 64 3770.0000.000 0.002 xGPS_NMEA(0) .GPS.0 l 11 64 3770.000 143.198 56.164 *SHM(0) .SHM.0 l2 16 3770.000 -0.195 0.541 $ The PPS is run via shm_splc2, so the GPS_NMEA is guaranteed to be off (but it gets the date/time info). This is using pool servers plus an ISP server (across a DSL link from my box). I run a Garmin GPS 18 LVC over serial, and get the PPS signal via the shmpps (shm_splc2) driver. Here is my 'ntpq -p' and 'ntpq -crv': saturn:$ ntpq -p remote refid st t when poll reach delay offset jitter == *SHM(0) .PPS.0 l 13 16 3770.0000.000 0.001 -bigben.cac.wash .USNO. 1 u 26 64 377 13.568 -1.107 2.694 -clepsydra.dec.c .GPS.1 u 37 64 377 32.296 -1.607 3.923 -time.sdsc.edu .WWVB. 1 u4 64 377 41.676 -4.008 2.228 -clock.sjc.he.ne .CDMA. 1 u5 64 377 33.254 -1.262 1.950 +tick.ucla.edu .GPS.1 u 48 64 377 42.264 -0.820 6.585 +clock.xmission. .GPS.1 u4 64 377 51.862 -0.540 1.430 saturn:$ ntpq -crv assID=0 status=0964 leap_none, sync_telephone, 6 events, event_peer/strat_chg, version=ntpd [EMAIL PROTECTED] Sun Oct 7 00:42:35 UTC 2007 (2), processor=i686, system=Linux/2.6.17-5mdv, leap=00, stratum=1, precision=-20, rootdelay=0.000, rootdispersion=0.243, peer=28353, refid=PPS, reftime=caebb9b5.a65ccee4 Sun, Nov 18 2007 23:28:53.649, poll=4, clock=caebb9b6.5599d760 Sun, Nov 18 2007 23:28:54.334, state=4, offset=0.000, frequency=-22.465, jitter=0.001, noise=0.001, stability=0.000 -- Dennis Hilberg, Jr. timekeeper(at)dennishilberg(dot)com NTP Server Information: http://saturn.dennishilberg.com/ntp.php ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance of NTP under Windows Vista?
On Wed, 14 Nov 2007 06:26:48 GMT, David J Taylor [EMAIL PROTECTED] wrote for the entire planet to see: Does anyone have any measurements of NTP running under Windows Vista? In particular, the Meinberg foehr 1520 version? Hi David - I'll let you know when my first PC is upgraded to Vista, oh in five or six years maybe. Win2K is still on almost all my windows boxen. One or two are running XP. Good luck. - Eric ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Inexpensive OEM GPS units?
Hi there John Ioannidis wrote: Out of curiosity: what is wrong with the Garmin GPS 18LVC that someone would like to look at an alternative? At $70, it's practically free. Where can get one in Europe? USD 68.50 is ca € 50.- Some EU webshops sell it for € 114.-, which is ca USD 156.- Or can I order one from the Garmin site? Regards, Rob -- Avoid alphabet soup. Include the charset in your HTML header; META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=Your_Charset ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance of NTP under Windows Vista?
Eric wrote: On Wed, 14 Nov 2007 06:26:48 GMT, David J Taylor [EMAIL PROTECTED] wrote for the entire planet to see: Does anyone have any measurements of NTP running under Windows Vista? In particular, the Meinberg foehr 1520 version? Hi David - I'll let you know when my first PC is upgraded to Vista, oh in five or six years maybe. Win2K is still on almost all my windows boxen. One or two are running XP. Good luck. - Eric Thanks, Eric. Unfortunately people who are running Vista today will not be able to wait! Good luck with your unsupported OS. I've done some measurements and report here: http://www.david-taylor.myby.co.uk/ntp/NTP-on-Windows-Vista.html I don't currently understand the behaviour, as it seemed to take several days to reduce the offset by a hundred milliseconds (averaged), whilst showing a lot of intermediate noise, followed by sudden cessation of the noise when the offset was near zero. I'd love to hear from anyone who has made comparative performance measurements, or who has suggestions as to how to proceed. Thanks, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] move_fd() causing bad behavior on AIX5.3
In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes: brandon ntp-4.2.4p4 / AIX 5.3 This was annoying to chase down because I brandon guess it's also screwing up the fds used to log errors. The brandon symptom is that ntpd exits silently due to a bind() error, but only brandon when daemonized. Running under some debugging tools, such as brandon Aprobe, changes the behavior (no failure), possibly because of brandon additional fd usage. brandon This sounds like bug #604 brandon (https://support.ntp.org/bugs/show_bug.cgi? id=614). Was that brandon ever confirmed fixed for AIX5? Did you mean bug 604 or 614? Regardless, both are marked FIXED, and 604 has been VERIFIED. Another reason why bugs sometimes do not appear under a debugger is when the debugger initialized variables. brandon I haven't looked into exactly how move_fd() is screwing up, but brandon ntpd is happy on my test box with the call to it removed entirely. We don't do much testing under AIX because we don't have easy access to a box. An additional approach would be to use some of the assertion stuff in include/ntp_assert.h and see if you can get something to violate an assertion. And if you can shed any light on bugs 135, 309, 598, or 716, that would be swell, too. H ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance of NTP under Windows Vista?
Ryan Malayter wrote: On Nov 19, 12:15 pm, David J Taylor [EMAIL PROTECTED] this-bit.nor-this-bit.co.uk wrote: I don't currently understand the behaviour, as it seemed to take several days to reduce the offset by a hundred milliseconds (averaged), whilst showing a lot of intermediate noise, followed by sudden cessation of the noise when the offset was near zero. I'd love to hear from anyone who has made comparative performance measurements, or who has suggestions as to how to proceed. My previous reading indicates that Vista and Server 2008 have had significant changes to their internal timing architecutre, mostly to better support multi-media and near-real-time applications, as well as enhanced power management. So I think, perhaps, ntpd might be making assumptions that no longer apply in the Vista world. I am unsure of the complete changes, however. There is also this bug in the Vista driver for the High Precision Event Timer, which is available on newer hardware: http://support.microsoft.com/kb/933272. I would test with that patch. We only have Vista on laptops at the moment, with variable connectivity and lots of sleep/wake cycles. So we just use the built- in Windows Time Service, which handles those conditions well enough to keep things within 100ms or so. Ntpd did not behave well in my previous tests with various network interfaces coming on and off (Wired Etherenet, WiFi, and EVDO connections are used intermittently throughout the day on all of our laptops). Plus power modes changing all the time. I will check into deploying ntpd on Vista desktops as soon as we get one deployed, but we only seem to be deploying laptops these days. Thanks, Ryan. You may well be correct about the changes, but I had read here some time ago about the performance being satisfactory under Vista from (IIRC) Heiko who is usually quite thorough. Noted on the pointer to the patch, but that doesn't seem to relevant in that this PC is permanently on, and not rebooted. Of course, the patch may do more than just fix the restart issue.. Interesting about the desktops - out of fashion! Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Performance of NTP under Windows Vista?
On Nov 19, 12:15 pm, David J Taylor [EMAIL PROTECTED] this-bit.nor-this-bit.co.uk wrote: I don't currently understand the behaviour, as it seemed to take several days to reduce the offset by a hundred milliseconds (averaged), whilst showing a lot of intermediate noise, followed by sudden cessation of the noise when the offset was near zero. I'd love to hear from anyone who has made comparative performance measurements, or who has suggestions as to how to proceed. My previous reading indicates that Vista and Server 2008 have had significant changes to their internal timing architecutre, mostly to better support multi-media and near-real-time applications, as well as enhanced power management. So I think, perhaps, ntpd might be making assumptions that no longer apply in the Vista world. I am unsure of the complete changes, however. There is also this bug in the Vista driver for the High Precision Event Timer, which is available on newer hardware: http://support.microsoft.com/kb/933272. I would test with that patch. We only have Vista on laptops at the moment, with variable connectivity and lots of sleep/wake cycles. So we just use the built- in Windows Time Service, which handles those conditions well enough to keep things within 100ms or so. Ntpd did not behave well in my previous tests with various network interfaces coming on and off (Wired Etherenet, WiFi, and EVDO connections are used intermittently throughout the day on all of our laptops). Plus power modes changing all the time. I will check into deploying ntpd on Vista desktops as soon as we get one deployed, but we only seem to be deploying laptops these days. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] move_fd() causing bad behavior on AIX5.3
ntp-4.2.4p4 / AIX 5.3 This was annoying to chase down because I guess it's also screwing up the fds used to log errors. The symptom is that ntpd exits silently due to a bind() error, but only when daemonized. Running under some debugging tools, such as Aprobe, changes the behavior (no failure), possibly because of additional fd usage. This sounds like bug #604 (https://support.ntp.org/bugs/show_bug.cgi? id=614). Was that ever confirmed fixed for AIX5? I haven't looked into exactly how move_fd() is screwing up, but ntpd is happy on my test box with the call to it removed entirely. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] move_fd() causing bad behavior on AIX5.3
In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes: brandon Oops, 614 is what I meant. I did see that it is closed, but the brandon comments on it left me with some doubt about whether it had been brandon verified on AIX5 specifically. VERIFIED means the person who opened the issue has verified that the fix we committed works for them. Mostly, the code in NTP is general code, so if we fix something in that area of the code it worke everywhere. If there is a problem in an OS-specific area, when we get a bugfix and that problem is marked as VERIFIED, it means that the fix worked. There have been (rare) cases where OS-specific issues are different between different releases of an OS. Unless we can actually work on these cases ourselves (and often in these cases we need to work with the kernel or system-library engineers) we really can't make lots of progress in certain cases. When this happens we just wait, as either the vendor will fix things or we'll get a patch from somebody who is in a better position to work on the problem than we are. brandon ... We were interested in NTPv4 for the brandon ability to really always slew (tinker step 0) since our software is brandon allergic to time stepping. We may abandon the idea though, due to brandon lack of confidence in the maturity of NTPv4 on AIX5. The general NTPV4 code is very well tested. There are definitely AIX-specific areas of the code that we cannot easily test, but we would only know about problems if somebody opened a ticket on them, and the odds are that a fix will appear sooner if somebody is able to dig in to the problem and find the fix. Please note that there are cases where we can work around kernel problems. An example would be in configure.ac, near line 3843, where we avoid a kernel FLL bug in certain patch levels of Solaris 2.6 and 2.7. And if you can shed any light on bugs 135, 309, 598, or 716, that would be swell, too. brandon 135, 716: still exist. I had to explicitly compile away IPv6 brandon support to resolve the issue. At least this lets me know that the disable IPv6 code is working well enough! brandon 309: I don't think our setup would hit this so can't comment. brandon 598: This is interesting since it also complains about the xntpd brandon IBM ships (which we currently use as well). We have had some brandon issues with the clocks jumping back to 0:00...1970 after reboots; I brandon believe we finally convinced IBM there was a problem. The other brandon issues discussed in this bug I am not sure about; we'll have to brandon investigate and see if they are contributing to time related brandon pecularities. I'd appreciate any help you can offer in resolving any of these issues, and I'm happy to help in any way I can as well. H ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Details about code structure
Hi All, Which will be the best document to refer if I need to know information about the organization of code in ntp? I am looking for information like, * a convenience library is created in libopts directory which is further used to link against the final exe * a library is created in libntpd to be linked against ntpd * ntpd uses libs made in libopts + libntpd and so on. One obvious way is to look at the makefile.am in each directory to figure out what is made out of what? But I thought I will put it across to everyone to see if there is any documentation related to this. Also is there a design doc that talks about this or other details? -- Prathap mobile: +91 99465 56643 Pivot Systems http://www.pivotsys.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
