Re: [ntp:questions] Red Hat vote for chrony

2014-12-12 Thread Michael Deutschmann
second reads, writes and trimming and then it would become quite useful. Especially since it would free the OS to do anything it wants with the IRQ0 timer without disrupting wallclock time. "Tickless" kernels have been a thorn in the side of

Re: [ntp:questions] NTP server not reducing polling interval on upstream hosts

2014-10-22 Thread Michael Deutschmann
nd it (assuming, that is, that the full argument can be defended...). Michael Deutschmann ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP server not reducing polling interval on upstream hosts

2014-10-17 Thread Michael Deutschmann
out two holes in the argument, with no one posting a defense in the interim. The first is that polling at 64 isn't enough to stop an excursion under bad PPS, and the second is that reference clocks aren't likely to falsetick. Michael Deutschmann ___

Re: [ntp:questions] ESR looking for good GPS clocks

2012-03-03 Thread Michael Deutschmann
sor, and its omission probably saves only a fraction of a cent per device. Yet ESR faces a more than $100 markup to have it put back. ---- Michael Deutschmann ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ESR looking for good GPS clocks

2012-03-03 Thread Michael Deutschmann
On Sat, 3 Mar 2012, Chris Albertson wrote: > On Fri, Mar 2, 2012 at 4:03 PM, Michael Deutschmann > > (Not my dream though.  If I was to go to the trouble of installing a box > > outside my home and routing a cable through the wall to my computers, > > I'd like some weat

[ntp:questions] ESR looking for good GPS clocks

2012-03-02 Thread Michael Deutschmann
ot my dream though. If I was to go to the trouble of installing a box outside my home and routing a cable through the wall to my computers, I'd like some weather sensors in the deal as well as just time...) Michael Deutschmann ___ questions m

Re: [ntp:questions] ntpd wedged again

2012-02-15 Thread Michael Deutschmann
fed "Sorry, I'm not sure anymore" rather than lies. Michael Deutschmann ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.

2009-10-20 Thread Michael Deutschmann
sers than, say, BT Group... Michael Deutschmann ___ 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...

2009-10-18 Thread Michael Deutschmann
rference will be trapped inside. So unless you are trying to get GPS reception indoors, and the noisy computer is your own, you are in much better shape than the WWV or WWVB clients. They often have to deal with interference sources that are between them and the transmitter they want. Mic

Re: [ntp:questions] If the EMI shoe was on the other foot...

2009-10-17 Thread Michael Deutschmann
ose 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 ___ questions mailing list questions@

Re: [ntp:questions] If the EMI shoe was on the other foot...

2009-10-17 Thread Michael Deutschmann
ter 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 ___ questions mailing list question

[ntp:questions] If the EMI shoe was on the other foot...

2009-10-09 Thread Michael Deutschmann
pens to be the same frequency as a highly useful public radio clock signal. Would the experts here then want the government to mandate spread spectrum be ON, and if so, what sort of modulation to use? ---- Michael Deutschmann ___ questions mailing list

Re: [ntp:questions] Linux and mlockall()

2008-12-26 Thread Michael Deutschmann
the cure is simple: When a resolver process is forked, it's first act should be to reset the stack limit to what it was in the first place. There's no worry about overcommitting real memory, because mlockall() is not inherited across forks. Michael Deutschmann _

[ntp:questions] Linux and mlockall()

2008-12-18 Thread Michael Deutschmann
t ntpd before named. So it should be safe for me to hack the configure script so mlockall() is used anyway, right? Also, calling this a "Linux" problem is likely careless. I'd imagine the root of the incompatibility is probably in the GN

Re: [ntp:questions] Getting SNTP to accept large corrections

2008-01-18 Thread Michael Deutschmann
ter 2038-01-19T03:14Z. That should be enough to nail down which NTP era to use. (Interesting -- as I write this it is almost exactly 30 years from the End of Unix Time.) If you do have 64-bit time_t, why not just read your filesystem's timestamp on the drift file? --