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

[Hal Murray]

stevesommars...@gmail.com said:
> If the bad guys can intercept NTP traffic timestamps can be altered, unless
> NTP authentication is used.  [This rarely happens.] 

For those not familiar with this area...

There are 2 ways to authenticate NTP packets.

You can setup a shared key.  This requires getting the key from one site to 
the other via some out-of-band method.  The main disadvantage of this approach 
is that it requires manual interventation at the server end to enter the new 
key.  That doesn't scale.

NIST offers this.  They send you the key via snail mail.



There is a new approach: NTS, Network Time Security.  The RFC isn't final yet, 
but I don't expect significant changes.  There is running code.
  https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

The basic idea is that the client uses TCP to setup a TLS connection to a 
NTS-KE (key exchange) server.  The client gets client-server keys and cookies. 
 There is a pair of keys for each client-server.  There is no per-client state 
on the server.  Each cookie contains the keys encrypted with a cookie-key 
known only to the server.

The client sends a cookie with each request, authenticating with a key.  The 
server decrypts the cookie to get the authentication key for this client, then 
uses that key to authenticate the request  ...  and sends back a new cookie 
with the NTP response.

Cloudflare and Netnod have announced public servers.
  https://developers.cloudflare.com/time-services/nts/usage/
  https://www.netnod.se/time-and-frequency/netnod-launch-one-of-the-first-nts-e
nabled-time-services-in-the-world


-- 
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

[Fiorenzo Cattaneo]

> 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  wrote:
>
> On Sat, 19 Oct 2019 18:24:57 -0700
> Fiorenzo Cattaneo  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
>
> --
> 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.

___
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

[Steven Sommars]

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 paper
 discusses such
NTP time transfer issues (thanks Tom).
A diverse set of servers may be desirable:  Using eleven stratum 2 servers
with common stratum 1 sources may not meet your requirements.
If the bad guys can intercept NTP traffic timestamps can be altered, unless
NTP authentication is used.  [This rarely happens.]





On Mon, Nov 4, 2019 at 2:51 PM Bob kb8tq  wrote:

> Hi
>
> Since “rogue” servers are rare, bumping up the number of servers fairly
> quickly
> gets you to a very high degree of confidence. Is that 5, 7, 9, or 11? It
> sounds like
> a wonderful topic for somebody’s thesis or dissertation :)  Given that
> this is a free
> resource and that the network usage is negligible even with a dozen
> servers, the only
> real downside is being tagged as a resource hog.
>
> Bob
>
> > On Nov 4, 2019, at 7:05 AM, Hal Murray  wrote:
> >
> >
> > att...@kinali.ch said:
> >> 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.
> >
> > It's more complicated than that.
> >
> > It depends on what code you are using and how you configured things.
> >
> > If you are using  ntpd and you said in your ntp.conf
> >  server 
> > Then it grabs one and sticks with it until you restart ntpd.
> >
> > In the old days, it was common to use
> >  server 0.pool
> >  server 1.pool
> >  server 2.pool
> >  server 3.pool
> > That used the pool before the pool code in ntpd was working.  I'm pretty
> sure
> > some distros set things up that way and some systems are probably still
> using
> > an old config file.
> >
> > The pool code is supposed to drop bad servers and get replacements.  I'm
> not
> > sure of the details on what "bad" covers.  It could be not responding at
> all
> > or it could be time not good-enough.  I'll dig into the code if it
> matters.
> >
> >
> > If you aren't running ntpd (classic or ntpsec) then I don't know what
> happens.
> >
> >
> > --
> > 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 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

[Bob kb8tq]

Hi

Since “rogue” servers are rare, bumping up the number of servers fairly quickly
gets you to a very high degree of confidence. Is that 5, 7, 9, or 11? It sounds 
like
a wonderful topic for somebody’s thesis or dissertation :)  Given that this is 
a free
resource and that the network usage is negligible even with a dozen servers, 
the only
real downside is being tagged as a resource hog.

Bob

