| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Richard, 0.5s is the maximum window size (and thus the tie breaker value as well) so the calculations will give wrong result IF the time difference is greater or equal
to 500000000ns. However, if we care for that 1ns then modifying the example algorithm as follows still produces a correct answer for maximum 0.5s: wrap = abs(diff) > WINDOWSZE ? 1 : 0; - Jouni From: Richard Tse [mailto:Richard.Tse@xxxxxxxx]
Jouni:
From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
That should not make a difference. The exact +-0.5s is always classified as a “wrap” case and then which direction to +-1 sec is done is checked using the signed
comparison of the diff. - Jouni From: Richard Tse [mailto:Richard.Tse@xxxxxxxx]
That looks good Jouni.
There is a special condition when diff equals -500000000 and +500000000. The former will result in a presentation time 0.5 sec in the future and the latter
will result in a presentation time 0.5 sec in the past. Perhaps we should always declare the condition when abs(diff) = 500000000 to be an error condition and force the timestamp to be in the past. Rich From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
The “PTP friendly” timestamp example code with 0.25ns precision over the wire – Richard’s option #2 basically. As discussed during the call today this one also
handles the corner case for late packets: typedef uint64_t uint48_t; #define TSTAMPSZE 1000000000 #define WINDOWSZE 500000000 struct Timestamp { uint48_t secondsField; uint32_t nanosecondsField; }; // Convert a PTP timestamp (the presentation time) to a 32 bit // timestamp with a 0.25 nanosecond precision. uint32_t presentation_to_timestamp( const struct Timestamp* presPTP ) { return presPTP->nanosecondsField << 2; } // Convert a 32 bit timestamp with a 0.25 nanosecond precision to a // PTP timestamp (the presentation time). void timestamp_to_presentation( const struct Timestamp* localPTP, struct Timestamp* presPTP, uint32_t ts ) { int32_t diff; uint32_t wrap; ts >>= 2; // remove fractional nanoseconds diff = ts - localPTP->nanosecondsField; wrap = abs(diff) >= WINDOWSZE ? 1 : 0; presPTP->secondsField = localPTP->secondsField; presPTP->nanosecondsField = ts; if (diff < 0) { presPTP->secondsField += wrap; } else { presPTP->secondsField -= wrap; } } From: Richard Tse [mailto:Richard.Tse@xxxxxxxx]
My presentation regarding the timestamp format is attached. I look forward to hearing everyone’s feedback. Rich From: Richard Tse
Jouni: Rich
From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Richard, Coming back to this.. see inline. From: Richard Tse [mailto:Richard.Tse@xxxxxxxx]
Jouni: I haven’t seen any reason why we should use a protocol independent timestamp or why we need this timestamp to cover more than one second of time (thus negating
the need to convert to/from a larger time counter). Thus, I think that we should use a timestamp of the same format as the nanoseconds field of PTP (IEEE 1588) time. This eliminates any need to convert between time formats, is compatible with the protocol
(IEEE 1588) that will be used to deliver the common time-of-day to the network nodes, and, I believe, covers all the use cases. [JiK:] I would argue that a node that uses 1588 and also does internal timestamping of packets is not really using PTP packet formats internally - at
least not in the parts where hardware operations are required. So I do not buy the “conversion” argument. Although 1588 is a likely choice for time synchronization protocol it does not mean RoE has to depend on its presence. There are others around as well..
specifically GPS/GNSS is still quite a bit in use in cellular side.. Having said this I do not have strong “feelings” whether the timestamp is 1s or 32 bit flat binary in the units of X ns as long as we can agree on some sensible on-wire format with enough
precision. If the on-wire format happens to be “PTP friendly” that’s fine by me. Note that IEEE 802.1.Qbv specifies the use of PTP time for its traffic scheduling CurrentTime. Since 802.1Qbv will likely be used in the same applications
as 1904.3, shouldn’t we be consistent with it? [JiK:] I definitely do not want to build mandatory ties to specific 802 family specs when it comes to RoE.. and time synchronization in this case. It
makes no sense to me. How the ToD is delivered is not RoE’s business as long as there is access to a precise enough time source. This would not forever bind us to using the PTP timestamp format. If something new and better comes along in the future, a new PKT_TYPE could be defined that
uses another timestamp format. [JiK:] Don’t like that approach either ;) Why I would need to do redefinitions and/or add new time source specific packets (and burn that number space)
while I can easily do a time source agnostic solution? For me the real question to discuss is actually whether 1ns precision in the RoE header enough for the future needs. - jouni Rich From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Richard, Because that “64 bit timestamp” was time source and protocol independent. We should not care where the time is sourced from as long as it meets the accuracy
requirements. - Jouni From: Richard Tse [mailto:Richard.Tse@xxxxxxxx]
Jouni: Rich From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Richard, From: Richard Tse [mailto:Richard.Tse@xxxxxxxx]
Jouni: The receiver should know that there is an expected limited size of wait time. If its calculation determines that the wait time is outside this expectation,
then it would either present the info immediately or act upon it in a different way because it is late. I think this type of check would be implemented in any solution, regardless of the format or size of its timestamp. [JiK:] Then with these checks what is the benefit of your proposal? I do not see any simplification in the implementation. In practice, I don’t think a system would work well if the information arrived with little or no time margin for presentation. If CPRI or some other constant-bit-rate
(CBR) datastream is transported over 1904.3, the information must be there when it is expected. A CBR datastream cannot wait for late information. [JiK:] Of course late packet is a late packet. I am for algorithm correctness. We also need to understand that in future there will be VBR traffic (the
moment any L1 split comes into the picture). - Jouni
Rich From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Richard, The logic below you describe does not seem to work if you receive even 1ns late packet as far as I recon – it would keep the packet in buffer for a long time
instead of dropping it. And if you start verifying for that case you are most likely to end up to similar amount of checks as my example algorithm had. Or did I miss something? - Jouni From: Richard Tse [mailto:Richard.Tse@xxxxxxxx]
Jouni Inline
again… Rich From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Richard, Even more
inline ;) From: Richard Tse [mailto:Richard.Tse@xxxxxxxx]
Jouni
From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Richard, See inline From: Richard Tse [mailto:Richard.Tse@xxxxxxxx]
Jouni: 1.
For the timestamps, it looks like the 31 on-the-wire timestamp resides in positions [47:16]. So, are you assuming the least significant 16 bits are fractional nanoseconds?
Is this the error that you said you found in your mask values? [JiK:] Yes. The masks are wrong.. they should be shifted 16 bits to right. 2.
While we don’t mandate the use of PTP time, it will almost certainly be used for RoE applications. Perhaps we should also include a similar example with PTP time. [JiK:] It is likely to be very similar but with a bit more lines of code.. The PTP time stamp structure is not too “binary friendly”. [RTse]
It’s not too bad if we just use the nanoseconds portion of the PTP timestamp format. [JiK:] presumably if that were the solution. a.
On this point, I do not recall why we chose to use a straight binary nanosecond value for the timestamp instead of just using the least significant bits of the PTP time format.
Then, no conversion would be needed and the multiply and divide operations would not be needed. [JiK:] Just cutting & pasting the lowest bits does not work if there is jitter in the network and/or the local vs presentation time fall to different
sides of the “wrap boundary” – but I can be proven wrong. You don’t need multiply/division in your implementation. The example was for informational purposes. I could implement the “internal clock” as a flat counter and adjust it then based on the PTP measurements
etc. [RTse]
Yes, both sides should be aware of the wrap-around condition associated with the timestamp. However, I don’t see this as an issue in practice.
·
The generator of the message should give a presentation timestamp that has sufficient margin to account for the expected maximum network packet delay, packet delay variation,
and PTP time-of-day misalignment at the destination node. This margin guarantees that the message will get to the destination a little before the presentation time occurs. ·
The jitter and maximum PTP ToD misalignment between the nodes would be much smaller than the network delay. ·
The network delay is much smaller than the wrap-around size of the timestamp. ·
If the above three conditions are true, I don’t think there would be any confusion related to the wrap around boundaries of a PTP-based presentation timestamp. [JiK:] So.. say the local time is 199.999995009 and the calculated presentation time is 200.000000009 -> timestamp sent over is 9. Now, if the receiver
happens to receive and timestamp the RoE packet at 199.999999509 the calculated presentation time at the receiver would be 199.000000009. Or how would you ensure the receiver gets the presentation time correct? Since I am usually on the slow side maybe I am
missing something? [RTse]
The receiver should just look at the presentation time and wait until his local PTP ToD (after masking the bits we don’t care about) equals this time before it presents
the info. In this case, the receiver would just wait until the nanoseconds value of its local PTP time = 000000009ns and then it would present the information. Since the receiver’s local PTP ToD is already past 199.000000009 seconds, this equality would
not happen until its local PTP ToD = 200.000000009 seconds.
3.
Finally, do you think the presentation time needs to reach beyond 1, 2, or 4 seconds from the current time? It seems unlikely so, perhaps, just a 30, 31, or 32-bit local
time (not counting fractional nanoseconds) should be sufficient. [JiK:] Even 1s is a lot.. but I had no better use for the excess bits. [RTse]
Yes, 1 second is a lot. This is why I think using the 30-bit integer nanoseconds portion of the PTP timestamp format (which wraps around at 1 second) would be a good
option to use for the RoE timestamps. Despite the non-power-of-two wraparound value, this is still a fairly easy binary implementation. - Jouni Rich From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Jouni Korhonen Folks, We had the discussion today during the call how the 32-bit on-wire timestamp in the RoE header actually relate to PTP time stamp and why the example algorithm is using 64-bit
timestamps instead of e.g. PTP timestamps. (nb. the mask values seem to have a bug now that I looked at it again ;) First, 1904.3 is not mandating PTP, so I did not want to refer PTP timestamps explicitly. Thus, a 64-bit timestamp for my time of day/local time and for simpler math. So,
the algorithm assumes that the e.g. the PTP "local time" is converted to 64-bit nanosecond number. The conversion is rather straight forward but may lose some years from the possible time scale e.g. in a case of PTP time stamp (since PTP time stamp has 48-bit
seconds field). Anyway, 64-bit time stamp in nanoseconds from EPOCH (1 January 1970 00:00:00 TAI) still runs without overflow till mid 2554. Should be enough for few generations to come.
Below is some mock up pseudo code that would do the conversions. (nb. for illustration purposes only – i did not *run* the code ;) After I have the 64-bit time of
day, I tune my “presentation time” maximum distance so that it fits into 32-bit field that I have in RoE header. That’s what the Appendix example algorithm basically does. // PTP timestamp struct Timestamp { uint48_t secondsField; uint32_t nanosecondsField; }; // PTP timestamp to 64-bit nanoseconds uint64_t ptp_tstamp_2_ts64( const struct Timestamp* ts ) { return ts->secondsField * 1000000000LL + ts->nanosecondsField; } // 64-bit nanoseconds to PTP timestamp void ts64_to_ptp_tstamp( struct Timestamp* ts, uint64_t ts64 ) { ts->secondsField = ts64 / 1000000000LL; ts->nanosecondsField = ts64 % 1000000000LL; } --
Jouni Korhonen, CTO Office, Networking, Broadcom Corporation O: +1-408-922-8135, M: +1-408-391-7160 |