I have a network using a Catalyst switches and NTP to sync time. The discrepancy in time among workstations can be anywhere from 5ms to 100ms. I know the Catalyst series Switches do not support PTP or GTP. Can I use something like Syn1588® PCIe NICs to overcome the limitations of the switches and have a more precise time in my network?
I'll attempt an answer.
TLDR: In short, to run PTP across a Catalyst switch:
- use priority queuing for PTP packets/frames
- use PTP over UDP/IP (probably making QoS configuration a bit simpler)
- probably, PTP comes as multicast - be sure to have a proper multicast forwarding setup in place.
- a good NTP set up might be good enough.
Longer: You may choose to switch over from NTP to PTP. There will be some cost and learning curve involved. New NICs, new client side drivers/kernel modules/deamons will need to be configured, debugged analyzed and monitored.
(Not only) Catalyst switches will happily transport PTP packets or frames. You may "help" things a bit with a QoS configuration that puts these frames into the low latency/priority queue.
This will either require marking the packets them with DSCP46/EF at the source (recommended) or by classifying/marking them with DSCP46/EF as they enter your switching infrastructure. You may need to consult the vendor's documentation or use a packet trace of the given PTP packets/frames to find out what properties of the packet you can use for the matching criteria for classification/marking.
From that perspective, it might help to run PTP over UDP/IP, so you can read or set QoS markings from/to a field of the IP header. PTP over IEEE802.3 (i.e. "over Ethernet") might be a bit more difficult to handle in this context, as it might make the QoS classification/marking procedure a bit more difficult.
That's aboud all I can say about PTP. I've only come across it once, and all I had to do was making sure that multicast forwarding was working as intended and that the PTP frames were in the priority queue, as was requested by the vendor.
A case for NTP: You may also choose to stick with NTP.
First, learn about your clients. Those of the "simple kind" (happy with fetching the time once a day and stepping their clock accordingly) can make do with a single server, maybe a second one for redundancy. Accuracy for them will be up to their local clocking system, and how accurate it may ever be.
The clients of the sophisticated nature like to discipline (not step) their clock, and they need either one time source, or three-or-more, preferrably not two. NTP mathematics don't work well with two time sources (also see https://tools.ietf.org/id/draft-ietf-ntp-bcp-01.html#rfc.section.4.1). Also, these clients depend on talking to the same servers over a long time, so they can learn how reliable their servers are.
Having GPS receiver as one time source is a very good starting point.
Some suggest a Raspberry Pi with an RTC addon makes a good NTP server as well (in that case connecting to internet based servers over your first ISP).
A third small hardware box connecting to some other time source (i.e. a different set of Internet servers over another ISP) will give you the third source of time (a surplus Cisco 800 series router, maybe?).
If there is an equivalent to DCF77 (https://en.wikipedia.org/wiki/DCF77) in your area, consider using such a radio based source for a fourth small hardware box as well.
Then have the simple NTP clients get their time from either of these three at regular intervals, and let the more sophisticated ones talk to all three/four of them. That should get you very good time quality for most of your systems.