> On Nov 4, 2019, at 7:05 AM, Hal Murray  wrote:
> 
> 
> att...@kinali.ch said:
>> 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. 
> 
> It's more complicated than that.
> 
> It depends on what code you are using and how you configured things.
> 
> If you are using  ntpd and you said in your ntp.conf
>  server 
> Then it grabs one and sticks with it until you restart ntpd.
> 
> In the old days, it was common to use
>  server 0.pool
>  server 1.pool
>  server 2.pool
>  server 3.pool
> That used the pool before the pool code in ntpd was working.  I'm pretty sure 
> some distros set things up that way and some systems are probably still using 
> an old config file.
> 
> The pool code is supposed to drop bad servers and get replacements.  I'm not 
> sure of the details on what "bad" covers.  It could be not responding at all 
> or it could be time not good-enough.  I'll dig into the code if it matters.
> 
> 
> If you aren't running ntpd (classic or ntpsec) then I don't know what happens.
> 
> 
> -- 
> 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

[Hal Murray]

att...@kinali.ch said:
> 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. 

It's more complicated than that.

It depends on what code you are using and how you configured things.

If you are using  ntpd and you said in your ntp.conf
  server 
Then it grabs one and sticks with it until you restart ntpd.

In the old days, it was common to use
  server 0.pool
  server 1.pool
  server 2.pool
  server 3.pool
That used the pool before the pool code in ntpd was working.  I'm pretty sure 
some distros set things up that way and some systems are probably still using 
an old config file.

The pool code is supposed to drop bad servers and get replacements.  I'm not 
sure of the details on what "bad" covers.  It could be not responding at all 
or it could be time not good-enough.  I'll dig into the code if it matters.


If you aren't running ntpd (classic or ntpsec) then I don't know what happens.


-- 
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

[Attila Kinali]

On Sat, 19 Oct 2019 18:24:57 -0700
Fiorenzo Cattaneo  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

-- 
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.

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

[Fiorenzo Cattaneo]

Achim, thank you for your graph and for the link to Dan Drown blog and
your suggestions. I am going to collect data and replicate his
research. I doubt I'll discover anything new, but it's interesting
nevertheless to look into these time series data.


-- Fio Cattaneo

Universal AC, can Entropy be reversed? -- "THERE IS AS YET
INSUFFICIENT DATA FOR A MEANINGFUL ANSWER."

On Mon, Oct 21, 2019 at 12:06 PM Achim Gratz  wrote:
>
> Fiorenzo Cattaneo writes:
> > 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.
>
> The asymmetry from different bandwifth up-/downstream is only a small
> part of the effective up-/downstream difference.  Dan Drown has measured
> that:
>
> https://blog.dan.drown.org/tag/asymmetric-latency/
>
> I would think the jitter distributions are skewed as well, so some of
> that gets finally interpreted as an offset.  If you can trust the clocks
> on either end of the connection to be accurate, then you can set the
> offset to zero and solve for the asymmetry instead of the usual
> assumption of zero asymmetry to solve for the offset.
>
> Plotting the offset against the RTT like Dan does is instructive, but
> you won't always get such nice graphs.  I've attached a plot of how one
> of my stratum-1 has seen the three PTB servers through my DSL connection
> during the last three months.
>
>
> So while the connection is stable you can sort of remove the extra
> offset that comes from a changing RTT, but at any one time you might
> jump to one other set of correlation lines and get that "correction"
> wrong.
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> Factory and User Sound Singles for Waldorf Blofeld:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
> ___
> 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

[Hal Murray]

> My understanding is that it would work moderately well even without a
> stratum-1 server, at least be able to operate within a few tens of
> milliseconds for several hours. Although I confess I haven't used peering in
> a very long time. In my workplace we added stratum-1 GPS symmetricom NTP
> servers about 6 months after the above mentioned setup.

Suppose you start with 2 stratum 2 servers connected to different stratum 1 
servers on the internet and also to each other.

Suppose one of the stratum 1 servers goes down.  After 8 poll intervals with 
no response, your server using it will switch to using your other local 
server.  That puts it at stratum 3.

Suppose it was the link that went down rather than the server.  (It was a race 
as to which of your servers timed out first.)  Soon your second server gives 
up and switches to using your first server.  The first server is now stratum 
3, so the second server becomes stratum 4.  Then the first server becomes 
stratum 5 and the second becomes 6 ...  After a few more iterations, one gets 
to stratum 16 which is a no-data.  The other soon times out.

