[questions] Re: NTP community feels broken

[Paul G]

On Friday, June 17, 2022 at 2:24:05 PM UTC-4, chris wrote:
> That's correct, but the various issues with the system have been 
> discussed for years, yet nothing ever gets done about it. That's the 
> point that Philip above was making... 

Of course working with Harlan is difficult. Coming here to advise us of that 
won't result in any changes. Fortunately there are alternatives so there's no 
need to fret about the "reference" implementation.

The issue with your posts is that they were confusing. Or wrong.
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: NTP community feels broken

[Paul G]

On Friday, June 17, 2022 at 2:33:35 PM UTC-4, David Woolley wrote:
> On 17/06/2022 19:14, Paul G wrote: 
> > Where is it in this 
> > tarball:http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.8p15.tar.gz
> >  
> > 
> > If it's not there then you're probably in the wrong list/group.
> This group is about the NTP protocol

I said probably because other major projects have (or should have) their own 
discussion channels.
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: NTP community feels broken

[Paul G]

On Friday, June 17, 2022 at 2:12:52 PM UTC-4, chris wrote:

> Nothing to do with products. ntp.org has a monitoring system that polls 
> every server in its database to verify that it's reachable.

Perhaps you mean pool.ntp.org. It's in the ntp.org namespace but it's a 
separate project run by Ask Bjørn Hansen.
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: NTP community feels broken

[Paul G]

On Friday, June 17, 2022 at 11:24:31 AM UTC-4, chris wrote:
> It's the code that polls ntp servers to verify that they are up.

Where is it in this tarball: 
http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.8p15.tar.gz

If it's not there then you're probably in the wrong list/group.
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: NTP community feels broken

[Paul G]

On Friday, June 17, 2022 at 9:37:15 AM UTC-4, chris wrote:
> The problem is the monitoring software

What software product/program do you mean?
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

Re: [ntp:questions] More than one PPS source on Raspberry Pi?

[Paul J R]

The answer is no and yes (and also maybe)..

no because the current pps-gpio driver only loads a single pin (though 
it could be extended to load more than one, but i dont think anyones 
done that).


yes because the other way it could be achieved is to create a second 
module called pps-gpio2 and then init that with a different pin config, 
and that wouldn't be overly hard and possibly easier than trying to 
extend the existing driver (depending on knowledge of kernel drivers).


Lastly, maybe because im unaware of what hardware limits the rpi might 
have which might get in the way of doing something like that (from what 
i've read, every pin is capable of being configured for interrupts, so 
it sounds like it should be possible)


On 05/12/17 03:35, Frank Wayne wrote:

Has anyone tried to use more than one PPS source at the same time on a 
Raspberry Pi? The device tree overlay pps-gpio does not seem to support more 
than one instance. That is, if my config.txt specifies two instances of 
pps-gpio for different GPIO pins, only /dev/pps0 is created.

The documentation for pps_gpio is limited or missing, and the Raspberry Pi 
forum and the LinuxPPS list have not helped.

If pps-gpio cannot do it, is there another way to get PPS devices for Raspbian 
or another OS that will run on a Pi?

Frank Wayne
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions




___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Looking for a NTP stratum 2 appliance

[Paul]

On Mon, May 29, 2017 at 4:24 AM, François Meyer 
wrote:

> the problem is with GPS Time, that is not UTC(USNO) and not traceable


This is not correct (per USNO).  "GPS Time" is traceable (in NIST usage)
to UTC(USNO) and hence UTC.  The GPS message carries the current offset and
USNO produces retrospective reports.  It's worth noting that that "GPS
Time" may not be legally traceable to UTC outside of the US since the USNO
is not an internationally "recognized" national metrology institute.  That
would depend on case law.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Looking for a NTP stratum 2 appliance

[Paul]

On Fri, May 26, 2017 at 10:33 PM, Harlan Stenn  wrote:

> NIST doesn't control GPS.  That's done by USNO and the USAF.
>

This is true(ish)* but irrelevant.  NIST defines traceability to NIST and
GPS can be a component of UTC(NIST) traceability.

More importantly the premise of this issue is incorrect (if it has been
properly presented).  If I have an S2 clock peering both with a GPS
disciplined S1 clock and a NIST clock via NTP then "apparent" errors
("drift") are measurements of network instability not variance from
UTC(NIST).  E.g. this line:

 time-d.nist.gov .NIST.   1 u   35  5127   48.0371.714
2.137

does not mean this clock has a 1.7ms offset and 2.1ms of jitter with
respect to UTC(NIST).

Since NIST specs the NTP error O(50ms) due to network issues it's
insufficient for the stated need in any case.

*NIST publishes the delta and the two groups work to maintain constrained
offset between UTC(NIST) and UTC(USNO) so they can be considered equivalent
instances of UTC in the US.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Looking for a NTP stratum 2 appliance

[Paul]

I also assumed that despite what you wrote you were using your (too few) S1
devices.  I would agree that you probably should not poll NIST at small
intervals for various reasons.  However I suspect that there's a deeper
misunderstanding.  Per NIST the US Federal GNSS system (known as the Global
Positioning System or GPS) can be part of system* that is considered to
produce measurements traceable to the NIST national standards.  Using NIST
servers via the public Internet likely *cannot* produce measurements that
are traceable to NIST (in a meaningful way).

*"GPS disciplined oscillators can be used to establish traceability to the
national time and frequency standards maintained by NIST"  [
https://www.nist.gov/pml/time-and-frequency-division/services/gps-data-archive].
Note that NTP fed by a GPS PPS produces a GPS disciplined oscillator.

On Fri, May 26, 2017 at 10:31 AM, Matthew Huff  wrote:

> We do sync our systems to our stratum 1 servers. The issue is that the
> regulations require us to verify that we aren't 50 msec away from NIST
> time, not GPS time. By running our stratum 2 servers with a preference to
> nist servers and also other ntp servers, our client machines can connect to
> our stratum 1 and 2 servers and we can monitor the diff between the local
> client time and NIST
>
> > On May 26, 2017, at 9:49 AM, Miroslav Lichvar 
> wrote:
> >
> >> On Fri, May 26, 2017 at 12:11:30PM +, Matthew Huff wrote:
> >> Thanks. I agree that the appliance doesn’t appear to exist. It’s a
> shame that it doesn’t, I think it would be a good idea.
> >>
> >> The 50 msec isn’t that hard to reach on an average basis, but we
> routinely see drifts away from that on occasions. The minpoll idea would
> probably fix this, but was hesitant to poll that frequently. I just found
> NIST’s NTP page and they specify to not poll more frequently that every 4
> seconds (minpoll 2). I wouldn’t have thought that they would want polling
> with minpoll 3, but it appears I was wrong. This may fix the issue by
> itself.
> >
> > Using such a short polling interval over Internet would be a horrible
> > idea. NIST servers are overloaded and located in a network that has
> > problems with asymmetric routing. It's better to avoid them if
> > accuracy is a requirement. I thought you were using those stratum-1
> > servers you have and the requirement for accuracy was 10 or 100
> > microseconds, not milliseconds.
> >
> > Anything should do better than 50 milliseconds as long as it's on
> > local network.
> >
> > --
> > Miroslav Lichvar
>
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Looking for a NTP stratum 2 appliance

[Paul]

"The Securities and Exchange Commission (SEC) approved a new clock
synchronization standard of 50 milliseconds applicable to computer clocks
that are used to record certain events in NMS securities or OTC equity
securities. Firms have six months from the effective date, until February
20, 2017, to apply the new 50 millisecond standard to impacted system
clocks that capture time in milliseconds. Firms have eighteen months from
the effective date, until February 19, 2018, to apply the new standard to
impacted system clocks that do not capture time in milliseconds. [
http://www.finra.org/industry/notices/16-23];

Perhaps you are referring to something other than the above requirement.
In any case 50 or 5 milliseconds is easily achieved on any random computer
unless there are uncontrolled external events.  You should control those
events.  A common problem is setting minpoll to some value other than 3.
Another is a misconfigured NIC or a speed mismatch.

Our nearly unmaintained S2 Linux servers manage  less than 100 microseconds
of jitter and 500 microseconds of offset compared to the S1 servers.

I'd be surprised if an appliance as spec'ed exists.

On Fri, May 26, 2017 at 6:25 AM, Matthew Huff  wrote:

> The issues is that sometimes our stratum 2 servers drift away from NIST
> time (our stratum 2 servers are synced to NIST stratum 1 servers) by > 5
> msec, violating FINRA regulations (it's a silly requirement).
>
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP under AIX?

[Paul]

On Thu, May 18, 2017 at 3:06 PM, Brian Inglis <
brian.ing...@systematicsw.ab.ca> wrote:

> A lot of these types of boxes appear to be some type of SoC board with
> some GPS module, some Linux distro, some NTP release, probably GPSd,
> and with little in the way of docs, specs (typical: <1us!), guarantees,
> or likely support and maintenance. They often feature pictures of fancy
>


I assume here you are referring to classic NTP appliances from folks like
Spectracom, MicroSemi or EndRun (if they still exist).  I would expect the
LeoNTP to be more like Tharp's Laureline (V2) (
https://partiallystapled.com/pages/laureline-gps-ntp-server.html) and not
actually run anything one would recognize as NTP -- except for network
packets.  I think of these things as being network attached GNSS modules
that use NTP compatible packets for time transfer.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP under AIX?

[Paul]

On Thu, May 18, 2017 at 2:20 PM, Brian Inglis <
brian.ing...@systematicsw.ab.ca> wrote:

> JLT Fury is overkill if you don't need better than Rb performance
> and stability.
>


Ooops. I typed JF rather than JL (Jackson Labs).  I picked the Fury over
the other JL products because it comes in a desktop version with
appropriate connectors esp. the DE9 with EIA levels.  Likewise all the
boxes I mentioned are plug and play.  Also I was responding to the idea of
multiple copies of the same "ntp compatible" appliance rather than
something that would meet vague needs.

However with a DO Fury you can sync it outside once a year (or some
suitable interval) and bring it in to a GPS-free zone (~36ms/year drift).
The Fury is still spec'd with Moto compatible part.  Hopefully that's not
just u-Blox behind a microcontroller.

BTW, the Fury is the only device I've used that produces NMEA sentences
with sub millisecond jitter.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] dynamic stratum changes

[Szuch, Paul]

Hi, I'm setting up ntp on an isolated net.
Some of our linux machines run a custom time protocol that synchronizes the 
kernel to GPS time to sub millisecond accuracy.
I've got my ntpd.conf using the local oscillator (127.127.1.1) clock at stratum 
1.

I'm looking to see what I should do when my custom time protocol has an error 
and can't synchronize time anymore.
I would like to degrade my stratum so that other machines will choose a better 
source of time, depending on how bad my custom protocol fails.
I'd rather not kill and restart ntpd, as that just puts load on the machine for 
no good reason, and seems very inelegant.
I looked into ntpdc "fudge" command, but it doesn't support the stratum option.
Is there some elegant way of making the local ntpd change its reported stratum?

Do I have to customize the local oscillator driver to input the health status?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Testing IPv6 code

[Paul]

The proximate cause is using the wrong name for the pool.
2.pool.ntp.org will return IPv6.  Use one of those.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] What happened to the software of which ntimed-client was a part?

