Re: [ntp:questions] Ruh, roh. Leap Second?
Martin, There can be a disconnect of serveral months between some gimmick in the development branch and when it appears on supermarket shelves; however, the current version does explicitly announce impending leaps in the protostats file and does take a vote among the sources on whether to mark the calendar for a leap. All this is overridden if the NIST leapseconds file is present. Dave Martin Burnicki wrote: Dave, David L. Mills wrote: Peter, I head the same comment over the jungle telegraph. However, in the distributions that leave here there is no such comment, so it would have to come from somewhere else or from a modified distribution. The message: Clock: inserting leap second 23:59:60 UTC can be found in the Linux kernel sources. So this indicates ntpd has indeed received a leap second announcement from an upstream time source and has passed that announcement to the kernel which has then inserted the leap second. AFAIK that's the way leap seconds should be handled on systems which provide a kernel PLL. The following time reset happened after that to undo the faulty leap second and step back to the correct time. So the basic question is from which upstream time source the faulty leap second announcement has been received. To help spot feckless fingers, recent versions have a protostats file in the statistics collection and official reports go there, as well as the system log if configured. These reports are described in the decode.html page in the docuentation. I'm not familiar with the protostats file, but I assume it is only generated if explicitely configured in ntp.conf, similar to the other stats files. Since such faulty leap second announcements have been reported here several times I'd really appreciate if there would be a log entry generated by default if a leap second announcement is received. That log entry should also indicate from which time source that announcement has been received, so a faulty time source could easily be identified and fixed or discarded in order to prevent those faults the next time. Martin ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Utility to measure time drift
I'm looking for a utility like clockdiff(8) to measure the time delta between different machines. The utility itself should run on Windows, but the machines under investigation are running Linux. Thanks, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Utility to measure time drift
jkvbe [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'm looking for a utility like clockdiff(8) to measure the time delta between different machines. The utility itself should run on Windows, but the machines under investigation are running Linux. The usual approach is to set up a machine that has all the machines under scrutiny as servers in its NTP configuration, possibly all marked noselect - I'm not sure about that bit. Ntpq -p will then tell you the offset to them all, relative to a single base (the monitoring server's own notion of time). Note that this is subject to all the vagaries of normal NTP life. If the DSL connection to one server is heavily overloaded, the offset will reflect that. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Ruh, roh. Leap Second?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Peter Laws) writes: 1 Time(s): Clock: inserting leap second 23:59:60 UTC RHEL 5.2 system running ntpq [EMAIL PROTECTED] Thu Jan 17 18:14:14 UTC 2008 (1) which is the default for that distribution. Grepping around in the logs it appears that most or all of my RHEL systems did it. I got this, too, on at least one system: Jun 30 19:34:53 ozz-1300 ntpd[2659]: time reset +1.000360 s Humm. I got one too, back in 2005, 6 months ahead of the last leap second. I wonder what was going on back then, Jun 21 01:09:33 shuksan ntpd[1794]: ntpd [EMAIL PROTECTED] Thu Apr 14 07:47:25 EDT 2005 (1) Jun 30 16:59:59 shuksan kernel: Clock: inserting leap second 23:59:60 UTC Jun 30 17:57:14 shuksan ntpd[1794]: time reset +1.014226 s -- 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] Generating keys for ntpdc control
Can someone run me through the steps necessary to generate, and apply keys so I can use ntpdc to make on the fly changes to ntpd? I've read through the docs - repeatedly! - and tried every incarnation of ntp-keygen listed. What I seem not to be able to get is what the key number represents. I suspect that it's got something to do with the -v option where it generates numbered keys, but creating them with a password ,and then specifying one - like key 1 - after entering password in ntpdc results in the cursor simply staring back at me. The keygen section of the docs includes the statement Following hte heard the keys are entered one per line in the format keyno type key, which I suspect is a typo, but I'm still not getting it. I suspect there needs to be a file referring to what key number is what. I'm running the current Meinberg windows port. This comes about because of a question I asked last week about KOD. It was suggested that I could use ntpdc to effect the necessary changes by either setting up symmetric keys or disabling authentication. Well, I didn't have any luck with the keys, so I disabled authentication. That didn't work for two reasons: ntpdc still wouldn't talk to ntpd, and I found that someone at 66.80.7.58 does know how to reconfigure ntpd remotely. I looked at my logs on the morning of 26 June, and found that I was now polling that address several times a second for time. Looking at my host server list, I showed that address listed about 20 times as mode 1 (whatever that is???) I didn't do it, and it wasn't in the config file.Also, it started after I disabled auth. Enabling auth, and restarting fixed it, although he kept trying for the rest of the day. I think the intention was to make himself an authoritive source and force my clock to drift, as his incoming timestamps looked to be off by at least a minute. Hackers. And not the good definition, either. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
