Given a non-PTP switch (e.g. no hardware support for time stamping), how can one make it to be as close as possible to a PTP compliant switch. I am thinking here to configure the switch such that the PTP traffic has the highest priority (which is kind of super basic configuration). Can you please suggest other possible configurations?

PS: I am aware that in general such configurations are hardware dependent given the switch capabilities. Therefore I am looking for all kind of crazy options.

  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 7 '17 at 21:36

How about using a hub rather than a switch?

It might be a stretch since your question has "switch" right there in the title, but you did say:

Therefore I am looking for all kind of crazy options.

Using a hub would avoid the jitter induced by the switch's queue.

I just ran a test where I measured the maximum offset after convergence between two PTP devices first on an unmanaged switch, and then on a hub.

  • Unmanaged switch: ~450ns
  • Hub: ~50ns

As you can see, nearly an order of magnitude improvement.

| improve this answer | |
  • 1
    That's not nearly an order of magnitude difference; it is an order of magnitude difference (hundreds vs. tens). – Ron Maupin Mar 22 '17 at 0:36

How many devices need to be connected?

If not too, crazy solution to connect network cards directly by patch-cord.

But PTP require ultra low jitter, rather latency time. What with network adapter buffers.

| improve this answer | |

Since you are referring to a switch which doesn't recognize PTP, you are probably safe to assume the switch will not negotiate unicast PTP packets. The switch will also ignore the link multicast PTP packets. The other multicast packets have special multicast addresses, and special treatment could be given based on those addresses.

Normally, switches don't look beyond the ethernet frame into the IP packet, so it may not be able to be done on some switches, but the switch could mark the frames and packets with specific COS and DSCP. Some switches can give some priority based on COS, but the queues are pretty small.

| improve this answer | |
  • I am curious if the following is possible: Let us say that the switch is able to identify the PTP messages and that these messages will be forwarded on the other ports with the highest priority. This means that the PTP messages will go first if other messages are buffered for transmission in the other ports. However, it can be the case that on those ports there is ongoing transmission. Is it possible to: 1. cancel this transmission 2. transmit the PTP messages 3. fully re-transmit the messages cancelled at point 1. What kind of options the switch should have to achieve point 3? – user3523954 Mar 15 '16 at 11:56
  • Actually, none of the above. The switch doesn't buffer, it queues, with very small queues, and most don't do priority queuing the way routers do; the high priority frames don't normally get exclusive use of the ports. I think you fail to grasp that PTP will work just fine without being prioritized. Even if the switch understood PTP, it doesn't treat the messages any different than other traffic, other than using the messages for itself, too. – Ron Maupin Mar 15 '16 at 13:19
  • when saying "... PTP will work just fine without being prioritized." i assume that you mean that synchronization is eventually achieved. The goal is my set-up is to have the maximum accuracy given a rather stupid switch that has some Qos features. Therefore, it is important that these PTP messages goes first if others are queued. PS: It is true, i am not a network expert. I see the problem from the Point of view of an hardware engineer that chooses some configuration which according to the datasheet should work. – user3523954 Mar 15 '16 at 13:26
  • I seriously doubt you are going to guarantee all the PTP frames will go first, and any frame already being serialized to a port will always go first. You can't stop an in-progress transmission. In the event of congestion, switches do drop frames, and ethernet has no facility for retransmission. The philosophy of networking is that it is better to drop data as early as possible. In fact, one good QoS tool is RED, which randomly drops packets in order to prevent queues from filling and doing tail-drops. – Ron Maupin Mar 15 '16 at 13:36
  • Can one guarantee that they will go as soon as the in-progress transmission is done? My understanding is that's why QoS exists... to prioritize traffic. – user3523954 Mar 15 '16 at 13:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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