[Paul]

The schedule seems to have slipped.  The last update with a date was maybe
two years ago with some speculation that the master could be done a year
ago.

Did the Linux Foundation lose interest?

Given the alternative I was hoping for a bit more code.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] 4.2.8p9 build issue on ARM running Ubuntu 14.04

[Paul]

[conflicting types for 'EVP_MD_CTX']

I've been able to build every version for some time but I can't build
4.2.8.p9/ARM/Ubuntu 14.04 because of the changes to a_md5encrypt.  I don't
cross-compile.

Before I start trying to figure this out I thought I'd ask if there's
something obvious I've missed.

Thanks.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Help: fudge time2 value for NMEA driver

[Paul]

On Thu, Nov 3, 2016 at 11:59 PM, Brian Inglis <
brian.ing...@systematicsw.ab.ca> wrote:

>
> The JLT Fury emulates the HP/Symmetricom/Agilent/Keysight 58503 which is a
> newer variant of the venerable HP38xx GPS-DOs,
>

Sure but this is tne NTP list and if you have a Fury you should use NMEA.
The driver is robust and it works with any minimally capable NMEA-like
input.  This is important because many (most) of the standard drivers are
old, cranky and unmaintained.  (E.g. the TSIP driver doesn't work on new
products, not only that but there's a subtle bug with older products like
the Thunderbolt).


> Single message output may be required for NMEA PPS handling to work, and
> why it
> did not work with your Fury or uBlox.
>

That's a reason to use ATOM+NMEA not a reason to fiddle the NMEA output.


> IRC early Fury models
>

We're drifting here but I didn't see any significant difference in jitter
after upgrading the GPS module in my Fury.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Help: fudge time2 value for NMEA driver

[Paul]

On Thu, Nov 3, 2016 at 2:27 PM, Brian Inglis <
brian.ing...@systematicsw.ab.ca> wrote:

>
> What do your refclock ntp.conf lines look like?
>

I'm not sure why you're asking but:
# PPS (ATOM)
server 127.127.22.0 minpoll 3
fudge 127.127.22.0 refid GPPS

# NMEA  @19200
server 127.127.20.0 minpoll 3 mode 65570 prefer
fudge 127.127.20.0 time2 0.039 refid FURY


> Also please see driver comments in [time-nuts] NTP refclock JLT Fury:
>

Using the NMEA (like) output is sufficient to number the seconds  -- using
an HP SCPI driver is an odd choice for non-HP gear.


> For decent results you also have to switch off output of other messages.
>

That's not my ublox experience although I did arrange that all the output
per tick happened in less than a second.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Help: fudge time2 value for NMEA driver

[Paul]

On Sun, Oct 30, 2016 at 1:29 PM, ogre up  wrote:

> Hello everyone, I've setup a NMEA+PPS ntp server, but both ref clock have
> strange offset value reported by ntpq -p.
>

Your billboard is fine.  If you want less jitter in your NMEA sentences you
need to buy better hardware.  Not necessarily more expensive but better.
However it doesn't matter as long as you stay within a few hundred
milliseconds of the correct second since the timing is done with PPS and
the GPS output is only used to number the seconds.  Unfortunately I have no
experience with your PPS problem.

I prefer using ATOM (PPS) + a GPS specific driver.  In the past I've been
unhappy using the PPS option in the NMEA driver so I don't bother.

Output from a low jitter NMEA compatible GPSDO:
 remote   refid  st t when poll reach   delay   offset
jitter
==
o127.127.22.0.GPPS.   0 l28  3770.0000.000
0.002
*127.127.20.0.FURY.   0 l18  3770.000   -0.003
0.011
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Best NMEA sentence

[Paul]

On Sun, Feb 21, 2016 at 9:43 PM, Brian Inglis <
brian.ing...@systematicsw.ab.ca> wrote:

> To amplify: would you suggest that the spec in that case should be FreeBSD
> on a
> Soekris or similar with an HP primary or secondary reference clock or
> similar?


I can't imagine any circumstance where I would make that recommendation.

If you mean what would I suggest for accurate high-resolution local
time-stamps I'd probably suggest going with Meinberg PTP gear (cards and
clocks).  There are modern equivalents of the venerable Soekris (e.g. the
Beaglebone products have real-time high resolution capture co-processors)
but I'm not sure how useful the typical Arm SOC  is for time-critical
production work (e.g. stock trading).

Don't forget the Soekris "most accurate NTP server" had hardware and
software mods (external hardware clock and custom NTP) and was built "just
because".  The stock stuff is nothing to write home about.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Best NMEA sentence

[Paul]

On Sat, Feb 20, 2016 at 6:58 AM, Neil Green  wrote:

> Is there a generally accepted NMEA “best sentence” for use with ntp? For
> example, I’ve seen GPRMC ...
>

RMC is the best.  Athough it abbreviates the year to two digits it provides
a complete timestamp plus fix validity and of course unlike the others is
ubiquitous.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Fw: NTP and Trimble TSIP

[Paul]

On Tue, Feb 16, 2016 at 7:40 PM, Brian Inglis <
brian.ing...@systematicsw.ab.ca> wrote:

>
> This module specs don't mention frequency output other than 1PPS which is
> specced within 60ns, so much better than almost all. If it also supports
> TRAIM and sawtooth correction, the driver can improve on that.


See http://www.trimble.com/timing/ICM-SMT-360.aspx.

This is  $50 quant. 1 Resolution SMT with a $2 TCXO (the 10MHz is presented
on pin 23).

It's GPSDO but it's not a T-bolt E.  24 hour hold-over 100x10^-9 vs
1x10^-12 .
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Fw: NTP and Trimble TSIP

[Paul]

On Tue, Feb 16, 2016 at 7:48 AM, Neil Green <nc...@hotmail.co.uk> wrote:

> Hi, yes, timepps.h is in my source tree. I can make the Copernicus II
> output NMEA all day long but I'm considering buying one of these:


You should use driver 29 (GPS_PALISADE) except two years on and there's
been no interest in supporting newer Trimble devices (Resolution etc.).  I
can send you a patch (which also fixes the smal bug in the Thunderbolt
code) that I'd expect to work with the ICM if you like.

Note that the consensus is that 10Mhz from from a GPS module is pretty bad.

--
Paul
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] custom NMEA messages

[Paul]

On Mon, Jan 4, 2016 at 3:58 AM, Hal Murray  wrote:

> > On Tue, Dec 29, 2015 at 4:08 PM, Brian Inglis <
> brian.ing...@systematicsw.ab.ca> wrote:
> > If you are looking at NMEA message timing - that's all over the board on
> > every device
>
> No, some devices do it right.  Look at my graph (way above).  You can do a
> whole lot better than most devices do.
>

If you're referring to your 18 vs 18x chart then I would disagree.  The 18
numbers are typical of my experience with various NMEA serial devices.
I've found one exception -- the JL Fury.  These are typical values:

o127.127.22.0.GPPS.   0 l58  3770.0000.001
0.002
*127.127.20.0.FURY.   0 l48  3770.000   -0.042
0.023

The JL Firefly II is about an order of magnitude worse than the Fury so
it's not simply that they're GPSDOs from JL.  Still better than your
typical serial device but nothing to write home about.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Atheros AR9331 w/GPS + PPS

[Paul J R]

On 8/09/2015 5:44 pm, Gabs Ricalde wrote:

On Tue, Sep 1, 2015 at 3:22 AM, Paul J R <m...@pjr.cc> wrote:

Hi All,

Thought I might share my experiences. Got given a little AR9331 based router
some months ago (gl.inet 6416a) and spun up pps on one of its gpio lines.
Its been running for about 2 months and so far the performance of it has
been quite impressive from a client perspective. Havent seen many references
to anyone using an Atheros chipset for pps and ntp so far but im curious if
anyone else has had any experiences?

Regards, Paul


I've been running two devices (TPLink WR703N, MR3020) for more than 2
years with almost no issue. Also impressed on what these devices could
do. Does the new OpenWRT versions have the PPS driver for AR9331? I had
to use this for Attitude Adjustment:
https://code.google.com/p/openwrt-stratum1/

The GL.iNet looks like it's made for hacking, wish it's sold locally.

Yeah, i did stumble onto the code on the google, but i ended up writing 
a new driver myself as that one was polling based.


