[ntp:questions] Never Step
I am trying to make NTP work so it never goes into Step mode. If the time difference is greater than the Panic threshold I want to exit (and never get a time value). If the time difference is greater than the Slew threshold I want to exit (and not Step). If the time difference is less than the Slew threshold I want to Slew. Any help or suggestions will be greatly appreciated. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] If the EMI shoe was on the other foot...
On Sat, 10 Oct 2009, David Woolley wrote: The general view in the amateur radio community is that spread spectrum computer clocks are a bad thing, because they spread the misery. So we can turn off spread spectrum with no guilt, then. The reason I was asking is that I'd expect most hackers to be biased in their assessment of any EMI mitigation proposal with costs. We don't use radio much these days, so non-ionizing radiation would have to be really intense to rattle us. The real-life clock radio stations are all lower frequency than the FSB of even the slowest computer with support for SS, so even the stratum 1 folks don't have any interest on the EMC side of this issue. (They do care about other EMI sources that fall in their playground, of course.) Michael Deutschmann mich...@talamasca.ocis.net ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] If the EMI shoe was on the other foot...
Michael Deutschmann wrote: On Sat, 10 Oct 2009, David Woolley wrote: The general view in the amateur radio community is that spread spectrum computer clocks are a bad thing, because they spread the misery. So we can turn off spread spectrum with no guilt, then. The reason I was asking is that I'd expect most hackers to be biased in their assessment of any EMI mitigation proposal with costs. We don't Not sure which direction of bias you were expecting. The computer fashion junkies, with their case modding obviously don't care, but... use radio much these days, so non-ionizing radiation would have to be really intense to rattle us. A lot of the key developers of the internet were radio amateurs. Dave Mills, who developed NTP is one. I'm not sure of the current status in the commercialised world, but it wouldn't surprise me if the more technical companies had a lot. The real-life clock radio stations are all lower frequency than the FSB of even the slowest computer with support for SS, so even the stratum 1 folks don't have any interest on the EMC side of this issue. (They do care about other EMI sources that fall in their playground, of course.) The most important radio time standard is GPS, which is in the low GHz. EMI is at submultiples of the raw FSB side because instruction rates and loop rates also introduce strong periodic elements. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] If the EMI shoe was on the other foot...
David Woolley writes: EMI is at submultiples of the raw FSB side because instruction rates and loop rates also introduce strong periodic elements. Which spread-spectrum (especially real spread spectrum, less so mere FM) mitigates. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Running two ntpd systems in parallel
On Mon, Sep 14, 2009 at 11:23 AM, Paul Fleischer p...@xpg.dk wrote: First, the network communication will be moved to another port that 123. Let's assume it's 1234 for now. I would like to see ntpd support unprivileged operation for testing purposes, including using a local port 1024. The approach I have been considering is adding a port option to the association commands like server and peer in ntp.conf, with the secondary or unprivileged ntpd still defaulting to remote port 123. Second, rather than using clock_gettime() and adjtime() it will use calls that modify a second clock which is implemented in the Linux kernel. For my purposes, a test unprivileged ntpd would modify a fictional system clock composed within ntpd using the real system clock modified by frequency and offset changes which normally would be applied to the system clock. This is a trickier bit of code to get right than the UDP port change. I'm curious how your second clock would be used, and what mechanism might be used to let you cleanly intercept the clock-affecting calls without requiring local patches to the NTP code. If I run the modified ntpd with the above configurations, it seems that the communicate with each other. However, ntpq behaves strange. Running ntpq -c peers on PC2 gives: remote refid st t when poll reach delay offset jitter == Running ntpq -c lassociations on PC2 gives: ind assID status conf reach auth condition last_event cnt === 1 10139 8000 yes yes none reject 2 10140 9614 yes yes none sys.peer reachable 1 Your patch missed a questionable bit of code I coincidentally am likely to remove from ntpq-subs.c do_printpeers() line 1571: /* * Check to see if the srcport is NTP's port. If not this probably * isn't a valid peer association. */ if (havevar[HAVE_SRCPORT] srcport != NTP_PORT) return (1); Remove that code and your ntpq should be much happier. It appears to have been added as a sanity check, but it's not a very good one. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] If the EMI shoe was on the other foot...
On Sat, 17 Oct 2009, David Woolley wrote: Not sure which direction of bias you were expecting. The computer fashion junkies, with their case modding obviously don't care, but... Against SS. The most important radio time standard is GPS, which is in the low GHz. But those are mostly-vertical line of sight transmissions. Unless the translucent-case computers are sitting in a zeppelin parked between you and the satellite, they shouldn't hurt very much. Michael Deutschmann mich...@talamasca.ocis.net ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