If you have evidence that something better happens, please clue me in.

You can keep going with either a localclock or orphan mode.  If you do that, 
you are running what GPSDOs call holdover.  It works well enough for a while.  
How long is a lot of it-depends.


> My apologies, I just did a quick googling because I was on the phone and
> didn't have access to my desktop bookmarks. This is the list I normally use

> http://support.ntp.org/bin/view/Servers/StratumOneTimeServers 

That list is better than most.  I would still treat it with a  reasonable 
amount of caution.  Scan the column of last-modified dates.

Don't get hung up on stratum 1.  A stratum 2 right next to a stratum 1 can 
keep time well enough so that you will have a hard time telling the difference 
over a network connection.

Cloudflare offers  non-smearing public servers.
  https://blog.cloudflare.com/secure-time/

--

For "interesting" reading, check out the Wikipedia page on NTP abuse.
  NTP server misuse and abuse
  https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse

I think Dave Plonka's writeup of the U Wisc event should be required reading 
for any computer science program.  (It's in the References section of the wiki 
page.)




-- 
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

[Fiorenzo Cattaneo]

>
> > With this setup you have no single point of failure, and even if the
> > connection to internet fails, they can still provide time as they are 
> > peering
> > and synchronizing with each other.
> No, it doesn't work that way.  You need connectivity to at least one stratum 1
> server.
> There is an option to elect one, orphan mode, if you get disconnected from the
> net.  That keeps all the local clocks close together.  They will all drift
> along with the chosen leader.

My understanding is that it would work moderately well even without a
stratum-1 server, at least be able to operate within a few tens of
milliseconds for several hours. Although I confess I haven't used
peering in a very long time. In my workplace we added stratum-1 GPS
symmetricom NTP servers about 6 months after the above mentioned
setup.

>
>
> > You can use this list to pick stratum 1 servers:
> >   http://www.advtimesync.com/docs/manual/
> > stratum1.html
>
> There is no date on that list.  At a quick glance, a few systems I'm familiar
> with are way out of date.  I wouldn't trust any of the details.  Same for
> other lists of stratum 1 servers.  They might be a good starting point.  In
> particular, many servers that say "open access" on lists like that have
> changed their rules, often going off the air.

My apologies, I just did a quick googling because I was on the phone
and didn't have access to my desktop bookmarks. This is the list I
normally use

http://support.ntp.org/bin/view/Servers/StratumOneTimeServers


>
>
> > server time.nist.gov
>
> That's a bad example.  NIST has servers at several locations.  That name
> rotates across them.  You might get a good one, or you might get one on the
> other side of the country.  If it works well today, it may not after you
> reboot and pick a different server.
>   https://tf.nist.gov/tf-cgi/servers.cgi

100% agree on this.. DNS roundrobin is good enough for 10s of
milliseconds, but for best results you should always pick nearby
servers. The worst thing of DNS round robin is that it gives
unpredictable results.

