I fear that I am developing a reputation for bringing to the list rather

Questions for you are at the end. Thanks for your thoughts,.

Hi David, I don't particularly trust NTP servers from pool.ntp.org (I assume that is what you mean by "pool"), and I use public stratum-1 servers chosen from a public list. Of course I make sure that my usage complies with the policies and terms of use for each server (some allow regional use only, some say do avoid using iburst keyword, some require prior permission and/or notification). I have found that using 3 to 5 public stratum-1 servers works very well, and gives a time synchronization which is within 3 to 5 milliseconds when compared with a reference timing board with GPSDO. This time offset discrepancy is actually due to the fact that my ISP (comcast cable) has asymmetric send/receive delays. It disappears when I tried this setup at my office, which has symmetrical fiber optic connection to internet. Your point about avoiding having all the internal machine hit stratum-1 servers is a good one however. To avoid that in my setup I designate 3 machines which serve as an internal stratum-2 pool for internal distribution. Each of them has 3 to 5 external NTP stratum-1 servers and they all peer with each other. Then every other internal machine uses these 3 machines. I have more details on my setup in my reply to Eric. Kind regards, -- Fio Cattaneo Universal AC, can Entropy be reversed? -- "THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER." On Fri, Oct 18, 2019 at 11:08 PM David J Taylor via time-nuts <time-nuts@lists.febo.com> wrote: > > I fear that I am developing a reputation for bringing to the list rather > oddball questions. In my rôle as agent provocateur, therefore, here is > another such problem. > > Questions for you are at the end. Thanks for your thoughts,. > > — Eric > [] > =============================================== > > Eric, > > As others have mentioned, using the reference NTP should do the job with > margin to spare! > > - Windows, use the Meinberg port. I have some info here: > https://www.satsignal.eu/ntp/setup.html > > - Linux, NTP is usually installed by default, although it may be a release > or two behind. Usually this isn't important. Use "ntpq -pn" to see whether > you have it. > > - MAC, reference NTP is available (I believe), but you might need to compile > it. > > - For your one stratum-1 server you can use a GPS source would with a > Raspberry Pi, or even a Windows PC although that won't be quite as good, but > adequate for 0.01 seconds accuracy. Some notes here: > https://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html > > - For a wall-clock from the Raspberry Pi: > https://www.satsignal.eu/raspberry-pi/DigitalClock.html > I should really recompile this so that the RPi doesn't have to be rebooted > when the clocks change, but the compiler/software I used > (Lazarus/FreePascal) didn't have the required API call at the time. > > - using the pool servers for a few PCs is OK, I think, as all the PCs won't > be hitting the same pool servers. How many is "a few" - perhaps 20? Don't > use "stratum-1" public servers (e.g. time.nist.gov), as they are likely to > be overloaded and therefore not as accurate as you might expect. Using the > "pool" command in NTP and pool servers is likely to be just as good, if not > better. > > I hope that gives you a little more food for thought. > > Cheers, > David > -- > SatSignal Software - Quality software for you > Web: http://www.satsignal.eu > Email: david-taylor@blueyonder.co.uk > Twitter: @gm8arv > > > _______________________________________________ > 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.

Hi David, I don't particularly trust NTP servers from pool.ntp.org (I assume that is what you mean by "pool"), and I use public stratum-1 servers chosen from a public list. Of course I make sure that my usage complies with the policies and terms of use for each server (some allow regional use only, some say do avoid using iburst keyword, some require prior permission and/or notification). I have found that using 3 to 5 public stratum-1 servers works very well, and gives a time synchronization which is within 3 to 5 milliseconds when compared with a reference timing board with GPSDO. This time offset discrepancy is actually due to the fact that my ISP (comcast cable) has asymmetric send/receive delays. It disappears when I tried this setup at my office, which has symmetrical fiber optic connection to internet. Your point about avoiding having all the internal machine hit stratum-1 servers is a good one however. To avoid that in my setup I designate 3 machines which serve as an internal stratum-2 pool for internal distribution. Each of them has 3 to 5 external NTP stratum-1 servers and they all peer with each other. Then every other internal machine uses these 3 machines. I have more details on my setup in my reply to Eric. Kind regards, -- Fio Cattaneo ===================================== Fio, I'm surprised you don't trust "pool" servers. My experience is that using the pool directive, and allowing NTP to expand its server list automatically to the maximum number of servers, gives good results usually with one of two servers at least being stratum-1 GPS-locked. That's using UK and NL servers. 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! If you have a PPS feed from that GPS board, you could easily add it to a Linux PC (Raspberry Pi, for example) or even a Windows box and use that locally as your own stratum-1 server. I never had much success with peering - it seemed that when one server had a higher offset for whatever reason it dragged the other with it. I use multiple independent stratum-1 servers - one a Linux X86, one a Raspberry Pi, and one LeoNTP box. Cheers, David -- SatSignal Software - Quality software for you Web: http://www.satsignal.eu Email: david-taylor@blueyonder.co.uk Twitter: @gm8arv

