| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Since our timestamping is going to the same as 1588’s, I suggest we follow the same format. Using another format (like 0.1ns increments) has no benefit and
just causes problems as the system would have to convert between the formats. Of course, we don’t need to use all 16-bits of the 1588 fractional nanoseconds field format. If we only want 4-bits worth, we should use the most significant
4-bits of the 1588 fractional nanoseconds field (1/16 of a nanosecond increments). Rich From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Jouni Korhonen Pah.. we know less than 1ns would most likely be overkill for current known applications. The question I have / had is that whether we want to follow what 1588
did or do something else. That something else being either 1) no fractional nanoseconds at all or 2) e.g. what WLAN guys are after (0.1ns which is 4 bits more). - Jouni
From: AshwoodsmithPeter [mailto:Peter.AshwoodSmith@xxxxxxxxxx]
LOL – yes I know ; )
My gut feeling is that as we get into 1/65535th of a nanosecond we are well beyond the realm of the possible so that may be way too many bits.
One nanosecond is about 25cm in fiber. So we are talking .0004 of a cm!!!! Seems like over kill to me but I’m not a clocking expert. I can see doing this kind of overkill on periodic PTP packets where the bits don’t cost bandwidth, but here where every bit counts I think we need to be more
frugal. Cheers, Peter From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
You would need to add 16 more bits to the timestamp. - Jouni
|