>
>
> > just a cheap GPS receiver (serial is best, but USB should be OK
>
> There are 3 levels of GPS receiver.  GPSDO is best.  GPS with PPS is second - 
> serial prefered, but USB works.  Low cost GPS (without PPS) on USB is last.
>
> USB is polled -- no interrupts.  That adds a millisecond of jitter.  That's 
> probably not an issue if your goal is 100 ms.  (If you are a geek, be sure 
> you understand hanging bridges.)
>
> The timing on the serial port from low cost GPS receivers is often crappy.  
> This is a horrible example:
>   http://users.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif
> Anyway, you need to check the device you select.  (Or get suggestions from 
> people who are using them for NTP.)

Ouch, that looks pretty awful.

>
> The PPS signal will fix that.
>
> The GPSDO will continue providing decent time if your GPS stops working.  
> Holdover is the buzzword.


Currently my stratum-1 servers are as follows, in decreasing order of accuracy:
* amd64 PC with Symmetricom/Microsemi BCP635 timing board, fed with
the 1 PPS signal from a UBLOX-7 receiver.
* amd64 PCENGINES with GPSDO with PPS fed to serial port. I very
recently got two GPSDO, a BG7TBL and a Oscilloquartz STAR 4 receiver.
The latter is very nice as it also provides the receiver state
(calculating stationary mode, stationary mode, GPS lock info and
holdover info).
* amd64 PCENGINES with vanilla UBLOX-7 receiver with PPS fed to serial port.


Thus far I have been playing with PPS on the serial port. I just
modified the serial port driver to support PPS_ECHOASSERT and
PPS_ECHOCLEAR so that I can use the oscilloscope to get a quantitative
understanding of what the interrupt latency and jitter is. Perhaps I
should experiment with PPS on the parallel port as well. RS232 is far
from ideal, mainly due to the fact that the rise time of the PPS edge
on a 12 volt signal is very high. The UBLOX-7 PPS has a TTL output and
the RS232 port I use is TTL compatible so I'm hoping this ameliorates
the issue with the rising edge on the RS232, but I'll only know for
once I get the measurements with the oscilloscope.

I keep comparing the time between these three servers, and I've
observed an absolute lock offset of approximately 10 to 20
microseconds between the timing board server and the PPS on RS232
servers. That is what I would expect by RS232 timings. Once I have the
oscilloscope measurements I should be able to adjust and correct for
the average interrupt latency, although I won't be able to do anything
for the jitter.


>
>
> --
> 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 -- 

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

[Achim Gratz]

Fiorenzo Cattaneo writes:
> 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.

The asymmetry from different bandwifth up-/downstream is only a small
part of the effective up-/downstream difference.  Dan Drown has measured
that:

https://blog.dan.drown.org/tag/asymmetric-latency/

I would think the jitter distributions are skewed as well, so some of
that gets finally interpreted as an offset.  If you can trust the clocks
on either end of the connection to be accurate, then you can set the
offset to zero and solve for the asymmetry instead of the usual
assumption of zero asymmetry to solve for the offset.

Plotting the offset against the RTT like Dan does is instructive, but
you won't always get such nice graphs.  I've attached a plot of how one
of my stratum-1 has seen the three PTB servers through my DSL connection
during the last three months.


So while the connection is stable you can sort of remove the extra
offset that comes from a changing RTT, but at any one time you might
jump to one other set of correlation lines and get that "correction"
wrong.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
___
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

[Dave B via time-nuts]

Hi.

Personally, I would not trust an "ISP" based NTP server!  From personal
experience, they tend to run them on the heavily congested
border/gateway systems.   As you can find and confirm using the usual
network routing and diagnostic tools.

As has been said, local GPS / Internet sync'd servers would be best, and
easy to setup and maintain.

The fun bit will probably be the management arguments about running one
(or hopefully more) GPS receivers, and the associated cables in from the
outside..

Don't forget to run them from a UPS!..  If you end up with more than one
local server, and there are more than one UPS protected power sources,
spread the load around and add redundancy.

All that can be done on a "shoestring" and still give good quality service.

Or you could raise some funds, and purchase two or three of these:-

http://www.leobodnar.com/shop/index.php?main_page=product_info=120_id=272

No affiliation, but they come recommended.  (And I've only just noticed
that they are not far from me.)

Regards.

Dave B.


On 21/10/2019 17:00, time-nuts-requ...@lists.febo.com wrote:
> Finally, your ISP
> too probably has their own NTP servers too that you may or may not
> know about.

-- 
Created on and sent from a Unix like PC running and using free and open source 
software:


___
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

[Steven Sommars]

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.


On Mon, Oct 21, 2019 at 11:01 AM J.R.  wrote:

> > 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.
>
> True, but you *can* see which upstream time source has been selected
> for a NTP server. Ask went through the pool servers last leap-second
> and contacted all the owners that were returning a Google IP as their
> primary time source to get them to change their configuration.
> Likewise, said servers that weren't reconfigured in time were pulled
> out of rotation during the event to prevent any issues. So there
> *were* some preventative measures taken.
>
> AFAIK, the only *big* public time services that do leap-smearing are
> Google & Amazon.
>
> Yes, I know a person *can* configure their own NTP server to do
> smearing too But if that one second is mission critical, then you
> are probably taking a lot more care choosing upstream time sources.
>
> ___
> 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

[J.R.]

> 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.

True, but you *can* see which upstream time source has been selected
for a NTP server. Ask went through the pool servers last leap-second
and contacted all the owners that were returning a Google IP as their
primary time source to get them to change their configuration.
Likewise, said servers that weren't reconfigured in time were pulled
out of rotation during the event to prevent any issues. So there
*were* some preventative measures taken.

AFAIK, the only *big* public time services that do leap-smearing are
Google & Amazon.

Yes, I know a person *can* configure their own NTP server to do
smearing too But if that one second is mission critical, then you
are probably taking a lot more care choosing upstream time sources.

___
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

[Myron Reiss via time-nuts]

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 

___
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

[Steven Sommars]

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.

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

[Bob kb8tq]

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

[Hal Murray]

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

[Hal Murray]

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.

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

[Fiorenzo Cattaneo]

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] can of worms: time-of-day in a community radio station

