On 2019-12-02 12:39 p.m., Adam Thompson wrote:
> On 2019-12-02 11:42, Gerald Brandt wrote:
>> Hi,
>>
>> I'm looking for an IEEE 1588v2/PTP aware switch. Looking around, I've
>> found several ruggadized ones and a couple in office types. I only
>> need something for use in office, and something with 16 or 24 GigE
>> ports would work.
>>
>> The ones I've found are pretty expensive, considering we would need 4
>> of them.
>
> Yes, PTP support is generally limited to Enterprise / Industrial / ISP
> grade equipment.  Some of which can be found used, if you're willing
> to go that route.
>
> Otherwise, have a look at:
> https://www.nist.gov/el/intelligent-systems-division-73500/ieee-1588-products-implementations
>
> https://en.wikipedia.org/wiki/List_of_PTP_implementations
>
> and this fellow's experience, which seems to mirror yours:
> https://www.reddit.com/r/networking/comments/568xax/new_to_ptp_ieee_1588_have_questions_on_how_to_get/
>
>
> I can tell you from direct experience that the two lists I linked
> above are FAR from comprehensive.  You can, with a bit of work, find
> pages like this:
> https://gtacknowledge.extremenetworks.com/articles/Q_A/What-Timing-Protocols-are-supported-on-Extreme-Switches
> from each major vendor.
>
> An alternative is to use a cheap server (Atom-based is fine) with two
> server-class NICs in it, and run a PTP bridge, see below.
>
> Also, if there's a straight layer-2 path from the end station that
> consumes PTP time, to the Grandmaster, the intermediate switches DO
> NOT have to be PTP boundary clocks.  The PTP protocol can compensate
> for non-PTP transparent switches/bridges between the consumer and the
> Grandmaster.  You can lose a small amount of accuracy
> (sub-millisecond) but that's still good enough for many/most
> scenarios.  NOTE: this is not a guarantee; YMMV; circumstances may vary.
>

I think what we're looking for is a switch with PTP Transparent Clock.
Currently, the PTP packet goes through three switches (ugh, I know) to
get from engineering to verification. One switch is in engineering to
get all their equipment hooked up, that goes to the server room, with
goes to verification with their own switch for their equipment. It's all
the same network. We get enough lag that the PTP time differential
affects our testing. We can do most of our testing with IRIG, but our
clients will want PTP at some point. Going through a single switch
helps, but it may be cheaper to get PTP Transparent Clock switches then
it would be to get multiple new network drops through out the building.
(we're pricing that out).

> Where you would need a Boundary Clock is, for example, to retransmit
> PTP time onto a different VLAN than you received it on.  This is,
> AFAICT, why PTP-capable switches exist... you'll note that most
> PTP-capable products are high-end because they're actually *routing*
> switches, and the L2 path to the Grandmaster is broken when you cross
> a router hop.  That's where a cheap server can come in handy, it can
> rebroadcast PTP time received on one VLAN onto others.  Again, you'll
> lose accuracy & precision simultaneously (no more 5ns sync!) but
> you'll get something.
>
> Finally, the $64,000 question would be why you need to use PTP in the
> first place?  Properly configured NTP can keep (non-Windows) systems
> in sync to within about 3msec on a LAN, including local router hops. 
> The only

Industry/Client demand. PTP is specced in RFCs.

>
> I'm pushing to get PTP capability at MBIX, but that's because I
> already happen to run mostly PTP-capable gear, it doesn't add much to
> MBIX's cost, so hey why not!  MBIX members wouldn't be required to get
> PTP-capable equipment: if this happens, I think it would just be a
> thing that's magically available on the IX fabric if your gear knows
> how to listen for it.  I think.
>
> -Adam
_______________________________________________
Roundtable mailing list
Roundtable@muug.ca
https://muug.ca/mailman/listinfo/roundtable