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

[Stephen Satchell <list@xxxxxxxxxxxx>]

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

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