[J.R.]

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.

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

[Hal Murray]

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.

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

[Mark Sims]

Well,  Lady Heather will do all that (plus handle time zones, DST, and 
leapseconds).  A Ras PI (even a Pi Zero) works very well.   I have just added a 
"radio station studio clock" display mode.  This clock display is driven by the 
system clock which is hopefully steered by NTP.  Default update rate is 10 Hz.  
 It can also be driven by a GPS device or GPSD.

Heather also supports a full screen digital date/time clock.

I just bought a nice 24" HDMI monitor for $60.  Add a $10 Pi Zero W and another 
$10 or so for power and cables.   And maybe $10-$30 for a battery backup (many 
people use USB power banks) so you don't have hiccups due to generator 
switchover, etc.

---

> 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.___
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

[Fiorenzo Cattaneo]

I'd definitely think so, good idea :-) . I've also seen some open
source projects which calibrate the PPM drift based on the measured
temperature either using the CPU's temperature measurement or a cheap
USB temperature ambient sensor, thus implementing some sort of
"software ovenization". Unfortunately I don't have the link handy.

-- Fio Cattaneo

Universal AC, can Entropy be reversed? -- "THERE IS AS YET
INSUFFICIENT DATA FOR A MEANINGFUL ANSWER."

On Sat, Oct 19, 2019 at 11:02 AM Adrian Godwin  wrote:
>
> On Sat, Oct 19, 2019 at 4:17 AM Hal Murray  wrote:
>
> >
> > The crystal is a thermometer.  On modern systems, the temperature depends
> > on
> > the workload as well as the air conditioning.
> >
> >
> Off-the-wall thought :   could you discipline a well-insulated raspberry pi
> to NTP using heaters or workload to modify its temperature ?
> ___
> 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

[Fiorenzo Cattaneo]

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
 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

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

[jimlux]

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.




___
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

[Achim Gratz]

Adrian Godwin writes:
> Off-the-wall thought :   could you discipline a well-insulated raspberry pi
> to NTP using heaters or workload to modify its temperature ?

Yes you can, been doing that with four rasPi and two TinkerBoards for
quite a while now to run the XTAL at its turnover temperature (which is
roughly 60°C for the rasPi and slightly higher for the TinkerBoard).
Depending on how much temperature swing you need to accomodate in total,
you may not be able to cope without external heating or cooling,
though.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

___
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] can of worms: time-of-day in a community radio station

[Bruce Hunter via time-nuts]

I have not been carefully following this thread, but it brings to mind 
experiences with broadcast time systems 40 or 50 years ago.  

Accurate time is critical for operating networks of stations as one second can 
correspond to a loss of about three words.  Digital displays were (are) OK for 
engineers and producers preparing to join networks, but very difficult for 
announcers reading copy and timing their reading to end on time.  For that case 
the proportional indication of an analog second hand was (is) extremely 
important.  So we had both as it is difficult for the brain to interpret 
digital indications while trying to concentrate on other tasks.

In my day major broadcast facilities employed Western Union clocks.  These were 
synchronized on the hour by a pawl pulling up the second hand at about xx:xx:59 
seconds and releasing it at the stroke of the hour.  Many such clocks, all over 
town, were connected in series through an 80 mA loop to a master pendulum clock 
at Western Union's area headquarters.