Hi There is the “good old way” to keep the station clocks running right in a non-profit radio station: 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. Been there / done that ….. 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 ….. Bob > On Oct 18, 2019, at 7:38 PM, paul swed <paulswedb@gmail.com> wrote: > > Have no idea if they exist still but what you need is time of day clocks > and what are called shot clocks. A shot clock is a clock thats preloaded > with a segment duration and counts to zero. No thinking is the key. These > have been used for years and years. > That makes talents job very very easy.It also is up to them to get on time. > Most are good at that actually. > With respect to network feeds they simply do very generally towards late. > But they rubber band from my experience. > Regards > Paul > > > On Fri, Oct 18, 2019 at 6:02 PM Bob kb8tq <kb8tq@n1k.org> wrote: > >> Hi >> >> A very normal internet based NTP setup will do what you wish to do. The >> main task is to make >> sure that your devices are *really* running NTP and not some odd thing >> built into their OS. The >> more devices / operating systems / OS versions / system configurations you >> have the more >> exciting this gets. >> >> Bob >> >>> On Oct 18, 2019, at 3:20 PM, Eric Scace <eric@scace.org> wrote: >>> >>> I fear that I am developing a reputation for bringing to the list >> rather oddball questions. In my rôle as agent provocateur, therefore, here >> is another such problem. >>> >>> Questions for you are at the end. Thanks for your thoughts,. >>> >>> — Eric >>> >>> Issue: >>> A community broadcast radio station with multiple studio locations >> wishes to improve the display of time-of-day throughout the station’s >> operating environments. Its current legacy approaches (described below) >> cause problems such as: >>> on-air presenters fail to smoothly segue into scheduled program feeds >> (e.g., BBC news) because the studio clock is “a little off”… and because >> the studio clock is digital. [Quick: how many more seconds can you speak >> before the top of the hour when a digital clock shows 4:59:42? Watching an >> analog stepping second hand is much easier in this situation.] >>> computers that automatically capture audio programs to files in storage >> sometimes truncate the start or end of the program because the computer’s >> idea of time-of-day disagrees with that of the program source. >>> desktop computers throughout the station, including in production >> studios, all render slightly different versions of time-of-day to their >> users. >>> servers (e.g, for streaming, for archiving shows) are similarly in >> cheerful disagreement as to time of day. >>> wall clocks studios in one city show a different time to their engineers >> than the studios in another city, rendering handoffs more complicated. >> Ditto for remote broadcast sites, and even between studios in the same site. >>> requires manual intervention to bring the most egregious systems back to >> some semblance of reality >>> >>> Background & existing situation: >>> Commercial broadcast stations have more money and technology to solve >> these problems. In contrast, “community radio” stations have limited funds >> and are largely staffed by volunteers (like me!). >>> >>> In this case, the existing systems are a hodgepodge: >>> mostly Windows OS PCs, with a couple of Macs >>> Linux servers >>> mash-mash of wall clocks, the best of which is a LaCrosse WWVB digital >> in the primary on-air studio. The WWVB signal is more than adequate but the >> LaCross display format is sub-optimal for studio use. >>> >>> Goals: (first pass) >>> minimum accuracy requirement: time-of-day displayed within ±0.1 second >> of UTC timescale. (Two clocks both falling outside this range will cause >> program handoffs to be uncomfortably tight or loose.) >>> no manual intervention required for summer/winter time transitions >>> no manual intervention required for leap seconds >>> leap second: >>> no smearing (minimum requirement) >>> accurate leap second display (desirable but unlikely to be achievable) >>> desirable consistency goal: time-of-day displayed within ±0.025 second >> throughout each site. At this level, two adjacent clock displays will not >> be perceived as out of step by a person. >>> presentation goals: studio/remote broadcast control point time-of-day >> displayed in both analog (with stepped seconds hands) and digital form >> (preferred H:MM). >>> If digital form includes seconds, the seconds digits should be visually >> separated; e.g..smaller. A presenter can then, at a glance and without >> confusion, announce the time (“four twenty-three”) from the digital display. >>> Date in form “Oct 17 Thu” available. >>> medium-term desirable: displays continue within specs for >> accuracy/consistency across power cutovers (to/from generator) and public >> Internet outages. >>> maintenance goals: >>> "eschew emergencies”: no one should have to rush to the station in the >> middle of the night, nor drop what their doing during the day, because >> time-of-day display has failed or gone out-of-spec. >>> standardize on the same hardware/software everywhere >>> identical hardware allows more cost-effective 1:N sparing >>> identical hardware/software means less confusion and less training for >> volunteers. (There are a large number of volunteers who use these systems, >> and most contribute time less than once per week. Consistency and >> straightforwardness in the toolkit improves the quality of on-air results.) >>> not too costly >>> try to avoid stringing a lot of new cabling around… but such cabling >> needs are recognized as a one-time investment, so this preference does not >> eliminate a cable-based solution that has other operational/maintenance >> advantages >>> >>> Potential approaches: >>> potential short-term: >>> desktops and servers: better NTP configuration >>> NTP checks: >>> at least hourly? >>> verify NTP utility employs reasonable averaging of multiple NTP servers >>> use time.nist.gov <http://time.nist.gov/> and similar higher-quality >> NTP servers >>> some systems are on in-house Ethernet; others on in-house wi-fi >>> clocks: >>> replace with refurb iPads running a dedicated time-of-day display app >> providing both analog and digital form. A refurb wall- or desk-mounted 13” >> iPad in locking frame runs about $100. Smaller sizes can be mounted >> immediately adjacent to or atop a studio mixing board. >>> remote field broadcast site: iPad over local wi-fi or cellular data? >>> IRIG displays could be awesome, but seem far more costly per display and >> require pulling coax — and integrated analog + digital displays appear to >> be less common. Two displays (one analog, the other digital) in each studio >> provide some redundancy but costs go up fast. >>> NTP-clocks powered over ethernet could similarly be awesome, but are >> similarly more costly and few integrated analog + digital displays exist. >>> medium term: >>> add in-house NTP server (with GPS and reasonable holdover plus battery >> backup) on each city’s on-site LAN/wi-fi networks as primary source, with >> remote public NTP servers as secondary. Many suitable models appear to >> exist, including the ESE E-911 units mentioned recently. Only a few are >> needed: one for each site plus sparing. >>> potentially increase the frequency of NTP synchronization for each >> computer/display clock when a local NTP server has been installed. >>> >>> Questions: >>> Are there other approaches that should be considered? >>> What NTP software should be used on Windows OS machines? Linux servers? >>> Mac OS allows one choice of NTP server but does not seem to provide for >> choice of NTP update frequency. Is there a 3rd party software solution, or >> some other parameter within MacOS that an admin can change to (a) establish >> a primary and secondary NTP server, and (b) set the frequency of NTP >> updates? >>> If one were to use an iPad to display time-of-day, what iPad apps >> provide the needed display formats, frequency of NTP checks, >> primary/secondary NTP sources? >>> For example, Atomic Clock Gorgy updates hourly and allows the user to >> choose one NTP server group (e.g., time.nist.gov <http://time.nist.gov/>). >> It has an analog seconds display format (circle of dots), digital H:MM >> (optional :SS), and MMM D DDD — although one could quibble over the >> typography. However, the display shows “SYNC” for a couple of seconds each >> hour while the NTP update occurs, which would be disconcerting if it >> happens when a presenter/engineer is in the midst of joining/cutting away >> from external program sources. >>> What have we overlooked? >>> >>> _______________________________________________ >>> 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 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.

