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 issue. Several other NTP pool servers make use of AWS NTP. This too is smeared, see https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html. On Sun, Oct 20, 2019 at 9:00 PM Hal Murray wrote: > > themadbea...@gmail.com said: > > In reference to using the NTP Pool, someone mentioned they don't trust > them > > and the possibility of a "rogue" server. The NTP Pool has a monitor that > is > > constantly querying every server in the pool, if the time drifts too far > it > > is removed from the DNS rotation. > > There is a catch. The pool code in ntpd never goes back to check to see > if a > server has been kicked out of the pool or resigned. As long as the server > keeps responding, it will be used but subject to the usual filtering > rules. > If it stops responding, ntpd will drop it and do another DNS query to get > a > replacement. (There may be some hysteresis on how-many.) > > Note that there are 2 ways to use the pool. You can say > server pool.ntp.org (or us.pool.ntp.org or 0.us.pool.ntp.org) > That will latch on to one of the servers in the pool. > It won't do the replacement dance I described above. > Next time you boot or otherwise restart ntpd you will probably get a > different > server. > > In the old says, before ntpd supported the pool command in ntp.conf, it > was > common to see things like: > server 0.pool.ntp.org > server 1.pool.ntp.org > server 2.pool.ntp.org > server 3.pool.ntp.org > (Slot 2 also returns IPv6 addresses.) > > You can also say: > pool us.pool.ntp.org > That will take several servers from the DNS response and try again later > if it > needs more. > > > > Also, none of the servers in the pool > > should be using leap-smearing (a requirement you mentioned). > > 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. > > > > -- > These are my opinions. I hate spam. > > > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] CATV assymetries
CATV plant in inherently asymmetric in delays. Referring to the DOCSIS (data over cable service interface specification) specs for North America: Downstream to the customer: 6 MHz channels with 64- or 256-level QAM modulation. If 256-QAM is used, the raw usable bandwidth is about 38 Mbit/s per channel. Upstream from the customer: 6.4 MHz channels (with fallback to channel widths between 0.2 and 3.2 MHz when talking with DOCSIS v1 equipment) QPSK, 8-, 16-, 32- or 64-level QAM DOCSIS v3.1 allows up to 1024-level, optionally also 2048 or 4096. Max rate with 4096-QAM and 25 kHz sub channel carrier spacing is 1.89 Gbit/s per 192 MHz OFDM channel. DOCSIS 3.0 support channel bonding, allowing multiple channels to be used simultaneously to/from the same customers. Downstream channels are shared and therefore traffic queuing may occur because of activity of other customers. Similarly, upstream channels may be shared by customers via TDMA or S-CDMA. Some contention can occur if customers transmit simultaneously. Signal-to-noise ratios may force specific customers to use lower speeds. These represent a large set of combinations that yield different downstream and upstream throughputs. More generally, asymmetric behavior is almost guaranteed on CATV plant between the customer site and the cable head end. Upstream packets take longer to send then downstream, and may have to contend for their channel(s). Downstream packets are sent faster but may queue. Between the cable head end and the public NTP server, symmetrical delays may be more prevalent. — Eric > On 2019 Oct 20, at 19:31 , Hal Murray wrote: > > > f...@cattaneo.us said: >> Maybe I should double check the routing from both ends again and make sure >> they are really symmetric.. I can also ask my coworkers in the networking >> group and hear what they think about it. > > We need a cable TV geek. > > It wouldn't surprise me if the upstream traffic went through a couple of > extra > hoops/hops that aren't visible at the IP level using tools like ping and > traceroute. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Flash!!! FA2 works on Arduino Tablets !!!
The interface from the FA2 is USB, so there is no need (and no way) to go through a DB9. I recommend using an adapter to go from your tablet (typically micro-USB or USB-C) to a USB-A socket, then use a standard USB-A male to USB-B male cable going to the FA2. One issue: once the tablet is connected to the FA2, there will be no way to charge the tablet, so start with a fresh battery... The app keeps the screen activated as long as the battery is >50%. After that, Android will put the app to sleep and recording will stop and the data that is not saved will be lost. There are a number of ways to deal with that, I am waiting to see actual use cases to come up with the best way. The battery life limitation is clearly an issue. You can buy cables that have a charging port but they only power the target (the FA2 in this case), not the tablet. I believe that you cannot charge the battery when the USB port is used as a master because as a master it is intended to deliver power, not receive it. Didier KO4BB On Sun, Oct 20, 2019, 10:19 AM Jim Harman wrote: > Didier, > > This looks very useful. Is there a specific DB9 to USB-C cable that you > would recommend, or would you use a USB-A (female) to USB-C adapter with a > standatrd USB-A to DB9 cable? > > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] can of worms: time-of-day in a community radio station
Hi Once you dig into all the sources of delay, the asymmetry is much more likely to be dimensioned in miliseconds than in microseconds. There are a lot of things that contribute to the total. Bob > On Oct 20, 2019, at 7:31 PM, Hal Murray wrote: > > > f...@cattaneo.us said: >> Maybe I should double check the routing from both ends again and make sure >> they are really symmetric.. I can also ask my coworkers in the networking >> group and hear what they think about it. > > We need a cable TV geek. > > It wouldn't surprise me if the upstream traffic went through a couple of > extra > hoops/hops that aren't visible at the IP level using tools like ping and > traceroute. > > > -- > These are my opinions. I hate spam. > > > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] can of worms: time-of-day in a community radio station
themadbea...@gmail.com said: > In reference to using the NTP Pool, someone mentioned they don't trust them > and the possibility of a "rogue" server. The NTP Pool has a monitor that is > constantly querying every server in the pool, if the time drifts too far it > is removed from the DNS rotation. There is a catch. The pool code in ntpd never goes back to check to see if a server has been kicked out of the pool or resigned. As long as the server keeps responding, it will be used but subject to the usual filtering rules. If it stops responding, ntpd will drop it and do another DNS query to get a replacement. (There may be some hysteresis on how-many.) Note that there are 2 ways to use the pool. You can say server pool.ntp.org (or us.pool.ntp.org or 0.us.pool.ntp.org) That will latch on to one of the servers in the pool. It won't do the replacement dance I described above. Next time you boot or otherwise restart ntpd you will probably get a different server. In the old says, before ntpd supported the pool command in ntp.conf, it was common to see things like: server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org server 3.pool.ntp.org (Slot 2 also returns IPv6 addresses.) You can also say: pool us.pool.ntp.org That will take several servers from the DNS response and try again later if it needs more. > Also, none of the servers in the pool > should be using leap-smearing (a requirement you mentioned). 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. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] can of worms: time-of-day in a community radio station
f...@cattaneo.us said: > Maybe I should double check the routing from both ends again and make sure > they are really symmetric.. I can also ask my coworkers in the networking > group and hear what they think about it. We need a cable TV geek. It wouldn't surprise me if the upstream traffic went through a couple of extra hoops/hops that aren't visible at the IP level using tools like ping and traceroute. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] Looking for Austron 2110 for parts
Hello Time-Nuts, Well, my trusty Austron 2110 has developed an intermittent that I am pretty sure is on the uP PCB (throws Illegal SWI3 Occurrence error). Anyone have a unit that is parts that they would like to get rid of? If so, please contact me off list. Yes, there is a uP PCB on eBay, but what I thought was a reasonable offer was rejected especially considering the $48.50 shipping to the U.S. Thanks in advance for any help or pointers. Regards, Skip Withrow ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] Used ESE ES-911/GPS/NTP Master Time Clock
I got in one of these... alas, the GPS module does not seem to work. It never locks to GPS. Alas, there is no status information to tell what is going on. These units only output a time code (in one of 4 different formats). All configuration is done via DIP switches. They do not output any satellite or other information. For what it's worth... Lady Heather can now read the time code information and use it to drive the clock display. I am going to try putting in a new GPS receiver. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] can of worms: time-of-day in a community radio station
I have been quite puzzled about the asymmetric nature of my home Cable Modem connection to the Internet in regard with the offset discrepancy I observe. The "last mile" asymmetric nature of Cable Modem (Comcast in my case) is not very high compared the delta I see between my stratum-1 servers at home and the nearest public stratum-1 NTP server. The upload/download discrepancy would be much less than 100 microseconds - as you point out in your calculation the worst is 33 microseconds for an upload speed of 12 Mbps, which is a drop in the bucket compared to other potential sources of jitter, switch queueing delays or asymmetric routing. The latter is not an issue in my case. I've used traceroute to check routing and I see that in both directions packets are routed between the two BGP ASes by the nearest (and most importantly, the same) peering point in Seattle. The public stratum-1 NTP server is at UW University in Seattle, and my home is in Bellevue, 10 miles from Seattle. All in all the latency from Comcast endpoint to UW University is approximately 3 millieconds, and latency from my home to Comcast endpoint is about 10 milliseconds. I've observed these latency numbers to be fairly constant throughout a few months of observations. This is a typical NTPQ output from one of my stratum-1 NTP servers at home: root@pendulum # ntpq -p remote refid st t when poll reach delay offset jitter == oGPS_NMEA(0) .GPS.0 l 13 16 3770.0000.014 0.000 ticktock.pengui .GPS.1 u4 64 3770.101 -0.016 0.012 clepsydra.pengu .GSYM. 1 u4 64 3770.1140.042 0.011 omega.s.uw.edu 172.22.16.38 2 u 43 64 377 19.8681.631 1.189 * local server (pendulum) is a FreeBSD pcengines x64 box which uses a BG7TBL GPSDO with PPS * ticktock is a FreeBSD pcengines x64 box which uses a Ublox-7 GPS receiver with PPS * clepsydra is a FeeBSD AMD x64 PC which uses a Symmetricom BCP635 timing board disciplined with a Ublox-7 GPS receiver with PPS * omega.s.uw.edu is Seattle's University of Washington public stratum-1 NTP server Currently I am observing a time offset of about 1.6 milliseconds, compared with a maximum time offset of 42 microseconds between the internal stratum-1 servers (I really need to measure the interrupt latency for PPS and adjust the offsets accordingly). I've taken pendulum stratum-1 server to my office in Seattle, and once there NTPQ reports an offset of about 100-200 microseconds with the public NTP server, which is a far more reasonable. Maybe I should double check the routing from both ends again and make sure they are really symmetric.. I can also ask my coworkers in the networking group and hear what they think about it. -- Fio (a time-nut who's very puzzled by this offset discrepancy) > > > Assume a NTP packet with all the protocol overhead is 100 bytes. That's 800 > bits. At 12 megabits/sec, that's 66 microseconds. Half of that is the worst > offset you can get and it would be lost in the noise from other sources. > > > There are 2 big ones. The first is queuing delays. The usual suspect the > last hop to your house. You have some control over that. But there are > queues out in the great big internet that you probably can't measure. > > The second is asymmetric routing. Your packets probably go out mostly on the > server's ISP and back mostly on your ISP. > > If you get caught in the crossfire of nation-state level cyber games, packets > between cities in the US may go via Iceland in one direction. > > -- Fio Cattaneo Universal AC, can Entropy be reversed? -- "THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER." On Sun, Oct 20, 2019 at 2:03 AM Hal Murray wrote: > > > Replies to several messages collected here to reduce traffic. > > > artgod...@gmail.com said: > > Off-the-wall thought : could you discipline a well-insulated raspberry pi > > to NTP using heaters or workload to modify its temperature ? > > Yes. > https://blog.ntpsec.org/2017/03/21/More_Heat.html > > The other approach is to measure the temperature and correct for it. > > NTP temperature compensation > Mark Martinec, 2001-01-08 > https://www.ijs.si/time/temp-compensation/ > > -- > > David J Taylor said: > > I suppose if you have a poor or overloaded internet connection server > > quality doesn't matter as much - well, almost. My ISP is 200/20, and used > > to be 200/12. Talk about asymmetric! > > Assume a NTP packet with all the protocol overhead is 100 bytes. That's 800 > bits. At 12 megabits/sec, that's 66 microseconds. Half of that is the worst > offset you can get and it would be lost in the noise from other sources. > > There are 2 big ones. The first is queuing delays. The usual suspect the > last hop to your house. You have some control over that. But there are > queues out in the great big
Re: [time-nuts] Authoritative Source for Lady Heather
Hello Mark. Thanks for that explanation. I GUESS my gobble-fu was working better than I have credit. I was not sure how closely connected your web site was to what is posted by texaspyro on EEBlog. I will continue to use your V6.14 source code, and eagerly await V6.30. Once I can fork from Github, I'll look into adding support for the shared memory service as can be configured in Linux/Raspbian GPSD and NTPD. I am hoping shared memory will be a lower noise source than a port repeater for serial port time data from a GPS. (I'd like to have both NTPD and LH listening to the same source.) R/ -Pat (KG5YPQ) On Sun, Oct 20, 2019, 12:05 AM Mark Sims wrote: > The two real sources are ke5fx.com and EEVBLOG > > ke5fx.com has the "official" fully blessed release. It is currently at > v5.0 This package has the nifty installer program. > > The EEVBLOG site ( > https://www.eevblog.com/forum/metrology/lady-heather-v6-beta-for-windows-exe/msg1434005/#msg1434005) > has the latest "beta" release. This version has support for several new > devices and several new features. It gets periodically updated. EEVBLOG > used to have a 1MB file limit so the source code was on tinyupload.com. > EEVBLOG has recently raised their limits to 5 MB, so everything can now go > there. I am planning on getting a new release (v6.30) out in a week or > two. > > I am also planning on getting Heather onto github. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] can of worms: time-of-day in a community radio station
Eric, As many others have mentioned, Meinberg has an excellent Windows port of NTPD that replaces the (horrible) default SNTP client. Linux & Mac should both have the standard NTPD distributions available. Since you mentioned internet outages (without mentioning frequency or duration), adding in your own local GPS based NTP server seems like a no-brainier. I'm sure you could find a place to mount a GPS antenna seeing as how it is a radio station, and there are countless inexpensive GPS modules to choose from that you could build your own NTP appliance, or connect to one (or more) of your existing servers and have them as some Stratum-1 time sources for the rest of each facility. As funding permits, you could upgrade to nicer GPSDO's for holdover. I would recommend having your "servers" at each location be the ones connected to GPS (if you decide to implement), and / or external NTP servers. Then each desktop / laptop / tablet / whatever all sync to your local servers (rather than have every device go out on the internet for time). In reference to using the NTP Pool, someone mentioned they don't trust them and the possibility of a "rogue" server. The NTP Pool has a monitor that is constantly querying every server in the pool, if the time drifts too far it is removed from the DNS rotation. Also, none of the servers in the pool should be using leap-smearing (a requirement you mentioned). Having 5-7 servers in your NTP configuration allows for one or two "falsetickers" to be rejected and still have enough good time sources to keep things humming along. While there are some public lists of S1 & S2 servers, it can take a little experimenting to find which ones really work best for each of your locations. Cloudflare recently launched a public time service, you can read more about it here: https://www.cloudflare.com/time/ and I've also found that Apple ( time.apple.com ) also utilizes their CDN network for delivering the closest NTP servers. From what I have read, neither of those services use leap-smearing either. Finally, your ISP too probably has their own NTP servers too that you may or may not know about. Jason ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] Thank you Didier
Thank you Didier. Some of us are serious time nuts that means our measurements exceed 24 hours. When GPS is involved 48 hours is a minimum. Unless you have a Cs fountain sooner or later you go back to GPS. Between Juerg and me we have at any time 4 PC based computers running. Some tests go over weeks. Fan noise and power failure are only a few concerns.And along comes FA2 having two HP53132 no more concern about fan and display failure. That is why both of us immediately bought one and did extensive testing. Recommended to a few others off list Key part in our tool chest.A tablet makes it even better, plan on powering the tablet from the FA2. It is definitely not about money opens new opportunities and gets other time nuts involvedBert Kehren ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Flash!!! FA2 works on Aderino Tablets !!!
Didier, This looks very useful. Is there a specific DB9 to USB-C cable that you would recommend, or would you use a USB-A (female) to USB-C adapter with a standatrd USB-A to DB9 cable? On Sat, Oct 19, 2019 at 10:04 PM Didier Juges wrote: > To be more specific, the app is a serial data logger which can collect and > save ASCII data, not specifically for the FA2 (I tried it with a GPS > receiver collecting NMEA). > It works with a USB-Serial chip like the FTDI, Prolific, Silabs, it may > even work with the CH340, via the USB connector of an Android phone or > tablet. > > > -- --Jim Harman ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] can of worms: time-of-day in a community radio station
Replies to several messages collected here to reduce traffic. artgod...@gmail.com said: > Off-the-wall thought : could you discipline a well-insulated raspberry pi > to NTP using heaters or workload to modify its temperature ? Yes. https://blog.ntpsec.org/2017/03/21/More_Heat.html The other approach is to measure the temperature and correct for it. NTP temperature compensation Mark Martinec, 2001-01-08 https://www.ijs.si/time/temp-compensation/ -- David J Taylor said: > I suppose if you have a poor or overloaded internet connection server > quality doesn't matter as much - well, almost. My ISP is 200/20, and used > to be 200/12. Talk about asymmetric! Assume a NTP packet with all the protocol overhead is 100 bytes. That's 800 bits. At 12 megabits/sec, that's 66 microseconds. Half of that is the worst offset you can get and it would be lost in the noise from other sources. There are 2 big ones. The first is queuing delays. The usual suspect the last hop to your house. You have some control over that. But there are queues out in the great big internet that you probably can't measure. The second is asymmetric routing. Your packets probably go out mostly on the server's ISP and back mostly on your ISP. If you get caught in the crossfire of nation-state level cyber games, packets between cities in the US may go via Iceland in one direction. kb...@n1k.org said: > At some odd hour of the day, one day a week, the tech geek fires up WWVB and > pipes it into an audio trunk. He / she then wanders around with a set of > headphones. Each clock in the station gets set to âthe right timeâ. Any > clock > that is out by more than some defined amount gets flagged for repair. What was the ballpark for "defined amount"? Any guess on how far a typical clock drifted in a week? > In some places, the clocks that got the set process had tags on them that > told you to use them for the correct time. Indeed even so, people still > would look at their wrist watch â¦.. 40ish years ago, the time servers on the Xerox internal network were mostly set from my watch. I don't remember doing anything fancy to set it. I probably used POP-CORN. We did have crude drift correction. I think the units were seconds per day, probably an integer. I remember an interesting improvement in Alto timekeeping. Ed Taft got annoyed at how poorly they kept time. He tracked it down to the handoff between designers, builders, and programmers. The Alto was designed with a 170 ns cycle time. Crystals are ordered by MHz rather than ns. The crystals said 5.88 MHz. That's off by 400 ppm. A magic constant deep within the OS was tweaked and things got much better. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