There was a patch 
(https://github.com/GBert/openwrt-misc/tree/master/gpio-test/src) which 
adds interrupt based gpio support, so i wrote a patch to add pps-gpio on 
top of that 
(https://dl.dropboxusercontent.com/u/49959760/970-pps-gpio-ar9331.patch). Its 
an openwrt patch specifically for the gl.inet board, but the code is 
pretty straight forward (though a bit messy) and should work on any 
ar9331 based box. It'll work on 14.07 and above (though i've only tested 
compiling it against 14.07 and the current trunk code)


I've also tested it with a som9331 openembed board and it seems to work 
quite well on that as well.


Not sure what locally would be for you, but if your in the US, there is 
a 1-day shipping option (i believe) for that particular box on amazon.


To give an idea on size though (which is perhaps what impressed me 
most), here it is next to an RPI2 
https://dl.dropboxusercontent.com/u/49959760/IMG_20150904_014715_w.jpg 
and im very tempted to make a little waterproof box for it, a poe 
splitter and stick it to the roof somewhere as the components i've 
looked at in it all have fairly extreme environment ratings.


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] Atheros AR9331 w/GPS + PPS

[Paul J R]

Hi All,

Thought I might share my experiences. Got given a little AR9331 based 
router some months ago (gl.inet 6416a) and spun up pps on one of its 
gpio lines. Its been running for about 2 months and so far the 
performance of it has been quite impressive from a client perspective. 
Havent seen many references to anyone using an Atheros chipset for pps 
and ntp so far but im curious if anyone else has had any experiences?


Regards, Paul

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] failing-over flaky upstream servers

[Paul]

On Thu, Mar 12, 2015 at 8:36 AM, Paul paul-ntp-questi...@lookmumnohands.net
 wrote:

 I would like my ntpd to continue serving time, gracefully choosing
 from the best available upstream servers.
 ...



   3. PPS signal derived from GPS.  Excellent accuracy, but only
  available say 90% of the day due to satellite visibility.


You should get a better (timing) receiver.  I have an 18x-LVC in the
window of my interior office in a rehab'ed machine room (they did cut out
some exterior windows) and I get a valid signal 97% of the time.
Admittedly it's probably all multipath but it manages sub-millisecond
offsets from more reliable clocks.

How do I best configure ntpd to get the best available time under
 changing circumstances?  I also like to be able to unplug the
 Internet without ntpd getting upset.  If I recall correctly, in order
 for PPS to function it needs a prefer peer, and I am unsure what the
 best selection is.


Versions  prior to 4.2.8 allowed you to use PPS + LOCAL.  This is a
sensible configuration because after you've initialized the seconds with
a correct source you do have a discliplined system clock -- at least
until the power fails.  Similar results can be achieved with a pps kernel
but I suspect the intent there is to have a primary(ish) standard, where a
GPSDO is ish compared to your Cesium standard, rather than a simple
receiver.  A new GPSDO can be had for much less than a Cesium (Cs) or
Rubidium (Rb) standard if you do want to go that way.  Even less from Ebay
although older units like RFTGs and Z38NNs have old receivers that need
better antenna siting.

Another approach is the NIST/USNO ACTS_MODEM driver which I've yet to get
working reliably but that's a personal problem.

In each case you probably want to use orphan mode.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] failing-over flaky upstream servers

[Paul]

I would like my ntpd to continue serving time, gracefully choosing
from the best available upstream servers.  (I'll state here at the
outset that I'm not serving time outside my local network.)

I have the following time sources available:

  1. NTP servers on the Internet.  Internet is mostly available.
 Individual upstream servers may occasionally disappear
 temporarily or permanently.

  2. NMEA sentences (via gpsd).  Excellent availability but terrible
 accuracy (due to the non-deterministic nature of sentence
 length and non-guaranteed trigger point from second epoch).

  3. PPS signal derived from GPS.  Excellent accuracy, but only
 available say 90% of the day due to satellite visibility.

How do I best configure ntpd to get the best available time under
changing circumstances?  I also like to be able to unplug the
Internet without ntpd getting upset.  If I recall correctly, in order
for PPS to function it needs a prefer peer, and I am unsure what the
best selection is.

In theory; once ntpd is running; given my available time sources and
provided the clock doesn't drift more than 500ms, it should be able to
keep excellent time based on the local clock and PPS.  The question
then becomes how best to configure ntpd to reflect this.

This is my current ntp.conf (at least a redacted extract thereof):

server internet0 iburst
server internet1 iburst prefer
server internet2 iburst
server internet3 iburst
server internet4 iburst

# pps-gpio on /dev/pps0
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 refid PPS
# enable kernel PLL/FLL clock discipline
fudge 127.127.22.0 flag3 1

# Undisciplined Local Clock
server 127.127.1.0

# SHM driver accessing NMEA via GPSD
server 127.127.28.0
fudge 127.127.28.0 refid NMEA
# mean avg offset when 377 reached
fudge 127.127.28.0 time1 0.183106

Here is the current 'ntpq -p' results.  As you will note, my prefer
peer died some time ago, and now the PPS is being ignored.

remote  refid st t when poll reach   delay   offset  jitter
===
-internet0   upstream  3 u   58   64  377   16.560   -6.112   1.680
 internet1   upstream 16 u  74d 102400.0000.000   0.000
-internet2   upstream  4 u   36   64  377   25.559   -8.380   5.171
+internet3   upstream  2 u   14   64  377   25.963   -4.732   1.422
+internet4   upstream  3 u   56   64  377   13.535   -5.390   2.924
xPPS(0)  .PPS. 0 l7   16  3770.000   -2.482   0.040
 LOCAL(0).LOCL.5 l  94d   6400.0000.000   0.000
*SHM(0)  .NMEA.0 l   46   64  3770.000   -0.544   1.633

Any thoughts?  How would you go about configuring ntpd for these
clocks?

--
Paul.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] failing-over flaky upstream servers

[Paul]

 Drop local driver as that is intended for systems with an external
 clock source providing an accurate disciplined system clock.

That doesn't quite make sense to me.  (To be sure we are talking about
the same thing, I assume you are referring to my server
127.127.1.0.)  My use case appears to align with the documented [1]
examples.  I /do/ want it to be the designated time server to act as
a primary server to provide synchronization to other clients on the
network [paragraph one], and the clock of last resort when all other
normal synchronization sources have gone away [paragraph two] and
when an external discipline source [like a modem] is available
[paragraph three].  Well, not a modem, but an external NTP source is
available at least a couple of times a day!  Of course, perhaps I'm
not understanding correctly, so do please tell me again if you think
including the local clock is bad.


 Set up your NMEA clock as prefer peer, and change fudge time to
 centre offset to PPS around zero.

OK - that sounds sensible.  The fudge time in my ntp.conf (fudge
127.127.28.0 time1 0.183106) was indeed set in that way.  From memory,
I configured ntpd to watch the NMEA but not to synchronise, waited for
everything to settle and collected offset readings over a day or so.
The fudge factor is a result of averaging out those samples.  At the
time, I was pretty happy with the result and I'm not sure I could do
better with that driver (driver28).


 If your ref clock generates NMEA sentences, try using the NMEA
 driver, which tries to compensate for sentence timing, instead of
 gpsd SHM.

Ah, ntpd - it's like a game of whack-a-mole - fix one issue, create
another in doing so.  I'm using gpsd because I want to use the NMEA
sentences in other places (hence the use of gpsd).  Now of course, I
could duplicate the serial port - as in create a virtual serial port
so that both gpsd and the NMEA driver could get the same serial data.
That, however, is another thing to break and add timing errors.

I also recall some issues where I tried using the NMEA driver
(driver20) but it ended up snarfing the PPS signal.  Or refusing to
play nicely with driver22.  Or something like that.  I've always found
ntpd to be a little on the touchy side.  Unfortunately I can't
remember the exact details on why I ended up with my current setup.


 If PPS still does not work reliably, remove the PPS driver and see
 if the NMEA driver will run with user mode PPS provided by the
 driver.

The PPS /was/ working very reliably... until my prefer peer
disappeared.  The ntpq output probably isn't at all representative of
everything working... but it is rather illustrative of why I'm
hoping to improve my configuration.

On the balance, I think I'd prefer to keep the NMEA and the PPS as
separate time sources - if only so I can monitor them separately.


 Let each configuration run for at least six hours and watch
 ntpq -p -c rv -c cv for precision = -20, stabilizing frequency and
 offset, loopstats drift and offset, and ref clock peerstats offset.

OK, I can do that.


Thanks for your detailed input.  Let me know what you think about the
local clock, if you significantly disagree with my fudge factor on
driver28 and if you think the NMEA driver (20) is significantly better
than the SHM driver (28) for my particular case.


[1] http://doc.ntp.org/4.1.1/driver1.htm

--
Paul.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] failing-over flaky upstream servers

[Paul]

On Thu, Mar 12, 2015 at 2:12 PM, Paul paul-ntp-questi...@lookmumnohands.net
 wrote:

  As you'd well
 know, the PPS signal stops when the unit is tracking less than three
 satellites.


That's the win for a timing receiver.  It will have single satellite mode.


  (The whole prior to
 4.2.8 thing is a bit of a worry.  On the face of it, it sounds like a
 regression, though no doubt there was a good reason for the change.
 Trouble is I'll now need to remember never to upgrade /for that
 particular reason/.)


 Your OP mentioned gpio which suggests to me some pain but if you're
running an OS that supports it building a PPS enabled kernel means you
don't need a prefer server.  But it also means you need to have a stable
pps source which means a GPSDO if you have a poor sky view.

Well, yes.  Maybe next time around!


Don't give up yet.  Get single-unit pricing on one of these first. 
http://www.jackson-labs.com/index.php/products/lte_lite .  You'll have to
do a bit of work but nothing too onerous if you're driving a gpio at 3V3.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] failing-over flaky upstream servers

[Paul]

3. PPS signal derived from GPS.  Excellent accuracy, but only
   available say 90% of the day due to satellite visibility.
 
 You should get a better (timing) receiver.  I have an 18x-LVC in the
 window of my interior office in a rehab'ed machine room (they did
 cut out some exterior windows) and I get a valid signal 97% of the
 time.  Admittedly it's probably all multipath but it manages
 sub-millisecond offsets from more reliable clocks.

