On 04-02-19 22:14, Gary E. Miller via devel wrote:
> Stupid typo. My fault. Thanks to Achimm for bisecting it. Fix pushed.
>
> Thank you for your report. Sorry for the trouble.
Thank you for the -quick- fix!
Kind regards,
Udo
___
devel mailing list
On 2/4/19 7:34 PM, Hal Murray via devel wrote:
> if they get converted to VoIP with typical who-knows
> type routing.
Very often, yes, but not always.
BTW, the example mentioned for the modem was ACTS + lockclock. I think
that's how NIST (at least used to) build out additional time server
instal
On Mon, Feb 04, 2019 at 05:34:56PM -0800, Hal Murray wrote:
> > Now, if it doesn't meet our accuracy thresholds, that's another story.
>
> Do we have any accuracy standards?
See https://www.ntpsec.org/drivers.html
INACCURATE
Remove GPS drivers and time radios for which the hardware offers no bet
> Now, if it doesn't meet our accuracy thresholds, that's another story.
Do we have any accuracy standards?
Given the screwups that can happen with bufferbloat, I'll bet it works much
better than some network connections.
It would be interesting to measure the delays on dial up lines. I wonder
On Mon, Feb 04, 2019 at 01:39:48PM -0500, Eric S. Raymond via devel wrote:
> I found a documentation error.
>
> The page for the modem driver says:
>
> This driver requires a 9600 bps modem with a Hayes-compatible command
> set and control over the modem data terminal ready (DTR) control
Hal Murray :
> What's wrong with just adding 2000 to 2 digit years? We are in the 2000s now
> so we don't have to consider the 1900 case any more. I'd be happy to
> reconsider dropping support for 2-digit drivers in another 30 years.
Grrr. Smacks of kicking the can down the road rather than at
Achim Gratz via devel :
> You can have all these errors with four digit years.
Of course we can. I'm not claiming that disqualifying these sources
with 2-digit year reports will solve the problem, just reduce the
number of failure modes and the difficulty of reasoning about them.
--
Achim Gratz via devel :
> I visited DEC in Palo Alto one time and got to see the very first Alpha
> mainboard (with an alcohol heatpipe made from a glass tube atop the
> CPU).
Damn shame about the Alpha. That was a good design that DEC utterly botched the
positioning and marketing of.
Back around
> My instinct in situations like this is to try to find a way to reduce the
> combinatorial complexity of the problem. Which is why I'm attracted to
> disqualifying any time source that truncates years.
What's wrong with just adding 2000 to 2 digit years? We are in the 2000s now
so we don't
Richard said:
> That said, on a Pi, if you write the time to a file on shutdown, then you
> will be accurate enough for certificate checks to pass on reboots and outages
> shorter than a couple months.
Eric said:
> Thanks, it's important to know the order of magnitude of the slack there.
At sh
Gary E. Miller via devel writes:
> I found it. Stupid typo. Fix coming.
Fix confirmed.
> Once again: thanks for the bisect.
My pleasure.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synt
Yo Udo!
On Mon, 4 Feb 2019 16:51:43 +0100
Udo van den Heuvel via devel wrote:
> I noticed that using latest git for ntpsec `/bin/ntpq -c
> kerninfo|/bin/awk -e '/pll offset:/ {o=$3; if (o < 0) o = -o; print
> o*100;}' -e '/estimated error/ {print $3*100;print 1;print
> "ntpstat"}'` does
Yo Achim!
On Mon, 04 Feb 2019 22:06:27 +0100
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> > The end result is:
> >
> > char buffer[200];
> > char buf[50];
> >
> > strlcpy(buffer, tag, sizeof(buffer));
> > snprintf(buf, sizeof(buf), use_f ? "=%
Gary E. Miller via devel writes:
> The end result is:
>
> char buffer[200];
> char buf[50];
>
> strlcpy(buffer, tag, sizeof(buffer));
> snprintf(buf, sizeof(buf), use_f ? "=%.*f" : "%.*g", precision, d);
> strlcat(buffer, buf, sizeof(buffer));
>
> ctl
Yo Achim!
On Mon, 04 Feb 2019 21:37:35 +0100
Achim Gratz via devel wrote:
> This defect bisects to the unlikely commit:
here is the entire change:
@@ -1198,21 +1198,14 @@ ctl_putdblf(
double d
)
{
- char *cp;
- const char *cq;
- char buffer[200];
+
Yo Achim!
On Mon, 04 Feb 2019 21:37:35 +0100
Achim Gratz via devel wrote:
> Udo van den Heuvel via devel writes:
> > I noticed that using latest git for ntpsec `/bin/ntpq -c
> > kerninfo|/bin/awk -e '/pll offset:/ {o=$3; if (o < 0) o = -o; print
> > o*100;}' -e '/estimated error/ {print $3*1
Udo van den Heuvel via devel writes:
> I noticed that using latest git for ntpsec `/bin/ntpq -c
> kerninfo|/bin/awk -e '/pll offset:/ {o=$3; if (o < 0) o = -o; print
> o*100;}' -e '/estimated error/ {print $3*100;print 1;print
> "ntpstat"}'` does no longer provide me with a pll offset nor a
Eric S. Raymond via devel writes:
> The failure cases are really hard to think about. There are all kinds
> of potential interactions among century error due to two-digit years,
> 32-bit wraparound in peer timestamps, unknown pivot dates on peers,
> GPS-era rollovers, unknown pivot dates in GPS fir
Hal Murray via devel writes:
> You can check that by looking at your syslog and/or ntp log files.
>
> The details may depend on the OS/Distro.
>
> From a clean reboot on Fedora, Pi 3.
> 2 Feb 17:46:14 ntpd[489]: PROTO: 192.168.1.33 unlink local addr 192.168.1.71
> ->
> 2 Feb 17:46:14 ntpd[489]:
Hal Murray via devel writes:
> Here is an example that I've encountered. Suppose you have 6 servers with
> minsane set to 3 all using each other. When recovering from a power failure
> everybody ends up waiting for everybody else to get started.
Bootstrapping such configurations is indeed not
I found a documentation error.
The page for the modem driver says:
This driver requires a 9600 bps modem with a Hayes-compatible command
set and control over the modem data terminal ready (DTR) control line.
The actual line speed ranges from 1200 bps with USNO to 14,400 bps
with N
Another complication with getting started after a building/site wide power
loss is that getting time needs DNS and the local caching DNS server may be
waiting for valid time.
We may need a local cache - /etc/hosts? and a cron job to keep it up to date.
--
These are my opinions. I hate spam
On 2/4/19 11:37 AM, Eric S. Raymond wrote:
> Richard Laager via devel :
>> That said, on a Pi, if you write the time to a file on shutdown, then
>> you will be accurate enough for certificate checks to pass on reboots
>> and outages shorter than a couple months.
>
> Thanks, it's important to know
Richard Laager via devel :
> That said, on a Pi, if you write the time to a file on shutdown, then
> you will be accurate enough for certificate checks to pass on reboots
> and outages shorter than a couple months.
Thanks, it's important to know the order of magnitude of the slack there.
--
On 2/3/19 5:48 PM, Hal Murray wrote:
> [getting started]
>> How do certificates make this more complicated?
>
> Checking certificates depends on time.
>
> It may be a non problem if your system has a RTC/TOY clock. But they break.
> Raspberry Pis don't have them, ...
Right. We are going to ev
Hello,
I noticed that using latest git for ntpsec `/bin/ntpq -c
kerninfo|/bin/awk -e '/pll offset:/ {o=$3; if (o < 0) o = -o; print
o*100;}' -e '/estimated error/ {print $3*100;print 1;print
"ntpstat"}'` does no longer provide me with a pll offset nor an
estimated error.
What are the alter
On 2/4/19 7:10 AM, Eric S. Raymond via devel wrote:
Mark: Heads up! Policy question ahead.
The position we *could* take, which I admit I'm attracted to, is this:
NTP is not a dorm-room project, it's vital infrastructure for
life-critical systems. It's 2019 and decent refclocks are cheap, so th
Hal Murray :
> > If the zero date was in the last century and your local refclock only ships
> > a
> > two-digit date, you have a problem. NTP will cheerfully "correct" the time
> > into the last century. This is a real problem case with RasPis or
> > BeagleBones using a vanilla NMEA GPS. So muc
> (I thought the RasPi stored a timestamp on a clean shutdown, then reads it
> back at boot time, so time is usually not actually zeroed. But I don't know
> that, and no such fallback is mentioned aty that link.)
You can check that by looking at your syslog and/or ntp log files.
The details ma
Mark: Heads up! Policy question ahead.
Some of our remaining refclocks return only 2-digit years, relying on
the system clock to disambiguate the century.
On conventional PCs this is seldom a problem. There's a time value
returned by an RTC (real-time clock) which the kernel reads, and
changes
30 matches
Mail list logo