Every 24 hours a Western Union technician would synchronize the area master 
clock with a pulse from the Naval Observatory. 
About 1973, Western Union technicians went on strike and management personnel 
were either unaware of the synchronization requirement or failed to figure out 
how to implement it.  The system's clocks drifted until unusable.  We installed 
a time standard based upon a Sultzer quartz crystal oscillator that included 
circuitry to preset and implement leap seconds at the proper time in the middle 
of the night, along with a WWV receiver for setting the system.  Western Union 
closed their clock business following that strike.

Another story.  An area radio station decided to forgo the Western Union clocks 
and install electric wall clocks as an economy move.  Their unionized 
announcers threatened to go on strike, saying the clocks were a symbol of their 
professionalism.  Even technical people must consider industrial psychology in 
the workplace.

Bruce, KG6OJI


 
___
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

[Didier Juges]

"Of course this is why I am a time-nut :-)"

I might say you graduated from the Advanced class with honors :)

Didier KO4BB
___
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

[Bob kb8tq]

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  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  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  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 

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

[Adrian Godwin]

On Sat, Oct 19, 2019 at 4:17 AM Hal Murray  wrote:

>
> The crystal is a thermometer.  On modern systems, the temperature depends
> on
> the workload as well as the air conditioning.
>
>
Off-the-wall thought :   could you discipline a well-insulated raspberry pi
to NTP using heaters or workload to modify its temperature ?
___
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

[Philip Jackson]

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-boun...@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  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.



___
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

[David J Taylor via time-nuts]

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-tay...@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.

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

[Hal Murray]

> With this setup you have no single point of failure, and even if the
> connection to internet fails, they can still provide time as they are peering
> and synchronizing with each other. 

No, it doesn't work that way.  You need connectivity to at least one stratum 1 
server.

There is an option to elect one, orphan mode, if you get disconnected from the 
net.  That keeps all the local clocks close together.  They will all drift 
along with the chosen leader.


> You can use this list to pick stratum 1 servers:
>   http://www.advtimesync.com/docs/manual/
> stratum1.html 

There is no date on that list.  At a quick glance, a few systems I'm familiar 
with are way out of date.  I wouldn't trust any of the details.  Same for 
other lists of stratum 1 servers.  They might be a good starting point.  In 
particular, many servers that say "open access" on lists like that have 
changed their rules, often going off the air.


> server time.nist.gov

That's a bad example.  NIST has servers at several locations.  That name 
rotates across them.  You might get a good one, or you might get one on the 
other side of the country.  If it works well today, it may not after you 
reboot and pick a different server.
  https://tf.nist.gov/tf-cgi/servers.cgi


> just a cheap GPS receiver (serial is best, but USB should be OK

There are 3 levels of GPS receiver.  GPSDO is best.  GPS with PPS is second - 
serial prefered, but USB works.  Low cost GPS (without PPS) on USB is last.

USB is polled -- no interrupts.  That adds a millisecond of jitter.  That's 
probably not an issue if your goal is 100 ms.  (If you are a geek, be sure you 
understand hanging bridges.)

The timing on the serial port from low cost GPS receivers is often crappy.  
This is a horrible example:
  http://users.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif
Anyway, you need to check the device you select.  (Or get suggestions from 
people who are using them for NTP.)

The PPS signal will fix that.

The GPSDO will continue providing decent time if your GPS stops working.  
Holdover is the buzzword.


-- 
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

[Fiorenzo Cattaneo]

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
 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-tay...@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.

___
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

[Fiorenzo Cattaneo]

Here are (some) answers to your questions.  Using NTP to synchronize
time across all machines is the one which makes the most sense IMHO.

In the past I setup the NTP server architecture for a "megacorp" I was
working for, and I have replicated the same setup (at a much smaller
case) in my house. My house has a wide mix of Linux, FeeBSD, Windows
and embedded clients such as IP videocameras, home controllers and
such ..

First, I second the recommendation to use Meinberg NTP server on
Windows, as Windows built-in client is quite poor.

For the NTP architecture layout, I would recommend having one to three
internal stratum-2 NTP servers which you can use for internal time
distribution.
* These stratum-2 NTP servers in turn synchronize with well known
public stratum 1 servers (at least 3, ideally 5)
* These stratum-2 NTP server peers with the others (if you have more than one)
* Each internal client would then synchronize to them directly and
thus would be a stratum-3 client.

With this setup you have no single point of failure, and even if the
connection to internet fails, they can still provide time as they are
peering and synchronizing with each other.
You can use this list to pick stratum 1 servers:
  http://www.advtimesync.com/docs/manual/stratum1.html
When selecting them, make sure you comply with their access policies.

=== example

Suppose your stratum-2 servers are clock1.local, clock2.local,
clock3.local. You ntp.conf would look something like this:

# ntp.conf server list for clock1.local
# public stratum 1 servers
server bigben.cac.washington.edu
server time-nw.nist.gov
server time.nist.gov
# peers
peer clock2.local
peer clock3.local


Then all the clients would simply have clock1.local, clock2.local and
clock3.local as their NTP servers. Note that your NTP servers do not
need to be dedicated, you can use any of the existing machines, so
long as they are always up.

A second refinement you could do is to get a GPSDO or just a cheap GPS
receiver (serial is best, but USB should be OK given your requirement
is +/- 100 ms from UTC) and add that to the internal servers, which at
this point would become stratum 1 servers.


At my home I follow this setup except that I am a bit crazy, and
Iactually have 3 dedicated servers, one with a GPSDO, one with a GPS
receiver and one with a symmetricom/microsemi timing board + GPS. I'm
in the process of building a couple WWVB receivers so I can detect if
GPS is being jammed. Of course this is why I am a time-nut :-)