Yes, I probably should  :-)

This; too; is a Garmin GPS18-LVC.  As for my bold claims of 90%
availability... turns out I was rather overstating it.  78% is more
like it.  It's sitting next to an external window.  As you'd well
know, the PPS signal stops when the unit is tracking less than three
satellites.  At least the NMEA sentences keep coming.


  If I recall correctly, in order for PPS to function it needs a
  prefer peer, and I am unsure what the best selection is.
 
 Versions  prior to 4.2.8 allowed you to use PPS + LOCAL.

Now that sounds quite sensible.  I'm using a custom compiled 4.2.6
here at the moment, so looks like I'm in luck.  (The whole prior to
4.2.8 thing is a bit of a worry.  On the face of it, it sounds like a
regression, though no doubt there was a good reason for the change.
Trouble is I'll now need to remember never to upgrade /for that
particular reason/.)


 A new GPSDO can be had for much less than a Cesium (Cs) or Rubidium
 (Rb) standard if you do want to go that way.

Well, yes.  Maybe next time around!


 In each case you probably want to use orphan mode.

Was not aware of that.  I will need to do some reading.


--
Paul.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Could some one help in pointing out the error here

[Paul]

On Mon, Mar 2, 2015 at 4:37 AM, catherine.wei1...@gmail.com wrote:

 I need to use the following commands in my system:
 :config server 
 :config restrict ...
 :config unconfig ...


Refer to http://www.eecis.udel.edu/~mills/ntp/html/confopt.html

It's :config unpeer not :config unconfig.  Also note that peer has more
than one meaning.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Tue, Feb 24, 2015 at 1:14 PM, Charles Swiger cswi...@mac.com wrote:

 On Feb 23, 2015, at 11:57 PM, David Woolley david@ex.djwhome.demon.invalid
 wrote:
  On 23/02/15 21:23, William Unruh wrote:
  manual corrections are probably good to 1 sec.
 
  It's a long time since I did this, but 200ms is more like it

 However, if you time things with a rhythm you can get to ~50 ms or better


While these performance anecdotes are interesting they (starting with
unruh@invalid) are all anecdotes.  I didn't mention research and real
numbers by accident.

The underlying assertion is that the chrony method offers some value and is
superior to NTPd.  So I'd like something more than hand-waving regarding
the performance and if it's better than just setting the clock once and a
while I'll write something to create a drift file based on the operator
listening to USNO ticks (or Emerald Time if you have it) and pressing
return at the right time.

Someone else can do a version that uses a microphone to listen to the ticks
-- a stone-age ACTS driver.

With regard to return on investment and underlying arguments about
advantages.  I don't buy the Well someone may want to do this so it's
worthwhile argument.  Doing something foolish or stupid doesn't make
Chrony better than NTPd.

Or to put it another way -- NTPd is about precise time transfer and it
protects you from falsetickers like your wristwatch.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Tue, Feb 24, 2015 at 4:17 PM, William Unruh un...@invalid.ca wrote:

 It is superior in that you can do it easily. Whether that is of any
 importance to you is of course up to you. Myself I have never used it.


As is often the case you completely miss the point.


 Fine. It has already been written for chrony. For those that want it,
 this is an advantage for chrony. I could argue that ntpd is
 no better than nothing because I could write a program to do what ntpd
 does. While (possibly) true, it is a silly argument.


If there's an real use case for the feature then writing a few lines of
some scripting language to implement an equivalent solution for NTPd is not
a significant effort.

If such an add-on was available for NTPd would you stop or would you
continue asserting that Chrony has some unproven advantage.  And until
someone shows the level of correction you can expect then it remains
unproven speculation.



 (assuming the presense does not mess other things up).


Yeah there's always that.


 Your wristwatch may well be a much better ticker than the localclock


Well mine isn't but that wasn't the point.  Come back when you have real
measurements of an end-to-end system.  I don't care about the time source.
You assert that there's an advantage to disciplining a clock by hand versus
free-running.  So come back in a year and tell me how it went.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Tue, Feb 24, 2015 at 3:22 PM, Charles Swiger cswi...@mac.com wrote:


 Data is available.  Feel free to review the papers referenced from:


I was unclear.  I mean specific research regarding disciplining a clock via
manual correction not human coordination or fine motor control.

As I said, an unbiased assessment of long term corrections using manual
correction.  Not well theory says speculation either on the part of
chrony and/or human performance.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Mon, Feb 23, 2015 at 12:53 PM, William Unruh un...@invalid.ca wrote:

 As Lichvar says with chrony
 you periodically read your watch, or listen to radio, and set the time
 and chrony figures out that you have a drift rate of about 30PPM and
 corrects. Now you may not value that possibility, which is perfectly all
 right, but some people might.


Seems like someone should do some unbiased research and determine just how
long it takes to find  clock drift, say to 2 ppm, using chrony with manual
corrections.  Finding a nice (efficient) method would be useful too.

With NTPd I might set the clock, wait a month check the time and create a
drift file.

Sometimes you have to examine a use case and conclude that it's poor return
on investment.  I think trying to discpline an uncharaterized oscillator
with a wristwatch is certainly marginal.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Sat, Feb 21, 2015 at 1:57 AM, William Unruh un...@invalid.ca wrote:

 On 2015-02-21, Paul tik-...@bodosom.net wrote:
  On Fri, Feb 20, 2015 at 3:23 PM, William Unruh un...@invalid.ca wrote:
 
  ??? how do assume that the chrony docs do not tell the truth?
  ^ you


Okay, I'll assume (or pretend) that you mean Why do I assume the Chrony
documentation is in error and the answer is believing you.  This is why I
suggest you stop paraphrasing and stop asking for paraphrasing.  Provide
references to sources and stop doing original research.

You said: Lichvar did some tests with PPS and found that chrony
disciplined the clock much better than did ntpd (factors of over 10) and
since NTPd can get to sub-microsecond your statement means Chrony is
getting at least O(10) nanoseconds.

The Chrony document says: With a good reference clock the accuracy can
reach one microsecond.

So one of you is wrong.  Except it turns out you're both wrong.  Miroslav
Lichvar says If the clock is stable enough, they can perform similarly.
so the Chrony doc understates the performance and you overstate it
considering the current/recent state of the art.

And now some original research:  I switched my most challenging *client*
(stratum 2 on a powerline network) from NTPd to Ntimed-client to Chrony.
NTPd had excursions in O(10) to O(100) microseconds, Ntimed-client managed
O(1) to O(10) microseconds and Chrony managed a reasonably consistent 1
millisecond offset.  I used stock conf files except Ntimed-client doesn't
use one.  So points to Chrony for being more consistent.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Pool server gone wild

[Paul]

On Fri, Feb 20, 2015 at 6:21 PM, Harlan Stenn st...@ntp.org wrote:

 This is interesting.  It may be that only 4 responses are returned at a
 time, but there has been lots of evidence and experience that depending
 on your resolver (most resolvers, from what I've seen), you won't get
 the same responses each time (this point assumes there are more than 4
 answers to be had).


I suspect the limit of four is enforced by the pool DNS servers and tweaked
by a short TTL.

Two points:
1) sometimes  2.*.pool is magic.  One would want to account for that.
2) sometimes a cache will return the same answer for n.*.pool if n is a
constant for longer than you might expect despite the TTL.

Something like 0.uk.pool, 1.uk.pool, 3.uk.pool and uk.pool will should
return 16 unique IPv4 addresses in the UK.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Fri, Feb 20, 2015 at 3:23 PM, William Unruh un...@invalid.ca wrote:

 ??? how do assume that the chrony docs do not tell the truth?


I don't understand that sentence.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Thu, Feb 19, 2015 at 9:42 AM, Rob nom...@example.com wrote:


 Ok but of course we are using PPS and a 16 second polling interval.


Use eight unless your system is broken in which replace it and then use
eight.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Thu, Feb 19, 2015 at 6:16 PM, Harlan Stenn st...@ntp.org wrote:

 While that document is old and unmaintained


So put an appropriate note at the top of it and on the link to it from the
WebHome page.  No one that stumbles onto it is going to find any gems.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Thu, Feb 19, 2015 at 5:34 AM, David Taylor 
david-tay...@blueyonder.co.uk.invalid wrote:

 Does not NTP's orphan mode and local clock driver provide this?


Refclock 1 (LOCAL/LOCL) is deprecated and I believe as of a recent release
it's useless* but Orphan mode is intended to replace the local clock
driver. It provides a single simulated UTC source   Note that I
provided a link not any commentary on the correctness of the claims at that
link.  It would be nice if the Chrony docs told the truth but likewise the
NTP docs.

*Previously LOCL+PPS was a useful configuration, now you need (or should)
use kernel PPS.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Wed, Feb 18, 2015 at 8:53 PM, William Unruh un...@invalid.ca wrote:

 On 2015-02-19, Paul tik-...@bodosom.net wrote:
  On Wed, Feb 18, 2015 at 6:49 AM, Charles Elliott elliott...@comcast.net
 
  wrote:
 
  If you don't mind me asking, why is chrony superior to NTPD
  for tracking a PPS signal, or even in general
 
 
  Chrony (in general) pros and cons: 
 
 http://chrony.tuxfamily.org/manual.html#Other-time-synchronisation-packages
 

 Just so people reading this know what you are saying


You've really got to let go of the need for third party paraphrase.  *I'm*
not saying anything about Chrony or Ntimed-client.  The authorities on
those programs should be accepted as authorities.  People that want to know
about Chrony can click on the link and read for themselves unfiltered by
you.


  In the specific case of PPS I don't see any advantage.

 Well, no. Lichvar did some tests with PPS and found that chrony
 disciplined the clock much better than did ntpd (factors of over 10). I
 think that is a difference.


Do you have a link to that?  The graphs I saw were all for (simulated?)
clients.  But it's been a while.

A difference is not necessarily an advantage (I said advantage not
difference) but I would have assumed that 
https://github.com/mlichvar/chrony/blob/master/README was correct which
says one microsecond* (I assume offset but it's unclear) but let's go with
10x NTPd.  On my machines NTPd offsets and jitter can be sub-microsecond.
So the target is O(10) nanoseconds?

Note that Ntimed...

 That is a promise not fact. Lets see how it works out. If it uses the same
 design
 as ntpd, it is hard to see how it will fix the deficiencies. But we
 will see.


In fact it's a fact.  Please stop refusing to read the Ntimed notes.  It
just makes you look bad.  Besides if you read the notes you can find the
glaring error and complain about it.


*With a good reference clock the accuracy can reach one microsecond.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Wed, Feb 18, 2015 at 6:49 AM, Charles Elliott elliott...@comcast.net
wrote:

 If you don't mind me asking, why is chrony superior to NTPD
 for tracking a PPS signal, or even in general


Chrony (in general) pros and cons: 
http://chrony.tuxfamily.org/manual.html#Other-time-synchronisation-packages


In the specific case of PPS I don't see any advantage.  Note that Ntimed is
intended to fix nearly all  the deficiencies (of consequence) of ntpd
relative to chrony,
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Mon, Feb 16, 2015 at 5:22 AM, David Taylor 
david-tay...@blueyonder.co.uk.invalid wrote:

 I hope that ntimed will not be available only on Linux


If you have a non-trivial interest I suggest reading the notes.  E.g.

Ntimed-client puts the entire interface to the OS timekeeping in four
trivial functions for portability, but there are other nits and downright
idiotic incompatibilities, because, quite frankly, the UNIX ecosystem is
filled with narrowsighted bigots.

At the timekeeping-level, Windows and OS/X are the odd ones out, and both
of these will need a dedicated set of the four functions. I hope somebody
with skills and access to those platforms will contribute them.

Of course at the end of the day you're going to be a bit disappointed.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Mon, Feb 16, 2015 at 2:57 AM, David Taylor 
david-tay...@blueyonder.co.uk.invalid wrote:

 For me, there are two show-stoppers with Chrony:

 - no support for standard NTP monitoring commands.

 - no support for ref-clocks on Windows.

 Like many others, I have built up a considerable monitoring architecture
 based on using ntpq


Flexibility is good.  Perhaps snmp should be your way forward.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] chrony as a server

[Paul]

On Mon, Feb 16, 2015 at 12:14 PM, David Taylor 
david-tay...@blueyonder.co.uk.invalid wrote:

 I have a non-trivial interest


I meant in Ntimed (the system) not time transfer in general.


 If ntimed is not going to be available for Windows and OS/X that rules it
 out for the great majority of the world's computers.


It's sad that systems that want accurate time are developed on platforms
that have trouble delivering on that need.  However in the case of MacOS X
it's a non-issue.  The NTPd that ships post 10.9 doesn't steer the clock.
That's done by Pacemaker.  So Apple has already gone their own way.  Of
course the bulk of Apple devices (iOS) do use NTP but rather more like
ntpdate.


 The NTP team has made outstanding efforts to encourage cross-platform
 portability such that the same source code can be compiled and run on
 multiple platforms, and the same management interface used even across
 platforms


I expect the same thing of Ntimed but I wouldn't be surprised if the
management interface has little in common with reference NTP ntpq
presentation.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Mon, Feb 16, 2015 at 1:11 AM, William Unruh un...@invalid.ca wrote:

 But that is not what you said. When I asked how ntimed works you
 answered that it disciplines the computer clock.


BZZT!

You said: Be interesting to see how and what it does.
To which I replied: Since I've told you how it does and what it does is
obvious ...

Perhaps when you're puzzled by answers to your questions you should review
your questions.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Sat, Feb 14, 2015 at 11:21 PM, William Unruh un...@invalid.ca wrote:

 If you demand that I give
 detailed explanation


You started off down the ntpd versus chrony path again.
  To get the discussion started, lets compare some of the differences
between chrony and ntpd
That's not useful.  You've spent years talking about chrony vs. ntpd.
There's nothing new to be said.


 tell me that timed


You keep saying timed.  Is that part of some plan to deny responsibility in
future?  I'm talking about NTIMED-CLIENT.  I don't know what you mean by
TIMED.


 is different from ntpd, but
 give me no explanation as to how, or how timed differs from ntpd


I've repeated pointed you to Poul-Henning Kamp's notes regarding Ntimed.
Why isn't that sufficient?  Please provide your parameters for adequate
explanation.



  I've downloaded ntimed which compiled ok so will give it a try in
  a few days.

 Be interesting to see how and what it does.


Since I've told you how it does and what it does is obvious (but just in
case -- it disciplines system time by steering it to UTC) you can see why
people might think you're not genuinely interested in a discussion.

  I have given you detailed answers to your question[s]

Not so much as of yet.  But I keep hoping.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] PHK on Ntimed and Chrony

[Paul]

I'm not completely convinced this is relevant to this list but I'm loath to
paraphrase, restate, summarize or condense the Ntimed notes so quoting PHK 
https://news.ycombinator.com/item?id=8781435:

I'm not keen on saying too much about Chrony, I'd rather let people
without a stake in the game provide comparisons.

But obviously: if I had throught it was just the thing, I wouldn't have
started writing Ntimed.

I also don't expect Ntimed to out-compete Chrony, and if it did, I'd have
to start a fourth alternative myself, to keep competition healty.

A very large part of NTPDs problem was that there were no competition,
which meant that everything got crammed into NTPD, come hell or 300KLOC.

We saw this also with GCC, which had become a stagnated arrogant monopoly,
and suddenly LLVM forced them to care about users again.

Having competing projects is good thing, and I hope Chrony sees things that
way too.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Sun, Feb 15, 2015 at 1:18 PM, William Unruh un...@invalid.ca wrote:

 Thank you. I had no idea what the new version was called, and saw
 someone call it timed. Sorry if it confused you.


This means you're not paying attention to details.  It also means you're
not reading PHK's notes.


 I wanted YOUR summary.


I gave you my summary.  You didn't like it.  Fortunately you don't need
anyone else's summary since PHK has thoughtfully prepared a set of them.
From the README file to the slides to the notes and finally the code.


 It I say to someone-- I hear you are trying out the new
 Subaru, I wonder how it works


If you ask me how my new Subaru works I'd say fine.  If you ask me how much
I like it I'd say a lot.  If you wanted a comparison to competitive
models I'd direct you to the Subaru competetive models comparison page.  If
you said No, no I mean I want *your* summary of Eyesight I'd say it's
better than I am and admit that I don't know if there is any public
technical material on their computer vision system and send you a link to
the YouTube video.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Fri, Feb 13, 2015 at 8:48 PM, William Unruh un...@invalid.ca wrote:

 
  I had a properly set up PPS source to do the comparison.

 As did I.


Ooops, I see that the text/plain part of the message was damaged.  I was
quoting you saying:
 I had a properly set up PPS source and my response was we have no way of
knowing that but you've clarified that.  However I believe the minpoll 4
advice predates minpoll 3.  Although much better than the ntp.org docs
(xntp ... really!) the udel documents are not completely consistent.

In any case all of my comments are specific to a PPS refclock, which you
mentioned in the post that prompted my reponse, and nanosecond jitter.
That value is significant only in so far was we can ignore jitter and focus
on wander.

 Poll 4 for PPS, Poll 6-10 for network.


There's an assumption that the Allan intercept for fast local networks is
512s and that the time constant  jitter versus wander trade-off supports
using minpoll 4 but I think the correct choice is three (minpoll 3 maxpoll
3) and my results reflect that.


  Note that since the effective poll interval is 3 higher
  than the nominal poll interval,

and since the convergence time scale is
  larger than one poll interval, this would give a convergence time of
  greater than 2^9 sec, or 500 sec (10 min)


I'm not completely clear on what you mean here but in any case using a time
constant of 256s would be expected to cut any time in half.  It also worth
noting that the bulk of offset error is corrected very quickly with only
the residue taking a significant amount of time.

However you've not responded to my question regarding your deep concerns.
For years you've complained about the ntpd pll and on occasion suggested
chrony.  Now a replacement is being developed.  So why do you continue to
focus on what you consider to be defects in ntpd?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Sat, Feb 14, 2015 at 2:09 PM, William Unruh un...@invalid.ca wrote:

 Because ntpd is what I know.


Except you've admitted you don't know NTPd.


 If you are saying that this is all up in the air again with
 the new replacement, that would be great. But I have seen no evidence
 thereof in discussions here.


And you won't.  This list is called ntp:questions.  If Ntimed was going to
be discussed on an ntp ilst ntp:hackers would make more sense.  But I
suspect Ntimed will be code and fact driven.   And PHK driven.  So read the
material I pointed you to last time, read the code and present useful
comments or code.


 I would have expected people involved to discuss what the new design
 philosophy was, what they saw as the advantages and disadvantages of the
 various approaches, etc. I have not seen those discussion. Either they
 are taking place elsewhere than here, or they are not taking place, and
 the new is simply a repolishing of the old.


See above.



 Regardind the rate of convergence, clearly that will be vastly faster
 with a PPS refclock... But most people use the net, not a local PPS source.


Yes but you said
 This means that if you are using say a PPS source, which gives
microsecond long term offset, it can take many hours to get there
and I was responding to that.  If you refuse to accept that your previous
statements set the context for a discussion then you're just an ANON troll.


 To get the discussion started, lets compare some of the differences
 between chrony and ntpd.


BZT.  NTPd is yesterday's news.  It's core is unlikely to change absent
a security flaw.  Design discussions about it are useless and unhelpful
(but they should still be on more relevant list).  Come back when you're
ready to write about the differences between Chrony and Ntimed with reasons
to select one or the other.  In the meantime be a better advocate of
alternatives to NTPd i.e. get unstuck from the past and port Chrony to
Windows.

Research is needed, and such research should be part
 of any new system. Is it there?


Ntimed has a few constraints -- no research needed:
1) Be safer (simpler) than ntpd.
2) Be smaller than ntpd.
3) Be as good or better than ntpd where better is probably slippery.

It's not clear to me if worrying about dial-up costs is an Ntimed concern
(I doubt it) but if it is for you then use Chrony.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Sat, Feb 14, 2015 at 6:38 PM, William Unruh un...@invalid.ca wrote:


 When timed is actually out I may be interested in testing it again.


Ntimed-client.  Again?  So you've installed the code?  
https://github.com/bsdphk/Ntimed
That seems unlikely.  Read this: http://phk.freebsd.dk/time/20141221.html


 You have not given any indication that the design discussion has moved
 on from ntpd.


Have you read the notes?  If you mean why is Ntimed still using PLL instead
of curve-fitting you should ask PHK or Harlan.  Ask eight times.


  Ntimed has a few constraints -- no research needed:
  1) Be safer (simpler) than ntpd.
  2) Be smaller than ntpd.
  3) Be as good or better than ntpd where better is probably slippery.

 None of those indicate that anything about the design has changed.


They arent' intended to.  You said research is needed I was pointing out
that it isn't needed.  The engineering is understood it's a matter of
deciding on a solution and coding it up.  Get the slides 
http://phk.freebsd.dk/_downloads/FOSDEM_2015.pdf read slides five to nine.


 No idea what is unsafe about ntpd.


Please tell me you're kidding.  Really.  If not then ... well we really
can't even begin to have a discussion until you understand the recent and
current state of NTPd.  Get the slides 
http://phk.freebsd.dk/_downloads/FOSDEM_2015.pdf see slide 39.


 Smaller may be possible, mainly be
 cleaning up the accretion of code.


PHK's coarse count puts ~300,000 lines of code in the tarball.  That's
overstating it a bit since a significant fraction is comments but there are
~60k lines of real code in the ntpd directory.


 And I would like to hear about what
 better means. I have mentioned why I believe chrony is better. What do
 you mean by better?


To repeat myself -- Ntimed-client keeps my difficult (poorly networked or
slow) clients at O(1) microsecond offsets.  That's an order of magnitude
better than ntpd.  That's one definition of better.   However, like beauty,
better is in the eye of the beholder.


 Dialup costs? Where did I ever mention dialup costs?


You didn't.  The designer of Chrony did.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ambient temperature and it's effects on ref-ntpd (was NTP offset doesn't change.

[Paul]

On Sat, Feb 14, 2015 at 9:33 PM, Harlan Stenn st...@ntp.org wrote:

 I have to wonder if it would be an appropriate GSoC project to
 write something that monitors and tracks available temperature sensors
 and correlates temperature (perhaps with the first derivative) with the
 resulting effect on clock frequency.


Not to deny anyone  a stipend but I feel fairly confident this work has
been done.  Of course sans specific code I could simply be engaging in
wishful thinking about Ackermann's clocks.  I'd check the time-nuts archive.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Fri, Feb 13, 2015 at 12:42 AM, William Unruh un...@invalid.ca wrote:

 OK, so we seem to have two different sets of experiments with very
 different results. Note that I did not erase the drift file, or restart
 ntpd after my perturbation.


Okay, I offset my clock by 100ms without restarting ntpd.  It took about
100 seconds to reduce that by two orders of magnitude and about 2,800
seconds to return to O(1) microsecond offset albeit O(10) microseconds of
jitter.   Next I'll try Ntimed-client.  Perhaps you should redo your
experiment in the modern era.  Or quit referring to stale data.

I had a properly set up PPS source to do the comparison.


We have no way of knowing that and the simplest way to get poor recovery is
to use the wrong poll interval with a PPS refclock.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Thu, Feb 12, 2015 at 12:00 PM, William Unruh un...@invalid.ca wrote:

 This means that if you are using say a PPS source, which gives
 microsecond long term offset, it can take many hours to get there


This has been asserted and corrected before -- as in years ago*.  A
properly configured Linux system with a PPS reference will achieve
best-possible short-term performance between 300-1200 seconds**.  This
should be microsecond offset and jitter.  An optimal drift estimate may
take longer.

*It wouldn't suprise me if it was Mills correcting you.
**Depending on initial conditions.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Thu, Feb 12, 2015 at 7:27 PM, William Unruh un...@invalid.ca wrote:

 It was based on measurements I made with ntpd


Are you assuming the numbers I provided are based on theory or were you
looking over my shoulder when I perturbed system time by two milliseconds
and watched it converge to O(10) microseconds in ~180 seconds.


 Note that the how long it takes to converge depends on the error that
 needs correcting.


See note ** in my message.


 Those are based on experiments, not theory.


 And my numbers are also based on empirical evidence not theory.  Do note
my mention of constraints (a properly set-up PPS source because you
mentioned one).
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Thu, Feb 12, 2015 at 7:16 PM, William Unruh un...@invalid.ca wrote:

 Not really. But it should be distrubing that chrony disciplines clocks
 much better ( lower jitter) than does ntpd in normal situations. Why?
 And does that have lessons that ntpd could learn from?


If you don't stop fixating on NTPd you're not going to get anywhere.  In
general you should encourage people to use better solutions rather than
voicing pointless complaints.  Read PHK's posts and slides.  The facts are
there, the code is short and his biases are obvious so you can start
complaining about what is expected/hoped to replace NTPd with little
effort. If Ntimed tanks then you can start whinging about NTPd again .

As I've said before Ntimed(-client) on my difficult machines (old, slow or
poorly connected) instantly* sets the clock and quickly converges to
microsecond level offsets.

*For reasonable values of instantly.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Thu, Feb 12, 2015 at 3:43 AM, William Unruh un...@invalid.ca wrote:

 It is hard to complain about a non-existant product.


As has been previously mentioned ntimed(-client) is in early release.  I've
been running it since late December.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Wed, Feb 11, 2015 at 4:32 PM, Harlan Stenn st...@ntp.org wrote:

 There are times repair is perfectly acceptable, and we do that.

 There are times replace is better, and we do that.


My point is a long drawn-out discussion of changes to the core of ntp seem
less than productive when the announced way forward is Ntimed (despite
mentions of NTP5).  Another way of looking at this is that it's time for
nomail@example and unruh@invalid to start complaining about Ntimed rather
than ntpd.

I certainly expect patches to continue for the NTP v4 branch.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Wed, Feb 11, 2015 at 8:22 AM, brian utterback brian.utterb...@oracle.com
 wrote:

 But no one who does actively engage really understands
 it or knows how to improve it. Unruh has a point, we don't know if there
 isn't a better way built on statistical analysis.


Since it seems the NTF proposal is to replace rather than repair
shouldn't this line of discussion be directed toward the new  software?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] leapseconds.list updates and ntpd

[Paul]

On Tue, Feb 10, 2015 at 12:19 PM, Harlan Stenn st...@ntp.org wrote:

 No.  The code looks for an updated file (daily, I think, more often as
 we get closer to an expiration).


It checks every SECSPERDAY after start.  I didn't notice any adjustments to
the interval (leapf_timer) and the comment says daily.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Shared PPS source/Multiple PPS sources

[Paul]

On Sat, Feb 7, 2015 at 1:15 PM, William Unruh un...@invalid.ca wrote:

 Some receivers allow you to feed in the current location


Stationary (or fixed-position) operation is an expected capability of
timing  receivers.  Likewise antenna delay, sawtooth correction if needed
and loss of lock alarms.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Shared PPS source/Multiple PPS sources

[Paul]

On Fri, Feb 6, 2015 at 3:17 PM, walter.preunin...@gmail.com wrote:

 Ok, so these questions might be off the wall.


Yes.



 Is there any reason why I could not share the PPS output of say, my u-blox
 7 GPS module on multiple computers?


 Of course you can.  However the correct way to do this is with a
distribution amplifier and it would be cheaper to buy another GPS.

Would it be good or bad to peer these 2 systems with each other?


It depends.  What are you trying to do?



 On the opposite end of the spectrum, would it be reasonable to have a PPS
 output from said module on a computer, with a second PPS (from another GPS
 module) on that same computer?


It depends on why you would do it.  Again what are you trying to do?


 The Chronodot/DS323X chips have 1 Hz sqaure wave output and they have +/-
 2ppm. It seems that the ATOM clock driver could be used, but would it be
 better to write a driver specifically for this chip?


RTC parts are not intended for hold-over input into NTP.  Unless you've
lost network access you'd do better to use a remote system.



 And a side question: Is it the GPS module that calculates when the PPS
 goes active?


If by calculate you mean determine then yes the PPS source (typically but
not exclusively a GPS in the NTP community) completely determines when the
PPS signal is active but I suspect you have a different question in mind.


 Is this signal compensated for the time it takes the signal from the sats
 in the module, or on the SV?


I've decided I have no idea what this question means.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS Offset problems

[Paul]

On Mon, Feb 2, 2015 at 4:48 PM, utah...@gmail.com wrote:

 Back to the offset with the HP Z3801 and Z3805.  This is not a leap second
 bug, it is something I am doing wrong on the HP; I've got two Z3805s off by
 16 seconds


They're using GPS rather tnan UTC time.  Presumably some SCPI like this:

:DIAG:GPS:UTC?

will check and this:

:DIAG:GPS:UTC 1

will change it.  You may have to reset/reboot the units after changing time
scale.  Check the manual.


 and one Z3801 off by one second.


Don't have any insight into this.  Perhaps you're triggering on the wrong
edge plus an offset.  After due diligence (there's a lot of information
about the Z38xx to read) you could ask on time-nuts.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS Offset problems

