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

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

— Eric

Issue:
A community broadcast radio station with multiple studio locations wishes to improve the display of time-of-day throughout the station’s operating environments. Its current legacy approaches (described below) cause problems such as:
on-air presenters fail to smoothly segue into scheduled program feeds (e.g., BBC news) because the studio clock is “a little off”… and because the studio clock is digital. [Quick: how many more seconds can you speak before the top of the hour when a digital clock shows 4:59:42? Watching an analog stepping second hand is much easier in this situation.]
computers that automatically capture audio programs to files in storage sometimes truncate the start or end of the program because the computer’s idea of time-of-day disagrees with that of the program source.
desktop computers throughout the station, including in production studios, all render slightly different versions of time-of-day to their users.
servers (e.g, for streaming, for archiving shows) are similarly in cheerful disagreement as to time of day.
wall clocks studios in one city show a different time to their engineers than the studios in another city, rendering handoffs more complicated. Ditto for remote broadcast sites, and even between studios in the same site.
requires manual intervention to bring the most egregious systems back to some semblance of reality

Background & existing situation:
Commercial broadcast stations have more money and technology to solve these problems. In contrast, “community radio” stations have limited funds and are largely staffed by volunteers (like me!).

In this case, the existing systems are a hodgepodge:
mostly Windows OS PCs, with a couple of Macs
Linux servers
mash-mash of wall clocks, the best of which is a LaCrosse WWVB digital in the primary on-air studio. The WWVB signal is more than adequate but the LaCross display format is sub-optimal for studio use.

Goals: (first pass)
minimum accuracy requirement: time-of-day displayed within ±0.1 second of UTC timescale. (Two clocks both falling outside this range will cause program handoffs to be uncomfortably tight or loose.)
no manual intervention required for summer/winter time transitions
no manual intervention required for leap seconds
leap second:
no smearing (minimum requirement)
accurate leap second display (desirable but unlikely to be achievable)
desirable consistency goal: time-of-day displayed within ±0.025 second throughout each site. At this level, two adjacent clock displays will not be perceived as out of step by a person.
presentation goals: studio/remote broadcast control point time-of-day displayed in both analog (with stepped seconds hands) and digital form (preferred H:MM).
If digital form includes seconds, the seconds digits should be visually separated; e.g..smaller. A presenter can then, at a glance and without confusion, announce the time (“four twenty-three”) from the digital display.
Date in form “Oct 17 Thu” available.
medium-term desirable: displays continue within specs for accuracy/consistency across power cutovers (to/from generator) and public Internet outages.
maintenance goals:
"eschew emergencies”: no one should have to rush to the station in the middle of the night, nor drop what their doing during the day, because time-of-day display has failed or gone out-of-spec.
standardize on the same hardware/software everywhere
identical hardware allows more cost-effective 1:N sparing
identical hardware/software means less confusion and less training for volunteers. (There are a large number of volunteers who use these systems, and most contribute time less than once per week. Consistency and straightforwardness in the toolkit improves the quality of on-air results.)
not too costly
try to avoid stringing a lot of new cabling around… but such cabling needs are recognized as a one-time investment, so this preference does not eliminate a cable-based solution that has other operational/maintenance advantages

Potential approaches:
potential short-term:
desktops and servers: better NTP configuration
NTP checks:
at least hourly?
verify NTP utility employs reasonable averaging of multiple NTP servers
use time.nist.gov http://time.nist.gov/ and similar higher-quality NTP servers
some systems are on in-house Ethernet; others on in-house wi-fi
clocks:
replace with refurb iPads running a dedicated time-of-day display app providing both analog and digital form. A refurb wall- or desk-mounted 13” iPad in locking frame runs about $100. Smaller sizes can be mounted immediately adjacent to or atop a studio mixing board.
remote field broadcast site: iPad over local wi-fi or cellular data?
IRIG displays could be awesome, but seem far more costly per display and require pulling coax — and integrated analog + digital displays appear to be less common. Two displays (one analog, the other digital) in each studio provide some redundancy but costs go up fast.
NTP-clocks powered over ethernet could similarly be awesome, but are similarly more costly and few integrated analog + digital displays exist.
medium term:
add in-house NTP server (with GPS and reasonable holdover plus battery backup) on each city’s on-site LAN/wi-fi networks as primary source, with remote public NTP servers as secondary. Many suitable models appear to exist, including the ESE E-911 units mentioned recently. Only a few are needed: one for each site plus sparing.
potentially increase the frequency of NTP synchronization for each computer/display clock when a local NTP server has been installed.

Questions:
Are there other approaches that should be considered?
What NTP software should be used on Windows OS machines? Linux servers?
Mac OS allows one choice of NTP server but does not seem to provide for choice of NTP update frequency. Is there a 3rd party software solution, or some other parameter within MacOS that an admin can change to (a) establish a primary and secondary NTP server, and (b) set the frequency of NTP updates?
If one were to use an iPad to display time-of-day, what iPad apps provide the needed display formats, frequency of NTP checks, primary/secondary NTP sources?
For example, Atomic Clock Gorgy updates hourly and allows the user to choose one NTP server group (e.g., time.nist.gov http://time.nist.gov/). It has an analog seconds display format (circle of dots), digital H:MM (optional :SS), and MMM D DDD — although one could quibble over the typography. However, the display shows “SYNC” for a couple of seconds each hour while the NTP update occurs, which would be disconcerting if it happens when a presenter/engineer is in the midst of joining/cutting away from external program sources.
What have we overlooked?

Sadly the formatting of the original message was stripped by the email server. Here is a slightly more comprehensible version.

On 2019 Oct 18, at 15:20 , Eric Scace eric@scace.org wrote:

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

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 <http://time.nist.gov/> and similar higher-quality NTP servers
  

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

  Note: While IRIG displays could be awesome, but seem far more costly per display and require pulling coax — and integrated analog + digital displays appear to be less common. Two displays (one analog, the other digital) in each studio provide some redundancy but costs go up fast.
  NTP-clocks powered over ethernet could similarly be awesome, but are similarly more costly and few integrated analog + digital displays exist.

• potential medium term:

  − add in-house NTP server (with GPS and reasonable holdover plus battery backup) on each city’s on-site LAN/wi-fi networks as primary source, with remote public NTP servers as secondary. Many suitable models appear to exist, including the ESE E-911 units mentioned recently. Only a few are needed: one for each site plus sparing.

  − potentially increase the frequency of NTP synchronization for each computer/display clock when a local NTP server has been installed.

QUESTIONS:

Are there other approaches that should be considered?

What NTP software should be used on Windows OS machines? Linux servers?

Mac OS allows one choice of NTP server but does not seem to provide for choice of NTP update frequency. Is there a 3rd party software solution, or some other parameter within MacOS that an admin can change to (a) establish a primary and secondary NTP server, and (b) set the frequency of NTP updates?

If one were to use an iPad to display time-of-day, what iPad apps provide the needed display formats, frequency of NTP checks, primary/secondary NTP sources? For example, Atomic Clock Gorgy updates hourly and allows the user to choose one NTP server group (e.g., time.nist.gov http://time.nist.gov/). It has an analog seconds display format (circle of dots), digital H:MM (optional :SS), and MMM D DDD — although one could quibble over the typography. However, the display shows “SYNC” for a couple of seconds each hour while the NTP update occurs, which would be disconcerting if it happens when a presenter/engineer is in the midst of joining/cutting away from external program sources.

What have we overlooked?

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-bounces@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 NTP servers
some systems are on in-house Ethernet; others on in-house wi-fi
clocks:
replace with refurb iPads running a dedicated time-of-day display app providing both analog and digital form. A refurb wall- or desk-mounted 13” iPad in locking frame runs about $100. Smaller sizes can be mounted immediately adjacent to or atop a studio mixing board.
remote field broadcast site: iPad over local wi-fi or cellular data?
IRIG displays could be awesome, but seem far more costly per display and require pulling coax — and integrated analog + digital displays appear to be less common. Two displays (one analog, the other digital) in each studio provide some redundancy but costs go up fast.
NTP-clocks powered over ethernet could similarly be awesome, but are similarly more costly and few integrated analog + digital displays exist.
medium term:
add in-house NTP server (with GPS and reasonable holdover plus battery backup) on each city’s on-site LAN/wi-fi networks as primary source, with remote public NTP servers as secondary. Many suitable models appear to exist, including the ESE E-911 units mentioned recently. Only a few are needed: one for each site plus sparing.
potentially increase the frequency of NTP synchronization for each computer/display clock when a local NTP server has been installed.

Questions:
Are there other approaches that should be considered?
What NTP software should be used on Windows OS machines? Linux servers?
Mac OS allows one choice of NTP server but does not seem to provide for choice of NTP update frequency. Is there a 3rd party software solution, or some other parameter within MacOS that an admin can change to (a) establish a primary and secondary NTP server, and (b) set the frequency of NTP updates?
If one were to use an iPad to display time-of-day, what iPad apps provide the needed display formats, frequency of NTP checks, primary/secondary NTP sources?
For example, Atomic Clock Gorgy updates hourly and allows the user to choose one NTP server group (e.g., time.nist.gov http://time.nist.gov/). It has an analog seconds display format (circle of dots), digital H:MM (optional :SS), and MMM D DDD — although one could quibble over the typography. However, the display shows “SYNC” for a couple of seconds each hour while the NTP update occurs, which would be disconcerting if it happens when a presenter/engineer is in the midst of joining/cutting away from external program sources.
What have we overlooked?

time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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 <eric@scace.org> wrote:  

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

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

— Eric

Issue:
  A community broadcast radio station with multiple studio locations wishes to improve the display of time-of-day throughout the station’s operating environments. Its current legacy approaches (described below) cause problems such as:
on-air presenters fail to smoothly segue into scheduled program feeds (e.g., BBC news) because the studio clock is “a little off”… and because the studio clock is digital. [Quick: how many more seconds can you speak before the top of the hour when a digital clock shows 4:59:42? Watching an analog stepping second hand is much easier in this situation.]
computers that automatically capture audio programs to files in storage sometimes truncate the start or end of the program because the computer’s idea of time-of-day disagrees with that of the program source.
desktop computers throughout the station, including in production studios, all render slightly different versions of time-of-day to their users.
servers (e.g, for streaming, for archiving shows) are similarly in cheerful disagreement as to time of day.
wall clocks studios in one city show a different time to their engineers than the studios in another city, rendering handoffs more complicated. Ditto for remote broadcast sites, and even between studios in the same site.
requires manual intervention to bring the most egregious systems back to some semblance of reality

Background & existing situation:
  Commercial broadcast stations have more money and technology to solve these problems. In contrast, “community radio” stations have limited funds and are largely staffed by volunteers (like me!).

  In this case, the existing systems are a hodgepodge:
mostly Windows OS PCs, with a couple of Macs
Linux servers
mash-mash of wall clocks, the best of which is a LaCrosse WWVB digital in the primary on-air studio. The WWVB signal is more than adequate but the LaCross display format is sub-optimal for studio use.

Goals: (first pass)
minimum accuracy requirement: time-of-day displayed within ±0.1 second of UTC timescale. (Two clocks both falling outside this range will cause program handoffs to be uncomfortably tight or loose.)
no manual intervention required for summer/winter time transitions
no manual intervention required for leap seconds
leap second:
no smearing (minimum requirement)
accurate leap second display (desirable but unlikely to be achievable)
desirable consistency goal: time-of-day displayed within ±0.025 second throughout each site. At this level, two adjacent clock displays will not be perceived as out of step by a person.
presentation goals: studio/remote broadcast control point time-of-day displayed in both analog (with stepped seconds hands) and digital form (preferred H:MM).
If digital form includes seconds, the seconds digits should be visually separated; e.g..smaller. A presenter can then, at a glance and without confusion, announce the time (“four twenty-three”) from the digital display.
Date in form “Oct 17 Thu” available.
medium-term desirable: displays continue within specs for accuracy/consistency across power cutovers (to/from generator) and public Internet outages.
maintenance goals:
"eschew emergencies”: no one should have to rush to the station in the middle of the night, nor drop what their doing during the day, because time-of-day display has failed or gone out-of-spec.
standardize on the same hardware/software everywhere
identical hardware allows more cost-effective 1:N sparing
identical hardware/software means less confusion and less training for volunteers. (There are a large number of volunteers who use these systems, and most contribute time less than once per week. Consistency and straightforwardness in the toolkit improves the quality of on-air results.)
not too costly
try to avoid stringing a lot of new cabling around… but such cabling needs are recognized as a one-time investment, so this preference does not eliminate a cable-based solution that has other operational/maintenance advantages

Potential approaches:
potential short-term:
desktops and servers: better NTP configuration
NTP checks:
at least hourly?
verify NTP utility employs reasonable averaging of multiple NTP servers
use time.nist.gov http://time.nist.gov/ and similar higher-quality NTP servers
some systems are on in-house Ethernet; others on in-house wi-fi
clocks:
replace with refurb iPads running a dedicated time-of-day display app providing both analog and digital form. A refurb wall- or desk-mounted 13” iPad in locking frame runs about $100. Smaller sizes can be mounted immediately adjacent to or atop a studio mixing board.
remote field broadcast site: iPad over local wi-fi or cellular data?
IRIG displays could be awesome, but seem far more costly per display and require pulling coax — and integrated analog + digital displays appear to be less common. Two displays (one analog, the other digital) in each studio provide some redundancy but costs go up fast.
NTP-clocks powered over ethernet could similarly be awesome, but are similarly more costly and few integrated analog + digital displays exist.
medium term:
add in-house NTP server (with GPS and reasonable holdover plus battery backup) on each city’s on-site LAN/wi-fi networks as primary source, with remote public NTP servers as secondary. Many suitable models appear to exist, including the ESE E-911 units mentioned recently. Only a few are needed: one for each site plus sparing.
potentially increase the frequency of NTP synchronization for each computer/display clock when a local NTP server has been installed.

Questions:
Are there other approaches that should be considered?
What NTP software should be used on Windows OS machines? Linux servers?
Mac OS allows one choice of NTP server but does not seem to provide for choice of NTP update frequency. Is there a 3rd party software solution, or some other parameter within MacOS that an admin can change to (a) establish a primary and secondary NTP server, and (b) set the frequency of NTP updates?
If one were to use an iPad to display time-of-day, what iPad apps provide the needed display formats, frequency of NTP checks, primary/secondary NTP sources?
For example, Atomic Clock Gorgy updates hourly and allows the user to choose one NTP server group (e.g., time.nist.gov http://time.nist.gov/). It has an analog seconds display format (circle of dots), digital H:MM (optional :SS), and MMM D DDD — although one could quibble over the typography. However, the display shows “SYNC” for a couple of seconds each hour while the NTP update occurs, which would be disconcerting if it happens when a presenter/engineer is in the midst of joining/cutting away from external program sources.
What have we overlooked?

time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

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

— Eric
[]

---==============

Eric,

As others have mentioned, using the reference NTP should do the job with
margin to spare!

• Windows, use the Meinberg port.  I have some info here:
  https://www.satsignal.eu/ntp/setup.html

• Linux, NTP is usually installed by default, although it may be a release
  or two behind.  Usually this isn't important.  Use "ntpq -pn" to see whether
  you have it.

• MAC, reference NTP is available (I believe), but you might need to compile
  it.

• For your one stratum-1 server you can use a GPS source would with a
  Raspberry Pi, or even a Windows PC although that won't be quite as good, but
  adequate for 0.01 seconds accuracy.  Some notes here:
  https://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html

• For a wall-clock from the Raspberry Pi:
  https://www.satsignal.eu/raspberry-pi/DigitalClock.html
  I should really recompile this so that the RPi doesn't have to be rebooted
  when the clocks change, but the compiler/software I used
  (Lazarus/FreePascal) didn't have the required API call at the time.

• using the pool servers for a few PCs is OK, I think, as all the PCs won't
  be hitting the same pool servers.  How many is "a few" - perhaps 20?  Don't
  use "stratum-1" public servers (e.g. time.nist.gov), as they are likely to
  be overloaded and therefore not as accurate as you might expect.  Using the
  "pool" command in NTP and pool servers is likely to be just as good, if not
  better.

I hope that gives you a little more food for thought.

Cheers,
David

SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv