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