3

When designing a network incorporating IEEE-1588 (PTP), packet-delay variation (PDV) is a significant source of timing error. Both boundary clocks (network nodes which act as a slave clock to upstream nodes and as a master clock to downstream nodes) and transparent clocks (nodes which measure the delay of timing packets so downstream slave clocks can compensate) can effectively minimize error due to PDV [1], [2].

What are the differences in network performance for implementing a transparent clock vs. implementing a boundary clock, for minimizing the impact of PDV?

closed as off-topic by Mike Pennington, Ron Trunk, YLearn Jul 28 '15 at 19:15

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "NE is a site for to ask and provide answers about professionally managed networks in a business environment. Your question falls outside the areas our community decided are on topic. Please visit the help center for more details. If you disagree with this closure, please ask on Network Engineering Meta." – Mike Pennington, Ron Trunk, YLearn
If this question can be reworded to fit the rules in the help center, please edit the question.

  • this question seems to be off topic – Mike Pennington Jul 24 '15 at 15:14
  • 2
    if you want to ask questions about on and off topic subjects, ask a question in Network Engineering Meta. – Mike Pennington Jul 24 '15 at 16:59
  • 2
    I would consider PTP on-topic (IMHO), but your question is too broad to answer. What are your exact (accuracy) requirements, and what "network performance differences" do you mean? – Gerben Jul 24 '15 at 20:39
  • 1
    Welcome to NE, we hope you will both contribute to and learn from this community. Unfortunately, I have to agree with Mike. This is really a question about PTP design/implementation, not about networking. While it does use a network and timing can be important to a network, this question really isn't about networks. In fact, if you remove the mention of "network [supporting|performance]" from the title and last line, this becomes readily apparent as it doesn't change the question at all. They seem to be added simply to make this appear on topic. – YLearn Jul 28 '15 at 19:15
  • 1
    Specifically to address your query as to why this is off-topic when many of the other NTP questions are on topic, if you check the NTP questions they are about enabling NTP on network devices, allowing NTP through ACL/firewalls, setting QoS for NTP, etc. If this were about enabling PTP on network devices, allowing PTP through network devices, how to QoS for PTP, or other network related questions, then it would be on topic. – YLearn Jul 28 '15 at 19:19
1

If you have heavy jitter or significant load, boundary clock. But optimizing for PDV alone will impact clock quality eventually.

If not: Assuming this is decision for a single piece of equipment and not an overall network design: (i.e. not considering overall quality of the clock at a particular hop)

If your particular gear has a path from the net interface that bypasses input queuing ("priority-queue in" behavior) before sending the sync to the PTP controller then boundary. Otherwise transparent.

I suppose some QoS could be applied to put PTP into the same queue as, say, voice traffic, but that still won't get rid of delay variation as calls get made and hung up.

  • Let me see if I understand this correctly: TCs strongly mitigate PDV inside the network equipment, and BCs mitigate PDV (less effectively) outside the network equipment. Is that right? – StockB Jul 27 '15 at 18:29
  • In other words, if there is one link with high PDV, make it a TC. If there are many links with moderate PDV, make an intermediate node a BC (if timing tolerances allow, of course. Otherwise, more drastic design choices may be required). – StockB Jul 27 '15 at 18:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.