[chrony-users] Tip for people using cheap local GPS-based NTP appliance

[Stephen Satchell]

I got a fairly low-cost consumer-grade NTP appliance for Christmas. In
connecting it to my network, I found that the fairly high amount of
broadcast traffic I have was giving the poor appliance's TCP/IP stack
fits, which was affecting clock quality.

I have an HP ProCurve ethernet switch in my network. I was able to use
the capabilities of that switch ($35 at the local used-computer store)
to isolate traffic for the appliance on a tag-based VLAN. By enabling a
VLAN on my time servers, I'm able to isolate all traffic to the
appliance to just NTP packets (and associated ARP), and the appliance
now runs happy and accurately.

The improvement in time quality was using the "tracking" command, and
including a couple of Stratum 1 servers in my configuration to check for
false-ticking from the appliance.

For what it's worth...

[Miroslav Lichvar]

Post by Stephen Satchell
I got a fairly low-cost consumer-grade NTP appliance for Christmas. In
connecting it to my network, I found that the fairly high amount of
broadcast traffic I have was giving the poor appliance's TCP/IP stack fits,
which was affecting clock quality.

That is an interesting issue.

Would you mind sharing the vendor and model of the appliance? Have you
reported the problem to them? Maybe they could fix it with a firmware
update.

[Stephen Satchell]

Post by Miroslav Lichvar

Post by Stephen Satchell
I got a fairly low-cost consumer-grade NTP appliance for Christmas. In
connecting it to my network, I found that the fairly high amount of
broadcast traffic I have was giving the poor appliance's TCP/IP stack fits,
which was affecting clock quality.

That is an interesting issue.
Would you mind sharing the vendor and model of the appliance? Have you
reported the problem to them? Maybe they could fix it with a firmware
update.

Yes, I would mind. I think they need a chance to whack the problem
before I expose them. (I used to write reviews for a number of the
computer magazines; I'm following ethical SOP with regards to discovered
problems.) One reason I decline is that, in my decades working on
networks, I've run across literally dozens of devices with embedded
TCP/IP stacks that fared poorly when attached to a busy network.

When I was a system/network administrator at a web hosting company with
co-located equipment, one complaint from a colo customer was "you're
killing me with your ARP traffic." It wasn't until years later I
discovered the "victim" was a power controller from APC that would choke
on high levels of layer-2 broadcast traffic.

As for the particular NTP appliance, I called their technical support to
discuss what I had encountered. "We have another model with a more
robust processor" -- for twice the money. And no guarantee that the
TCP/IP stack would fare any better.

Consider this: what good is a Stratum 1 source if the connection
between the source and the system running Chrony has lots of jitter,
from any source? By isolating the device from other traffic, and using
1000 base T from each time server to a gigabit switch, the jitter
between the appliance and the servers is measured in fractions of a
microsecond. (Which I've observed in the statistics for the connection
between time server and appliance, using chronyc.)

The appliance had other, unrelated, problems (doesn't like Linux
browsers, which may have more to do with JavaScript than anything else).
In other words, it's like other consumer grade electronics in its
ability to handle enterprise-level issues. I suggested possible
augmentations that would let people like me get around the GUI; they're
thinking about it. Specifically, TELNET and SNMP access to the
configuration of the device.

Your typical Windows user in a home environment wouldn't encounter the
problems with this device. And the typical Windows user wouldn't care
about extracting the most accurate time possible from the appliance.

tl;dr: It's my hobby horse.

So, isolating the device in its own broadcast domain using a VLAN was a
cheap and easy solution. A practical application for VLANs in a smaller
network. The upside is I didn't have plunk down another small stack of
bills, and I learned something new.

(N.B.: if the appliance knew about tagging, I wouldn't have needed to
have the HP ProCurve gigabit ether switch, which has been in my network
for a long time. Or perhaps maybe so; read above about jitter. But
then again, the only consumer grade equipment I have that knows about
tagging (VLANs) is my WiFi access point.)

(Further N.B.: if I had needed to, I have a small collection of Cisco
Catalyst 3550-48 switches in my networking collection. But those have
fans -- loud ones -- and the HP ProCurve is fanless. Also, the Cisco
switches has 10/100 ports, not 10/100/1000.)

[Rob Janssen]

You could try the LeoNTP: http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=120&products_id=272

It is "cheap" and handles a lot of NTP load.
But it does not have any monitoring or management from the network side.

Rob

[Denny Page]

Yes, I would mind. I think they need a chance to whack the problem before I expose them. (I used to write reviews for a number of the computer magazines; I'm following ethical SOP with regards to discovered problems.) One reason I decline is that, in my decades working on networks, I've run across literally dozens of devices with embedded TCP/IP stacks that fared poorly when attached to a busy network.

I’ve done a bit of testing on smaller NTP appliances. Based on the limited description, I may or may not have tested the unit you have. I understand and agree with your position about disclosure. With the vendors I have been involved with, I have been quite careful to not discuss implementation or performance specifics of other vendors products with them. It is the only way that vendors feel safe in working with you.

As for the particular NTP appliance, I called their technical support to discuss what I had encountered. "We have another model with a more robust processor" -- for twice the money. And no guarantee that the TCP/IP stack would fare any better.

Agree that this is a big unknown. Often, with a more powerful processor comes an embedded Linux and GPSD rather than a dedicated machine code implementation.

Denny