Re: [time-nuts] once again timenuts in the news

Usenix paper: https://www.usenix.org/system/files/conference/nsdi18/nsdi18-geng.pdf Usenix talk: https://www.usenix.org/conference/nsdi18/presentation/geng At the end of the talk the presenter mentions WAN sync between labs at Utah, Wisconsin and Clemson "under 10 microseconds" I'd like to

Re: [time-nuts] NIST

I found the public comments from Microsemi , but couldn't locate my response. At one time the full set of RFI public responses was on-line. The NIST 60 kHz time service is widely used by

Re: [time-nuts] Network Time Puzzle

See figures 7 & 8 in http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf When a router forwards an NTP packet multiple potential egress links may have equal cost. In order to distribute the traffic across the egress links the router can use the IP addresses and UDP source/destination port

[time-nuts] PTTI 2020 Keynote

FYI https://www.ion.org/ptti/call-for-abstracts.cfm PTTI Keynote Address "Atomic Timekeeping as a Hobby" Tom Van Baak, Leapsecond.com ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to

Re: [time-nuts] Noob question, NTP stratum 1.

US operators are planning to shut down their CDMA networks. See for example https://www.fiercewireless.com/wireless/verizon-to-shut-down-2g-cdma-1x-network-by-end-2019 I wouldn't be surprised to see this date get pushed back though. On Mon, Jul 22, 2019 at 8:05 PM K5ROE Mike wrote: > You

Re: [time-nuts] can of worms: time-of-day in a community radio station

Each NTP Pool server's real-time status can be seen at https://www.ntppool.org/scores/*ip_address* I can't answer questions about the monitor's source code NTP server timestamp errors happen occasionally. Internet delays and losses are unpredictable. My

Re: [time-nuts] can of worms: time-of-day in a community radio station

You can't test a server for smearieness. It wouldn't surprise me if some of them turn out to be getting time from google servers or something similar. The last time I checked over 50 of the NTP pool stratum 2 servers used Google, based on the Reference ID. The NTP pool folks are aware of the

Re: [time-nuts] can of worms: time-of-day in a community radio station

I scanned the NTP pool last leap second and relayed the list of offenders to Ask. NTP pool servers may use a mixture of smeared and non-smeared upstream servers. Yuck. While the NTP pool has limitations it is widely used (and abused). NTP servers outside of the NTP pool may also be imperfect.

Re: [time-nuts] John Fluke test equipment tutorial

https://tycho.usno.navy.mil/ptti.html archived 2012 and earlier PTTI papers. That site seems to be unavailable now, but the Internet Archive still holds copies. Circa 2013 PTTI and ION merged, new papers are paywalled. On Wed, Nov 27, 2019 at 11:20 AM Bob kb8tq wrote: > Hi > > Both the

Re: [time-nuts] NTP pool reliability

NTP pool performance depends on several factors. The primary pool monitor, located in Newark, New Jersey, periodically polls each NTP server. Based on reachability and calculated offset each server is assigned a score. See https://www.ntppool.org/scores/192.36.143.151 for example. If a

Re: [time-nuts] Any (relatively) cheap TSIP GPS receivers without WNRO out there?

ntpsec, a fork of the classic NTP distribution, supports an option to compensate for the 1024 week rollover: https://docs.ntpsec.org/latest/ntp_conf.html time1 sec Specifies a constant to be added to the time offset produced by the driver, a fixed-point decimal number in seconds. Each "g" on the

Re: [time-nuts] an interesting timing problem

This discussion focuses on interactive audio/data streams. One-way streams are treated differently, since delay is less important. Media transport typically uses IPv4/6 networks and can often be captured at one of the endpoints or somewhere in the network path. E.g., I captured a Skype call

[time-nuts] CDMA NTP servers beginning to fail

In the past few months I've noticed problems on multiple US-based public NTP stratum 1 servers that use CDMA as their stratum 0 clock.. EndRun Technologies Tempus LX ( https://endruntechnologies.com/pdf/USM3014--000.pdf) is an example. This is not a surprise. In the US Verizon has announced

Re: [time-nuts] Raspberry Pi NTP server

dulation being used. A Bell 103 or 202 is a hundreds of bits/second > device, so carrier acquisition/detect is typically 10s of bit times. For > fancier modems with multitone signalling and coding, it could be many > seconds for the speed negotiation to complete. > > TL;DR - there's no

Re: [time-nuts] Raspberry Pi NTP server

