From halmurray at sonic.net Tue Dec 2 06:01:45 2025 From: halmurray at sonic.net (Hal Murray) Date: Mon, 01 Dec 2025 22:01:45 -0800 Subject: FreeBSD: update to 15.0 vs ntpc.cpython-311.so Message-ID: <20251202060145.D7A2162003D@107-137-68-211.lightspeed.sntcca.sbcglobal.net> FreeBSD 15.0 is out libutil.so had been version bumped from 9 to 10 The old ntpc.cpython-311.so links to the old libutil.so.9 That breaks ntpmon and friends A simple build and install doesn't fix things. It works after I delete the old file. Does anybody remember/understand this area? The old file was: /usr/local/lib/python3.11/site-packages/ntp/ntpc.cpython-311.so The new files are: .../ntp/__pycache__/ntpc.cpython-311.py{c,o} Was my old file just leftover trash from when things worked that way? I wonder how long ago that was... -- These are my opinions. I hate spam. From halmurray at sonic.net Thu Dec 4 09:15:34 2025 From: halmurray at sonic.net (Hal Murray) Date: Thu, 04 Dec 2025 01:15:34 -0800 Subject: PPS over USB Message-ID: <20251204091534.C3DC462003D@107-137-68-211.lightspeed.sntcca.sbcglobal.net> James said: > I haven't tested it yet, as I'm attempting to 'improve' my PPS over USB > setup. Do you know what you are getting into? 1/2 ;) It's either fun if you are in the right mood, or a pain in the butt if you are unlucky. Do you know about hanging bridges? http://www.leapsecond.com/pages/m12/sawtooth.htm You can get the same thing with the USB clock beating against the PPS clock. The USB clock is derived from the CPU clock. That varies with temperature. I have one setup that gets a good hang on a cold winter night. If your clocks aren't close to in-sync, then ntpd will average over several/many samples with a random offseet. That's the common case. Your clock will be 1/2 ms off if you are using real slow USB and 1/2 of 125 microseconds if it's using the faster USB. I forget what USB calls them. Most GPS USB gizmos are slow and don't have PPS. If the clocks get very very close to in-sync, then the offset isn't random. If the clocks are close enough to in-sync, then all the samples will be close to the same offset. Putting ntpd on top of that adds another layer of complexity. -- These are my opinions. I hate spam. From davehart at gmail.com Thu Dec 4 12:06:57 2025 From: davehart at gmail.com (Dave Hart) Date: Thu, 4 Dec 2025 12:06:57 +0000 Subject: PPS over USB In-Reply-To: <20251204091534.C3DC462003D@107-137-68-211.lightspeed.sntcca.sbcglobal.net> References: <20251204091534.C3DC462003D@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: It would really help if someone would introduce a USB 3 UART. The typical USB serial ports are, as Hal indicated, stuck behind the 1 poll per millisecond USB 2 architecture. AIUI, USB 3 allows the device to alert the host without polling. Cheers, Dave Hart -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesb192 at jamesb192.com Thu Dec 4 14:04:13 2025 From: jamesb192 at jamesb192.com (James Browning) Date: Thu, 4 Dec 2025 06:04:13 -0800 (PST) Subject: PPS over USB In-Reply-To: References: <20251204091534.C3DC462003D@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <1290744141.1145721.1764857053953@privateemail.com> James Browning first wrote: JB> I haven't tested it yet, as I'm attempting to 'improve' JB> my PPS over USB setup. To which Hal Murray replied: HM> Do you know what you are getting into? 1/2 ;) No, not a clue. It looked like a fun aside while my merge requests ferment. I do not recall having seen those graphs before. I looked up the Host Controller Interfaces: they are Universal (1.x Intel/Via), Open (1.x everyone else?), Enhanced (2.x), and eXtensible (3.x). Later, Dave Hart chipped in: DH> It would really help if someone would introduce a USB 3 UART. I do not think it profits the vendors enough, yet. --- The notion I had was to measure the greatest and the least host offsets in microseconds. Also, stash the number of samples before a 900 (or more) microseconds drop. Take the midpoint of the range(?) and store it to be added to the next batch of samples. Then, take about a third of the slope from the notional bottom left to the top right and subtract it from the above results. I think it worked better before I ported it to C.