If a new time synchronization protocol is defined in the future with a different timestamp format, a new PKT_TYPE could even be defined
to be compatible with it. However, at this moment in time, PTP would be used. So, I think that we should define 1903.4 to work with it.
Rich
From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Jouni Korhonen
Sent: Thursday, November 12, 2015 7:47 AM
To: du.chao@xxxxxxxxxx; 'stds-1904-3-tf@xxxxxxxx'
Subject: RE: 32 bit timestamps over the wire
Hi,
Nothing against PTP.. and it is likely most deployments will rely on the presence of PTP. However, what I want to avoid is the 1904.3 specification stating
like “must support” or “must deploy” PTP for RoE to work. Keeping that in mind the possible timestamp solution cannot be hardcoded to PTP.
- Jouni
From:
du.chao@xxxxxxxxxx [mailto:du.chao@xxxxxxxxxx]
Sent: Wednesday, November 11, 2015 9:47 PM
To: 马世佳
Cc: Jouni Korhonen; 'Richard Tse'; 'stds-1904-3-tf@xxxxxxxx'
Subject: 答复: 32 bit timestamps over the wire
Jouni
Maybe we can absolutely employ PTP to realize synchronization, then what we want to do is just to reserve a little transmission bandwidth for the PTP package on the ROE link
杜超 Du Chao
BBU系统部
/ 无线产品经营部
BBU R&D center / Product R&D-Wireless Product Operation
|
|
|
|
马世佳 <mashijia@xxxxxxxxxxxxxxx>
2015/11/12 10:24
|
|
Jouni,
I always confused the meaning of timestamp, which is the time of receiving packet or sending packet in the air interface? Or the time of encapsulation for ROE ?
Thanks.
马世佳
移动研究院千人计划创新基地3-绿色通信研究中心
地址：北京市西城区宣武门西大街32号中国移动创新大厦18层，100053
电话：010-15801696688-36058
Mobile:：13910391546
邮箱：mashijia@xxxxxxxxxxxxxxx
发件人:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
代表 Richard Tse
发送时间: 2015年11月12日 9:52
收件人: Jouni Korhonen;
stds-1904-3-tf@xxxxxxxx
主题: RE: 32 bit timestamps over the wire
Jouni
Inline
again…
Rich
From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Sent: Wednesday, November 11, 2015 10:13 AM
To: Richard Tse; stds-1904-3-tf@xxxxxxxx
Subject: RE: 32 bit timestamps over the wire
Richard,
Even more
inline ;)
From: Richard Tse [mailto:Richard.Tse@xxxxxxxx]
Sent: Wednesday, November 11, 2015 1:14 AM
To: Jouni Korhonen; stds-1904-3-tf@xxxxxxxx
Subject: RE: 32 bit timestamps over the wire
Jouni
More inline.
Rich
From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Sent: Tuesday, November 10, 2015 10:00 PM
To: Richard Tse; stds-1904-3-tf@xxxxxxxx
Subject: RE: 32 bit timestamps over the wire
Richard,
See inline
From: Richard Tse [mailto:Richard.Tse@xxxxxxxx]
Sent: Tuesday, November 10, 2015 6:20 PM
To: Jouni Korhonen; stds-1904-3-tf@xxxxxxxx
Subject: RE: 32 bit timestamps over the wire
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
Sent: Tuesday, November 10, 2015 5:04 PM
To: stds-1904-3-tf@xxxxxxxx
Subject: 32 bit timestamps over the wire
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
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.