Take a look at vClock https://voceware.co.uk/products-vclock.aspx You could run on a surplus PC with a reliable NTP client. I like Tardis as I can set the servers that it queries and set limits to the amount of correction it applies so that it can compensate for PC RTC drift without the risk that it will make a major adjustment in error. Philip -----Original Message----- From: time-nuts [mailto:time-nuts-bounces@lists.febo.com] On Behalf Of Eric Scace Sent: Friday, October 18, 2019 4:33 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] can of worms: time-of-day in a community radio station Sadly the formatting of the original message was stripped by the email server. Here is a slightly more comprehensible version. On 2019 Oct 18, at 15:20 , Eric Scace <eric@scace.org> wrote: I fear that I am developing a reputation for bringing to the list rather oddball questions. In my rôle as agent provocateur, therefore, here is another such problem.

"Of course this is why I am a time-nut :-)" I might say you graduated from the Advanced class with honors :) Didier KO4BB

 I fear that I am developing a reputation for bringing to the list rather oddball questions. In my rôle as agent provocateur, therefore, here is another such problem.

 Questions for you are at the end. Thanks for your thoughts,.

On 10/18/19 12:20 PM, Eric Scace wrote: > I fear that I am developing a reputation for bringing to the list rather oddball questions. In my rôle as agent provocateur, therefore, here is another such problem. > > Questions for you are at the end. Thanks for your thoughts,. > > — Eric > I think that one aspect is more the "display" than the mechanism/implementation behind it. Digital displays are terrible for this, you really want an analog display with the sweep second hand. If you're reading copy to prep, and waiting for the cue, it's hard to switch between reading copy and read digital display - the analog second hand is a great indication of "how long til I'm live" So, one thing that you might want to do is figure out an inexpensive, easily duplicated, not depending on surplus, way to get that "analog wall clock". It seems that you should be able to get a LCD display (doesn't have to be high res), hook it up to a RPi or something commodity, and find software that displays a round wall clock, and syncs to NTP. If you can find software that integrates cue-ing with the wall clock so much the better - all the radio stations I've ever been at run their operations on a fairly repetitive schedule -for instance, PBS stations do station ID at the top, national news, local news, then network feed, with well defined outserts and inserts. Back in the day (i.e. more than 20 years ago) I saw an analog clock that had LEDs around the dial that showed the *minute* when the various cues were, and the "next cue" would blink. It was up to the talent and the engineer to hit the mark with respect to the second hand crossing 12.

Hello David, >>> I'm surprised you don't trust "pool" servers. My experience is that using >>> the pool directive, and allowing NTP to expand its server list automatically >>> to the maximum number of servers, gives good results usually with one of two >>> servers at least being stratum-1 GPS-locked. The main reason I do not trust "pool" servers is because there is no guarantee of which server you will get. I might be paranoid, but I am worried about rogue servers, and I much rather trust well known public stratum-1 NTP servers. So mainly a matter of trust. As far as their quality, I've actually never really seen public stratum-1 servers being overloaded. A good number of them are actually a group of servers and clients round-robin among all of them. For instance if I lookup the DNS records of the stratum-1 NTP severe closer to me (University of Washington, Seattle), I see it is actually 3 servers: fcattane@linux-mint-64:~$ dig bigben.cac.washington.edu ;; ANSWER SECTION: bigben.cac.washington.edu. 5 IN CNAME time.u.washington.edu. time.u.washington.edu. 4 IN A 140.142.234.133 time.u.washington.edu. 4 IN A 140.142.1.8 time.u.washington.edu. 4 IN A 140.142.2.8 >>> If you have a PPS feed from that GPS board, you could easily add it to a >>> Linux PC (Raspberry Pi, for example) or even a Windows box and use that >>> locally as your own stratum-1 server. Yes, all three stratum-1 servers I run at home all have a PPS output from GPS (either vanilla GPS receiver or GPSDO) which I feed to NTPD via serial port DCD input. >>> I never had much success with >>> peering - it seemed that when one server had a higher offset for whatever >>> reason it dragged the other with it. I use multiple independent stratum-1 >>> servers - one a Linux X86, one a Raspberry Pi, and one LeoNTP box. That's interesting you had experience with peering. My own experience with it was pretty good, but in my case I did the work to set up internal time sync for the cloud computing megacorp I worked for, and thus I had the luxury of choosing among several hundred servers and I picked the ones which had the lowest PPM drift. I wonder if NTPD's peering algorithm runs into trouble if the clock jitter between machines is too high -- hard to say without doing more experimenting. My experience with peering was good but only lasted about 6 months, as few months later we actually bought some Symmetricom stratum-1 boxes to avoid external dependencies and certify NIST traceability. The obvious advantage of peering is that if you don't have your own stratum-1 sources you can continue to serve time even if the internet connection goes down. Of course these days it's so incredibly cheap -- not to mention fun -- to build your own stratum-1 server with cheap GPS receiver with PPS output using either a Rasperry PI, a cheap old X86 PC, or (as I do for 2 of my servers) a pcengines box. Luckily both of us went down this route for our own NTPD servers :-) Cheers ! -- Fio Cattaneo Universal AC, can Entropy be reversed? -- "THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER." On Sat, Oct 19, 2019 at 9:04 AM David J Taylor via time-nuts <time-nuts@lists.febo.com> wrote: > > Hi David, I don't particularly trust NTP servers from pool.ntp.org (I > assume that is what you mean by "pool"), and I use public stratum-1 > servers chosen from a public list. Of course I make sure that my usage > complies with the policies and terms of use for each server (some > allow regional use only, some say do avoid using iburst keyword, some > require prior permission and/or notification). > I have found that using 3 to 5 public stratum-1 servers works very > well, and gives a time synchronization which is within 3 to 5 > milliseconds when compared with a reference timing board with GPSDO. > This time offset discrepancy is actually due to the fact that my ISP > (comcast cable) has asymmetric send/receive delays. It disappears when > I tried this setup at my office, which has symmetrical fiber optic > connection to internet. > > Your point about avoiding having all the internal machine hit > stratum-1 servers is a good one however. To avoid that in my setup I > designate 3 machines which serve as an internal stratum-2 pool for > internal distribution. Each of them has 3 to 5 external NTP stratum-1 > servers and they all peer with each other. Then every other internal > machine uses these 3 machines. I have more details on my setup in my > reply to Eric. > > Kind regards, > > -- Fio Cattaneo > ===================================== > > Fio, > > I'm surprised you don't trust "pool" servers. My experience is that using > the pool directive, and allowing NTP to expand its server list automatically > to the maximum number of servers, gives good results usually with one of two > servers at least being stratum-1 GPS-locked. That's using UK and NL > servers. 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! > > If you have a PPS feed from that GPS board, you could easily add it to a > Linux PC (Raspberry Pi, for example) or even a Windows box and use that > locally as your own stratum-1 server. I never had much success with > peering - it seemed that when one server had a higher offset for whatever > reason it dragged the other with it. I use multiple independent stratum-1 > servers - one a Linux X86, one a Raspberry Pi, and one LeoNTP box. > > Cheers, > David > -- > SatSignal Software - Quality software for you > Web: http://www.satsignal.eu > Email: david-taylor@blueyonder.co.uk > Twitter: @gm8arv > > > _______________________________________________ > 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.

Regarding analog clocks, what is the groups opinion on these Atomic WWVB Signal Radio Controlled Clock Movements? I ordered one from China but it isn't here yet. I am hoping that I won't have to change the clock for DST. They are only $15. https://www.klockit.com https://www.amazon.com/dp/B07XWTMZZD/ref=cm_sw_r_tw_dp_U_x_VJARDbHBEE15J https://www.aliexpress.com/item/33005680618.html -- Myron

		Attila Kinali

On Sat, 19 Oct 2019 18:24:57 -0700 Fiorenzo Cattaneo <fio@cattaneo.us> wrote: > The main reason I do not trust "pool" servers is because there is no > guarantee of which server you will get. I might be paranoid, but I am > worried about rogue servers, and I much rather trust well known public > stratum-1 NTP servers. This is a pretty baseless fear. The servers in the ntp pool are constantly monitored and those that are off by more than 100ms are quickly removed (within 2-3 hours, IIRC). Of course, if you are already using one of those, then the removal will not help you. But you are most likely using 3-5 servers anyways, which means ntp will remove the "rouge" server on its own. Attila Kinali -- <JaberWorky> The bad part of Zurich is where the degenerates throw DARK chocolate at you.

                     Attila Kinali

> This is a pretty baseless fear. The servers in the ntp pool > are constantly monitored and those that are off by more than 100ms > are quickly removed (within 2-3 hours, IIRC). In computer security it's a big no-no to use unknown or untrusted sources of information, as simple as that. A random source of information is both untrusted and unknown. You would never see a data center using ntp pool servers, or at least I haven't see any. Back in the days we actually set up agreements with selected NTP sources to give us authenticated NTP traffic. Of course the key management tends to be a substantial amount of overhead, so in every data center where we actually had access to the sky we installed stratum-1 gps rubidium servers and called it a day. Then of course there is also the argument as to whether the monitoring code is robust enough, and whether it uses a known trusted authority for time, or at least one which is not easily spoofed or hacked. -- Fio Cattaneo Universal AC, can Entropy be reversed? -- "THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER." On Sun, Nov 3, 2019 at 8:00 AM Attila Kinali <attila@kinali.ch> wrote: > > On Sat, 19 Oct 2019 18:24:57 -0700 > Fiorenzo Cattaneo <fio@cattaneo.us> wrote: > > > The main reason I do not trust "pool" servers is because there is no > > guarantee of which server you will get. I might be paranoid, but I am > > worried about rogue servers, and I much rather trust well known public > > stratum-1 NTP servers. > > This is a pretty baseless fear. The servers in the ntp pool > are constantly monitored and those that are off by more than 100ms > are quickly removed (within 2-3 hours, IIRC). Of course, if you > are already using one of those, then the removal will not help you. > But you are most likely using 3-5 servers anyways, which means ntp > will remove the "rouge" server on its own. > > Attila Kinali > > -- > <JaberWorky> The bad part of Zurich is where the degenerates > throw DARK chocolate at you. > > _______________________________________________ > 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.