[Paul]

On Fri, Jan 30, 2015 at 8:09 PM, utah...@gmail.com wrote:

 Any idea what I am doing wrong?


Probably nothing wrt the Datums. The 2100 has the apply as soon as
announced leap second bug.  There are some receivers. including the Z3812,
that want to apply the leap second in March but the Z3801 is reported to be
working correctly.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] Trouble using refclock 18 (ACTS)

[Paul]

I have a USR 5637 connected to a Linux host using a VoIP line.  I can
manually dial and often* successfully connect to the NIST/USNO numbers.
When used as a server it typically manages two (at random) successful
connections over 8 polls. All other connection attempts fail including all
other calls after the second success.  Restarting NTPd repeats the 2 of 8
process. I did remove the  Y command from the modem initialization string
since it doesn't do what's expected.

Does anyone have any tips for getting this to work reliably?

*Often is ~ 60%. Sometimes the line is busy, sometimes no carrier,
sometimes the baud is wrong but most failures are silent time outs.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM

[Paul]

On Thu, Jan 22, 2015 at 10:28 PM, Harlan Stenn st...@ntp.org wrote:

 They are both reporting seconds.


I'll change the subject on any further messages regarding sntp as a proper
replacement for ntpdate.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM

[Paul]

On Wed, Jan 21, 2015 at 10:46 PM, Harlan Stenn st...@ntp.org wrote:

 Right, so if you don't want that use sntp instead.


Are these numbers consistent?  If ntpdate is reporting seconds and sntp is
reporting milliseconds then it an order of magnitude difference.  Otherwise
it's several orders of magnitude.

server 192.168.0.244, stratum 1, offset -0.09, delay 0.02571
22 Jan 10:46:13 ntpdate[31506]: adjust time server 192.168.0.244 offset
-0.09 sec

sntp 4.2.8p1-beta5@1.3265-o Tue Jan 20 04:48:55 UTC 2015 (2)
2015-01-22 10:46:13.241424 (+0500) -0.00129 +/- 0.001866 ntpa 192.168.0.244
s1
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM

[Paul]

On Thu, Jan 22, 2015 at 4:07 AM, Rob nom...@example.com wrote:

 The problem is that ntpd believes that corrections it is applying are
 because of frequency errors in the clock, while in this case they
 are because of resets done externally.

 During the startup phase, bad things happen anyway (like touching the
 carefully determined and saved drift value), doing a couple of successive
 restarts makes it worse because adjtime effects accumulate in the kernel
 without knowledge of ntpd.



I suspect the request was for more information not more speculation or
anecdotes.  It's probably okay to say well it worked like that in 4.2.2
but then the answer is update to a newer version.

Problems in the quoted message:
Confusing phase and frequency.
Proposing undocumented (mis)behavior regarding ntpd start-up (pre-SYNC).
Speculating that adjtime has memory.

And of course the OP (per the subject) is talking about Windows not Unix.

Applying a fixed offset outside of ntpd makes it worse.


I don't know what this means.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM

[Paul]

On Wed, Jan 21, 2015 at 5:24 PM, Harlan Stenn st...@ntp.org wrote:

 What is missing?  We thought we caught all of the useful cases.


I made a small error.  I meant ntpq and ntpd.
ntpdate -d
ntpdc fudge (admittedly that's not a query)
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM

[Paul]

On Wed, Jan 21, 2015 at 6:00 PM, Mike Cook michael.c...@sfr.fr wrote:

   I don't have a free client to test this on, but I believe that by
 default ntpdate will SLEW the clock


Yes, even the most cursory grep of ntpdate shows adjtime and slewing.  The
-b and -B flags provide coarse controls.  Unless you're a victim of
SYS_WINNT.

Or (given adjtime) you could trust the man page.  Under SYS_WINNT it
appears to log an error about not using -b if you don't use -b.

 -b Force the time to be stepped using the settimeofday(2) system
call,
 rather than slewed (default) using the adjtime(2) system
call.  This
 option should be used when called from a startup file at boot
time.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM

[Paul]

On Wed, Jan 21, 2015 at 10:17 PM, Harlan Stenn st...@ntp.org wrote:

  ntpdate -d

 That's covered.  See
 http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate


I may be abusing ntpdate but ntpd -q -d (but sets the clock!) is not the
same as ntpdate -d which explicitly doesn't set the clock.

  ntpdc fudge (admittedly that's not a query)

 That's covered.  See the :config command in ntpq.


I'll admit I haven't tried that since 4.2.6 when it didn't work.  I'll try
again.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM

[Paul]

On Wed, Jan 21, 2015 at 5:40 PM, Harlan Stenn st...@ntp.org wrote:

 ... I'm not aware of anything on either Windows or Unix that would cause
 any
 applied immediate adjustment to have *any* residual affect on ntp.


Well ... at least under Linux if ntpdate calls adjtime and then another
program calls adjtime before the first completes the result may not be what
is expected.  Under SYS_WINNT ntpdate only steps.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM

[Paul]

On Wed, Jan 21, 2015 at 9:48 AM, Sander Smeenk ssme...@freshdot.net wrote:

 What is actually wrong with running ntpdate to initially sync a clock?


Nothing. The party line is that ntpdate and ntpdc are deprecated.   I do
hope that ntpq eventually incorporates all the features (I care about) of
ntpdc and ntpdate before they stop maintaining them.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver

[Paul]

On Tue, Jan 20, 2015 at 6:51 AM, George Ross g...@inf.ed.ac.uk wrote:

 From the Acutime 2000 user guide: The time tag provides a resolution of
 320ns   Is PPS going to be sufficiently better that it would outweigh
 the additional setup complexity?


No.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver

[Paul]

On Tue, Jan 20, 2015 at 1:45 PM, William Unruh un...@invalid.ca wrote:

  You would presumeably want a daemon to read the clock and toggle the pin,
 perhaps with interrupts turned off


That would be NTPd refclock 29 mode N where N select an event stamping
receiver.  Naturally doing this in user space increases latency.  Someone
should look and see if this is better than PPS.


  Not sure how long a pulse it requires.


At least one microsecond for the Acutime 2000 and probably similar for the
other devices.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Leap second to be introduced in June

[Paul]

[And this is why I wonder why leap seconds are discussed here.]

On Mon, Jan 19, 2015 at 7:15 AM, Mike S mi...@flatsurface.com wrote:

 You clearly misunderstood TF.460


You're using the wrong reference.  Try this one from 2007:

http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf

which provides the CCTF rationale for making discontinuous UTC continuous.

You can skip to the last page if you like but you shouldn't.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Leap second to be introduced in June

[Paul]

On Mon, Jan 19, 2015 at 9:56 AM, Mike S mi...@flatsurface.com wrote:

 You're citing a internal letter, from one BIPM group to another, asking
 them to bring something before the ITU. It's not normative, it's not
 informational, it's just correspondence.


That doesn't make any sense.  When the ITU decides *not* do to something
it's equally informative as when they decide to do something.

Just to be clear you're saying everyone, including the CCTF (previously
cited) and the ITU, that says UTC is discontinuous is wrong?

For those wonder that internal letter from CCTF to BIPM notes that The
UTC system as defined today is a *stepped* atomic time scale [emphasis
mine] which is quoting the ITU and can also be found at 
http://www.itu.int/net/newsroom/wrc/2012/reports/atomic_time.aspx which
discusses why the ITU continues to leave UTC stepped.

UTC is a discontinuous time scale composed from segments that are linear
transformations of atomic time, the discontinuities being arranged so that
UTC approximated UT2 https://en.wikipedia.org/wiki/UT2 until the end of
1971, and UT1 https://en.wikipedia.org/wiki/UT1 thereafter.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver

[Paul]

On Mon, Jan 19, 2015 at 2:57 AM, George Ross g...@inf.ed.ac.uk wrote:

  Is there anyone with the prior experience in getting these older
  Trimble units to work?

 We've had a Trimble Acutime 2000 running since 2005, at two separate sites.


Although the Palisades driver has been extended to the Praecis, Thunderbolt
and Acutime the document at 
http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver29.html is silent
on what is now best practice for Trimble timing receivers.   Presumably PPS
was ignored because the event based timing packets yield reliable
sub-millisecond offsets.  The driver and document should be brought into
the PPS era and be renamed the TSIP refclock rather than Palisades.

Palisades/NMEA + ATOM is the way to use these receivers.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Leap second to be introduced in June

[Paul]

On Mon, Jan 19, 2015 at 10:43 AM, Mike S mi...@flatsurface.com wrote:

 Again, you need to up your understanding of standards terminology.


No, if you're going to use jargon you should provide the meanings you're
using.  Since you clearly have your own version of reality it will help the
rest of us.


 non-sequitur. They're comparing UTC with TAI. From a TAI perspective, UTC
 steps backwards. From a UTC perspective, TAI steps forward, going further
 out of sync with Sol. However, mathematically both are continuous functions.


I can't believe you actually typed that.

I apologize to the list for feeding the troll.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] I don't understand Restrict statements!

[Paul]

On Mon, Jan 19, 2015 at 4:55 AM, David Taylor 
david-tay...@blueyonder.co.uk.invalid wrote:

 I get errors flagged at the points marked with X below:


Did you upgrade the version of NTPd?  I don't think older versions checked
for or cared about invalid keywords.


 I've tried reading the documentation, but it has failed to enlighten me
 sufficiently!


Everything (nominally) permitted on a restrict line is listed here: 
http://www.eecis.udel.edu/~mills/ntp/html/accopt.html
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!

[Paul]

On Fri, Jan 16, 2015 at 2:02 AM, Terje Mathisen terje.mathi...@tmsw.no
wrote:


 Anyway it is definitely possible to get into the 100K to 1M
 requests/second range.

 As I noted above the real problem isn't in the actual packet processing,
 which can be made very efficient indeed for the normal case of client mode
 request/reply, but in all the HW/driver/OS overhead that's occured before
 you get those packets inout of the ntpd process.

 Re. the Fitlet: With a 3.9 to 4.5 W power budget this box will never get
 into those ranges, but even handling 1K requests/second with sub-ms jitter
 and delay would still be a very nice Pool server.