Best of luck !




-- Fio Cattaneo

Universal AC, can Entropy be reversed? -- "THERE IS AS YET
INSUFFICIENT DATA FOR A MEANINGFUL ANSWER."


On Fri, Oct 18, 2019 at 1:00 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
>
> 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 

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

[David J Taylor via time-nuts]

  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-tay...@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.

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

[Hal Murray]

Just out of curiosity, how many PSc/laptops/servers does it take to run a 
radio station?


e...@scace.org said:
> What NTP software should be used on Windows OS machines? Linux servers?

There is a version of ntpd available for Windows.  Meinberg builds and 
distributes it.

Most Linux distros come setup to use ntpd with servers from the pool.

It's impolite to use the pool (or other servers) if you have more than a 
handful of clients.  Setup a pair (or more) of servers to use the pool and 
point your internal clients at them.

You may be able to configure your dhcp server to tell clients which NTP 
servers to use.



> desktops and servers: better NTP configuration NTP checks: at least hourly? 

I treat things like "at least hourly" as an indication of suspicious software.

There are a lot of packages that poll a server and smash the local clock.  
They usually have an option to set how often to do that.

The real key to decent timekeeping on a computer is to calibrate the crystal 
offset.  Modern OSes have a way to set that knob.  ntpd calls it drift.  It's 
saved in a file so it can be reloaded on reboot.  (Units are PPM.)  ntpd 
adjusts the polling interval automagically looking for the bottom of the adev 
graph with a cap at 1024 seconds.

The crystal is a thermometer.  On modern systems, the temperature depends on 
the workload as well as the air conditioning.


>   * some systems are on in-house Ethernet; others on in-house wi-fi

How good is your WiFi?  (mine is crappy)

The other consideration in this area is how good is your Internet connection?  
If it is saturated by a big download or upload, that may confuse ntpd.  ntpd 
assumes the network delays are symmetric.  It also filters out quirky samples. 
 The filter uses the last 8 samples so you need a long-enough download/upload 
to cause problems.  (There is a huffpuff option to try harder.)


>  − no smearing (minimum requirement)
  Beware of Google's NTP servers.

>  − accurate leap second display (desirable but unlikely to be 
> achievable)

What would anybody do if they saw a blinking "LEAP" on a display?

The NTP protocol distributes a leap-tonight indication.  It's fairly easy to 
query your ntpd server to see if that will happen.

NIST and others distribute a file with a list of leap seconds, including the 
next one if it has been announced.  (ntpd can use that file to introduce local 
leaps and/or override leaps from the net.)


>  … use time.nist.gov  and similar
> higher-quality NTP servers 

They are high quality in the legal sense, but the network between you and the 
server may add a lot of noise.

You may be able to find good local servers.  Ask around.  What do the local 
geeks use?  (There is probably an overlap between radio geeks and network 
geeks.)

---

How often does your internet link go down?

---

The package that provides ntpd probably includes ntpq.  You can use it see 
which servers ntpd is using, the round drip time to each server, and the 
offset to each server.  Try the peers command or ntpq -p  (defaults to 
localhost).

ntpd is a server as well as a client.  You can setup one system to monitor all 
the other systems you are interested in.  In your config file, add a server 
line with noselect.  That way, ntpq -p on one system will give you a quick 
health indication of the others.  You can also collect make graphs and/or will 
have logs if you want to investigate glitches.

---

You can setup a Raspberry Pi with a GPS as a time server.  That will give you 
a good place to stand if you want to see how your NTP servers are doing.  (You 
need a GPS Hat.  The low cost GPS mice that connect via USB don't provide PPS 
and even if they did, USB adds a lot of noise.)

It may not work with the antenna indoors.  Maybe near a window?  Or for a 
temporary hack, use a long extension cord and long ethernet cable and put it 
outside.

-- 
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

[paul swed]

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  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  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 

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

[Martin Flynn]

Our makerspace is using a BSD licensed product called OAS (On Air 
Screen) in the studio, with a slave displays planned at the engineers 
workstation, and in the Makerspace workshop . Link: 
github.com/saschaludwig/OnAirScreen


OAS has been set up on an Raspberry  PI, with the PoE shield on the back 
of the monitor.  OAS loads itself full-screen, no keyboard or mouse needed.


We are working on a supportable means to turn the various "lights" on 
the display(s) on and off automatically over the network using UDP messages.





As an example: Our Wheatstone R60 console has a relay that activates 
when any of mixer channels are active and feeding the main output. The 
relay contacts will drive a logic (GPIO) pin on a single-board computer 
(Xunlong Orange Pi Zero). The Pi Zero is running a python application 
that will generate a UDP message on the network to activate the "on-air" 
light on each display.


Obligatory Time nuts statement:  Time standard is a Symmetricom XLi GPS 
Disciplined TCXO with the 10MHz option


73

Martin

On 10/18/2019 4:33 PM, Bob kb8tq 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  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 

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

[Taka Kamiya via time-nuts]

I only have one idea.  Something I thought of doing it myself but have not done 
so, yet.
I think syncing locations with GPS or ntp is good enough for time 
synchronization.  But display could be problematic.  As they make transition 
from one program to another, 1 second overlap or 1 second of blank is quite 
long.  Listeners will certainly catch on to that.
I wanted a digital clock that has HH:MM:SS but below that are bar graph for 
sub-second.  Say 10th of a second, one LED representing 1/10th.  That way, they 
can count down and meet at 00 exactly enough for human perception.  For this 
kind of thing, fast flying 10th digit isn't really useful as it's awfully hard 
to read, let alone read and do something else, like think of a word to fill 
that last 1/2 second.
I would think this kind of thing is easy enough to implement either as a 
hardware or an application on Windows/Linux workstation.  Whatever the device 
to use, it must be synced with the master source.  PC's clock can go off by 20 
seconds per day quite easily.  Even server class machines close to million 
dollars use cheap 32KHz fork crystal.



--- 
(Mr.) Taka Kamiya
KB4EMF / ex JF2DKG
 

On Friday, October 18, 2019, 4:00:41 PM EDT, 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

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 

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

[David C. Partridge]

use Meinberg ntp if running Windows systems.   If you can you can drive an 
analog display derived from the system time all the better as humans can relate 
to that better than a digital clock display.

Daviud

-Original Message-
From: time-nuts [mailto:time-nuts-boun...@lists.febo.com] On Behalf Of Eric 
Scace
Sent: 18 October 2019 20:20
To: Time Nuts email list
Subject: [time-nuts] can of worms: time-of-day in a community radio station

   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 N

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

[Bob kb8tq]

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  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

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

[Eric Scace]

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  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.

   * some systems are on in-house Ethernet; others on in-house wi-fi



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 treatment:

  − 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 

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

[Eric Scace]

   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  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