Petr, Is the variance plot based on PPS timestamps, or on NTP's smoothing of the timestamps? Have you measured the offset? On Mon, Jul 13, 2020 at 10:54 AM Petr Titěra wrote: > On 12.07.2020 3:57, jimlux wrote: > > On 7/11/20 1:30 PM, Steven Sommars wrote: > >> Usin

Re: [time-nuts] Raspberry Pi NTP server

My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific PL2303, which supports USB 2.0 The PPS jitter is 1 msec (e.g., using ppstest). lsusb -v shows: Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port bInterval 1 which means 1

Re: [time-nuts] Raspberry Pi NTP server

I don't want to hijack Andrew's thread. Just wanted to add to Achim's comments about jitter and offset. USB2 devices should accept polls every 125 microseconds. [My USB knowledge is limited.] I have two devices. One is the Navisys GR701 which I suspect you're familiar with; it is an

Re: [time-nuts] Raspberry Pi NTP server

saying that the NMEA messages must > have such low latency however - in general they merely must arrive in time > before the next 1PPS, so USB serial is fine for that traffic. > > -Tim > > On Thu, Jul 9, 2020 at 9:00 AM wrote: > > > Message: 4 > > Date: Wed, 8 Ju

[time-nuts] ISS NTP operation problems.

At the end of November a question was posed to the ntp.org list concerning NTP problems on the International Space Station. With William's permission I'm following up on the time-nuts list. I analyzed NTP/IP packet captures

Re: [time-nuts] ISS NTP operation problems.

Responses to several comments. Opportunities to collect critical NTP debugging data on the ISS will be limited. Specific suggestions sent to me off-list would be appreciated. Earth station to ISS delays: I inferred the 600-700 msec RTT using the reported root distance [I've seen much higher

[time-nuts] Re: NTP servers

LeoNTP note:I've seen these units infrequently return NTP responses that are off by N-seconds (N is a small integer.) I could not determine the root cause. One other oddity. The returned NTP root dispersion is always 0, even when the unit runs in holdover mode. The support people say that

[time-nuts] Re: Leap indicator set to 1 !

the previous leap second. On Sat, Nov 27, 2021 at 9:22 AM Steven Sommars wrote: > FYI. > > At 2021-11-27 00:00:00 UTC many public NTP servers began setting the leap > indicator to 1. > This may be gpsd related > ___ time-nuts mailing

[time-nuts] Re: Leap indicator set to 1 !

>>The incorrect leap indicator began 256 weeks + 1 days since the previous leap second. The incorrect leap indicator began 256 weeks - 1 day since the previous leap second. Sorry for sign error On Sat, Nov 27, 2021 at 11:38 AM Steven Sommars wrote: > A number of the NTP servers a

[time-nuts] Leap indicator set to 1 !

FYI. At 2021-11-27 00:00:00 UTC many public NTP servers began setting the leap indicator to 1. This may be gpsd related ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To

[time-nuts] NTP Leap indicator set to 1 ! problems continue

This is written at 2021-11-30 15:45 2021-11-27 00:00:00 NTP servers start advertising leap=1. 2021-11-28 00:00:00 Many of these servers execute leap procedure. Leap=0 no longer advertised (mostly) 2021-11-30 00:00:00 *Another set of NTP servers start advertising leap=1.* 2021-12-01

[time-nuts] Re: NIST NTP servers way off for anyone else?

On Tue, Dec 14, 2021 at 11:40 AM Michael Rothwell wrote: > I see some high offsets on my local monitoring (synced to time.google.com > ). > Especially time-e-b on ipv6. > This observation is correct and is caused by queuing delay on the NIST server. NIST NTP mode 3 requests are apparently

[time-nuts] Re: NIST NTP servers way off for anyone else?

The Gaithersburg servers are accurate. This plot shows Gaithersburg time-e-g.nist.gov for the current month. [image: image.png] My monitoring client is located near Chicago and is Stratum-1 GPS sync'd. Typical round-trip time to Gaithersburg is ~27 msec. On 2021-12-07 a few monitoring polls saw

[time-nuts] Steering UK time station MSF

NIST steers the WWV/WWVB/WWVH radio stations using GPS common view. Recent youtube piece on MSF https://www.youtube.com/watch?v=yqciKS_N0K8 I was surprised that NPL (Teddington) steers MSF (Anthorn) based on the signals received at NPL. While this steering seems less accurate than GPS common

[time-nuts] Re: NTP server source needed

Though I don't have a Time Machines NTP server I've monitored them for several years and have seen a number of "off by N-seconds" errors. The manufacturer reproduced the problem and released new firmware for the TM2000B. I don't know the status of other models. I would be hesitant to trust the