<div dir='auto'>Cheapest PTP switch I've ever seen costs between C$6k and C$7k - with *education* discount.  You can probably expect to pay at least C$10k.<div dir="auto"><br><div dir="auto">C$10k should get you about 100 drops wired, at normal commercial rates.</div><div dir="auto"><br></div><div dir="auto">Netgear makes a nice business line, stackable or chassis, that doesn't break the bank.  Probably not 1588-compliant, but at least then everyone would be 1 hop from the grandmaster.</div><div dir="auto"><br></div><div dir="auto">YMMV.  Good luck, I don't think you can get that level of precision if the word "budget" exists in the conversation.</div><div dir="auto"><br></div><div dir="auto">-Adsm</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Dec. 3, 2019 13:06, Gerald Brandt <gbr@majentis.com> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
On 2019-12-02 12:39 p.m., Adam Thompson wrote:<br>
> On 2019-12-02 11:42, Gerald Brandt wrote:<br>
>> Hi,<br>
>><br>
>> I'm looking for an IEEE 1588v2/PTP aware switch. Looking around, I've<br>
>> found several ruggadized ones and a couple in office types. I only<br>
>> need something for use in office, and something with 16 or 24 GigE<br>
>> ports would work.<br>
>><br>
>> The ones I've found are pretty expensive, considering we would need 4 <br>
>> of them.<br>
><br>
> Yes, PTP support is generally limited to Enterprise / Industrial / ISP <br>
> grade equipment.  Some of which can be found used, if you're willing <br>
> to go that route.<br>
><br>
> Otherwise, have a look at:<br>
> https://www.nist.gov/el/intelligent-systems-division-73500/ieee-1588-products-implementations <br>
><br>
> https://en.wikipedia.org/wiki/List_of_PTP_implementations<br>
><br>
> and this fellow's experience, which seems to mirror yours:<br>
> https://www.reddit.com/r/networking/comments/568xax/new_to_ptp_ieee_1588_have_questions_on_how_to_get/ <br>
><br>
><br>
> I can tell you from direct experience that the two lists I linked <br>
> above are FAR from comprehensive.  You can, with a bit of work, find <br>
> pages like this: <br>
> https://gtacknowledge.extremenetworks.com/articles/Q_A/What-Timing-Protocols-are-supported-on-Extreme-Switches <br>
> from each major vendor.<br>
><br>
> An alternative is to use a cheap server (Atom-based is fine) with two <br>
> server-class NICs in it, and run a PTP bridge, see below.<br>
><br>
> Also, if there's a straight layer-2 path from the end station that <br>
> consumes PTP time, to the Grandmaster, the intermediate switches DO <br>
> NOT have to be PTP boundary clocks.  The PTP protocol can compensate <br>
> for non-PTP transparent switches/bridges between the consumer and the <br>
> Grandmaster.  You can lose a small amount of accuracy <br>
> (sub-millisecond) but that's still good enough for many/most <br>
> scenarios.  NOTE: this is not a guarantee; YMMV; circumstances may vary.<br>
></p>
<p dir="ltr">I think what we're looking for is a switch with PTP Transparent Clock. <br>
Currently, the PTP packet goes through three switches (ugh, I know) to <br>
get from engineering to verification. One switch is in engineering to <br>
get all their equipment hooked up, that goes to the server room, with <br>
goes to verification with their own switch for their equipment. It's all <br>
the same network. We get enough lag that the PTP time differential <br>
affects our testing. We can do most of our testing with IRIG, but our <br>
clients will want PTP at some point. Going through a single switch <br>
helps, but it may be cheaper to get PTP Transparent Clock switches then <br>
it would be to get multiple new network drops through out the building. <br>
(we're pricing that out).<br></p>
<p dir="ltr">> Where you would need a Boundary Clock is, for example, to retransmit <br>
> PTP time onto a different VLAN than you received it on.  This is, <br>
> AFAICT, why PTP-capable switches exist... you'll note that most <br>
> PTP-capable products are high-end because they're actually *routing* <br>
> switches, and the L2 path to the Grandmaster is broken when you cross <br>
> a router hop.  That's where a cheap server can come in handy, it can <br>
> rebroadcast PTP time received on one VLAN onto others.  Again, you'll <br>
> lose accuracy & precision simultaneously (no more 5ns sync!) but <br>
> you'll get something.<br>
><br>
> Finally, the $64,000 question would be why you need to use PTP in the <br>
> first place?  Properly configured NTP can keep (non-Windows) systems <br>
> in sync to within about 3msec on a LAN, including local router hops.  <br>
> The only<br></p>
<p dir="ltr">Industry/Client demand. PTP is specced in RFCs.<br></p>
<p dir="ltr">><br>
> I'm pushing to get PTP capability at MBIX, but that's because I <br>
> already happen to run mostly PTP-capable gear, it doesn't add much to <br>
> MBIX's cost, so hey why not!  MBIX members wouldn't be required to get <br>
> PTP-capable equipment: if this happens, I think it would just be a <br>
> thing that's magically available on the IX fabric if your gear knows <br>
> how to listen for it.  I think.<br>
><br>
> -Adam<br>
_______________________________________________<br>
Roundtable mailing list<br>
Roundtable@muug.ca<br>
https://muug.ca/mailman/listinfo/roundtable<br>
</p>
</blockquote></div><br></div>