On Fri, Jan 16, 2015 at 5:22 AM, Hal Murray hmur...@megapathdsl.net wrote:

 A Raspberry PI can do 1500 packets per second.


M Tharp's Laureline 
https://www.tindie.com/products/gxti/laureline-gps-ntp-server can responds
to thousands of requests per second using an Arm Cortex processor.  The
trick is doing the right thing.  His code is efficient and there's no OS.
Just a framework to hang some drivers on, a PHY interface and a GPS.  It
could probably be considered the appliance instantiation of ntimed-master.
It's too bad he stopped making them.  Mine has typically has O(10)
microseconds of offset/jitter from other clique members as you'd expect
from 100Mb ethernet.

There are various NTPd things it doesn't do; some folks would consider that
a win.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!

[Paul]

On Fri, Jan 16, 2015 at 9:02 AM, Charles Elliott elliott...@comcast.net
wrote:

 Never tell a person he is wrong ...


I'm not sure what your point is but that statement is ridiculous.  Frequent
and immediate correction is the PLL we want here.  Wrong answers don't help
anyone.

By the way, you can't send mail to nom...@example.com.  I'm sure being
somewhat anonymous enables statements like Harlan has decided to keep us
in the dark and feed us shit..
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver

[Paul]

On Fri, Jan 16, 2015 at 7:49 PM, Oceanos Admin sysad...@cellmail.com
wrote:

 Hi:

 We were looking to use an older Trimble Thunderbolt 8 channel GPS receiver
 for providing a Stratum 1 time reference



The standard hobbyist T-Bolt management program is Lady Heather.  It a
windows (dos) program that will run under Wine.  You can use it to
completely manage a T-Bolt.  It will also correctly initialize one.  The
Palisades driver has a bug that prevents correct set-up if you've managed
to get it misconfigured.

http://www.ke5fx.com/heather/readme.htm.

While message timing variability is much better than your typical GPS you
should use the PPS output via the ATOM/PPS refclock.

You'll probably get some advice to switch to simpler, more modern GPS
rather than an aging GPSDO.  They are a reasonable alternative if only for
reduced power consumption but given a standard serial port a T-Bolt is plug
and play.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!

[Paul]

On Thu, Jan 15, 2015 at 12:03 PM, Rob nom...@example.com wrote:

 Terje Mathisen terje.mathi...@tmsw.no wrote:
  it would seem to
  be a nice NTPD startum 1 server.

 Of course, it could still be good enough when you want to use it as a
 network time server.


Which is what was suggested.  After all this is an NTP list not a high
resolution timing list.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!

[Paul]

On Thu, Jan 15, 2015 at 8:41 AM, Terje Mathisen terje.mathi...@tmsw.no
wrote:

 [Fitlet] includes a serial port which should make it trivial to attach a
 Sure GPS board.


If they use a standard pinout.  The PC-2i didn't support DCD which makes it
not quite trivial.
Hopefully the hardware documents will be released soon.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!

[Paul]

On Thu, Jan 15, 2015 at 2:20 PM, David Taylor 
david-tay...@blueyonder.co.uk.invalid wrote:

 .. although expensive compared to a Raspberry Pi, if somewhat better in
 potential performance.


Among my (S1) clique of clocks the leading predictor of offset is network
connection not cpu.
As you might expect given the nature of NTP.

The gig attached clocks  are the best and USB ethernet is the currently the
worst.  WiFi and powerline networking are the worst of the bad.

The second leading predictor is software.  ntimed-client is better than NTP
on my more difficult S2 clients.

This is applies only to my Linux boxes.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!

[Paul]

On Thu, Jan 15, 2015 at 1:16 PM, Rob nom...@example.com wrote:

 It was suggested as a high-perf NTP server


That string is not in the message.  It's not a quote despite your quotation
marks.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!

[Paul]

On Thu, Jan 15, 2015 at 4:40 PM, Terje Mathisen terje.mathi...@tmsw.no
wrote:

 Not in my msg, but in the subject of the entire thread. :-)


I'm so used to nomail@example being wrong I had a knee-jerk reaction.  My
bad.

This does give me the chance to ask what a high-perf NTP server might be.
Given the constraints of the protocol I've always thought of performance in
terms of queries per seconds.  What metric are you using?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!

[Paul]

On Thu, Jan 15, 2015 at 9:23 PM, William Unruh un...@invalid.ca wrote:

  This does give me the chance to ask what a high-perf NTP server might be.
 I would have assumed the accuracy with which ntpd disciplines the computer


The jitter variability (from loopstats) on one of my clocks is ~1e-7, on
another it's ~9e-7s and on a third it's ~2e-8s.  Do you think that's
visible to the S2 clients?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Leap second to be introduced in June

[Paul]

On Wed, Jan 14, 2015 at 5:00 AM, Terje Mathisen terje.mathi...@tmsw.no
wrote:

 By _far_ the largest majority of all system time calls are asking for the
 _current_ time, right?



Are there (common) systems that have kernel calls for other than the
current time?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Leap second to be introduced in June

[Paul]

On Mon, Jan 12, 2015 at 12:46 AM, Mike Cook mike.c...@orange.fr wrote:

  Why do folks mention leap seconds on this list?
   part of the NTP protocol deals with the scheduling insertion/deletion of
 leap seconds.


I should have phrased that differently.   Or just let it go.



  Why do people point to leap-seconds.NTPtimestamp instead of just
  leap-seconds.list?

   leap-seconds.list is not the file itself


I understand but the udel doc and comments in the file itself say get
leap-seconds.list not leap-seconds.hard-to-predict-ntp-timestamp.  Every
previous specific reference becomes wrong when the next file is created.
The reason for leap-seconds.list is obvious -- why people post other things
is not.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP 4.2.8 for Windows, not branded

[Paul]

On Mon, Jan 12, 2015 at 10:58 AM, Danny Mayer ma...@ntp.org wrote:

 None of these are valid nor are they for you to use.


Take down the mailing list/Usenet gateway. Or make it smarter. I would vote
for the former.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Leap second to be introduced in June

[Paul]

Why do folks mention leap seconds on this list?
Why do people point to leap-seconds.NTPtimestamp instead of just
leap-seconds.list?

My five line leap second file with comments and one extra line for
(completely unnecessary) context.

#$  3629404800
#@  3660249600
3550089600  35  # 1 Jul 2012
3644697600  36  # 1 Jul 2015
#h  6eb5f274 cb8c4f5d 6ac15b69 6b095017 f219e7c
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Leap second to be introduced in June

[Paul]

On Sun, Jan 11, 2015 at 11:34 PM, brian utterback 
brian.utterb...@oracle.com wrote:


 On 1/11/2015 10:40 PM, William Unruh wrote:
  Well, actually as I understand it, ntpd does stop the cclock for that
  second

 That is not the case. That is the behavior that the kernel reference
 code implements which is not part of ntpd.


Presumably unruh@invalid read this discription of NTP leapseconds:

There are three approaches to implementing a leap second. The first
 approach is to increment the system clock during the leap second and
 continue incrementing following the leap. The problem with this approach is
 that conversion to UTC requires knowledge of all past leap seconds and
 epoch of insertion. The second approach is to increment the system clock
 during the leap second and step the clock backward one second at the end of
 the leap second. This is the approach taken by the POSIX conventions. The
 problem with this approach is that the resulting timescale is discontinuous
 and ambiguous, since a reading during the leap is repeated one second
 later. The third approach is to *freeze* the clock during the leap second
 allowing the time to catch up at the end of the leap second. This is the
 approach taken by the NTP conventions.

 And further

 If the precision time kernel modifications have been implemented, the
 kernel includes a state machine that implements the actions required by the
 scenario. The state machine implemented in most recent Unix kernels is
 described in the nanokernel
 sftp://www.eecis.udel.edu/%7Emills/nanokernel.tar.gz software
 distribution. At the first occurrence of second 3,124,137,600, the system
 clock is stepped backward one second. The operating system kernel time
 conversion routines can recognize this condition and show the leap second
 as number 60.

The table presented on that page notes that the NTP timestamps for :60 (the
leap second) and :00 are the same.  Of course things could have changed
since 12-May-2012 23:43 UTC when that page was last revised.

Strictly speaking the answer to the OP is it depends.  Not only on the
system but how you ask the implicit question -- what time is it.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP 4.2.8 for Windows, not branded

[Paul]

On Fri, Jan 9, 2015 at 5:57 PM, trackeroft...@gmail.com wrote:

 Yes, it is still not clear for me. If p1 is the latest release so why the
 files are marked as beta4, beta5? It looks like rc version, not final.


Assuming it's something like 4.2.8p1-beta5:

4.2.8P1BetaN are newer than 4.2.8 but they're not release candidates like
4.2.8.pN-RCm will be.

You can see the 4.2  releases here: http://archive.ntp.org/ntp4/ntp-4.2/.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Firewall requirements for NTP as both client and server

[Paul]

On Sun, Dec 28, 2014 at 11:11 AM, David Taylor 
david-tay...@blueyonder.co.uk.invalid wrote:

 I wonder whether this might be a firewall issue



The first question is always: does it work with the firewall off?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Firewall requirements for NTP as both client and server

[Paul]

These are some commands that might stop your instance. Or set your house on
fire.

/etc/rc.d/ipfw stop
ipfw disable firewall
ipfw -f flush

Your traces certainly look like the firewall is blocking the traffic.

On Sun, Dec 28, 2014 at 2:37 PM, David Taylor
david-tay...@blueyonder.co.uk.invalid wrote:
 Very good question, but I couldn't find a way to disable ipfw!  I did say
I am a complete novice at this
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions