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

[ Thread Index | Date Index | More Archives ]

On 01/04/2018 01:57 AM, Miroslav Lichvar wrote:
On Wed, Jan 03, 2018 at 06:47:19PM -0800, Stephen Satchell wrote:
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

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

To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject. For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.

Mail converted by MHonArc 2.6.19+