| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Kevin:
·
Because the delay through an Ethernet network is not constant, we can never get by using
only sequence numbers. Sequence numbers alone can be used to communicate the frequency of a signal, but they cannot be used to measure the delay or align the phase. At some time, you will need to use a timestamp to get this information.
o
One packet’s worth of radio data arrives every 10ms (in the radio’s timescale) at the RoE sender
o
One packet’s worth of radio data is presented every 10ms (in the radio’s timescale) at the RoE receiver
o
There is a 15ms constant delay (in the Ethernet’s timescale) between the arrival and the presentation events
o
The above achievements are easier to implement with the data path mechanisms shown in Example 1
·
Constant data rate:
o
If timestamps are used for timing recovery, then sequence numbers should not be. Sequence numbers could be used for detection of missing packets, reordering, or communication of a non-timing aspect
of the radio protocol.
o
In my concept, the presentation time is the time when the first byte of the RoE data is “pushed out” of the RoE Packet buffer of the RoE receiver.
§
If every packet is pushed out at the specified presentation time, the RoE Packet buffer will never overflow or underrun during steady-state operation.
§
The important timing event is when the first byte is “pushed out”. How the rest of the packet’s data is stored and processed is an implementation issue.
§
A PLL can use the very low-noise and very repetitive “push out” events to regenerate the original radio clock very cleanly.
·
Variable data rate:
o
The contents of the RoE packet are “pushed out” of the RoE Packet buffer whenever the presentation time arrives. The RoE packet buffer will never overflow. I believe the scenario presented by Jouni at the February plenary and in my example is real. What other ways can this application be solved? Rich From: Bross, Kevin [mailto:kevin.bross@xxxxxxxxx] Thanks for putting this together. A few comments: ·
We had previously discussed in our meetings that sequence numbers would be used for constant data rate uses (like tunneling and agnostic modes) and for control packets; the use of sequence numbers allows you to determine if you
have missed a packet in these cases. The cases where you have variable (non-constant) traffic are where it makes the most sense to use timestamps. Both of these scenarios have some issues if timescales on each end diverge. ·
Constant data rate:
o
If timestamp and sequence number are used, which has priority if there’s a conflict?
o
Suppose a constant rate queue hasn’t emptied by the time a timestamped packet comes in: do you delay the timestamped data until the queue has emptied, or do you drop bits/bytes to deliver that data according to the timestamp?
o
Conversely, suppose the timestamp for a constant rate flow is slightly after the time that the queue empties: do you repeat old bits, or do you glitch the data stream to align with the new timestamp?
o
If it’s a constant rate flow, I don’t see value in timestamps (other than in starting and stopping the flow through control packets). ·
Variable data rate:
o
Variable rate data expects to have some gaps, so an under-run isn’t a problem; but what about an over-run?
o
Suppose packet N has 600 bytes of data to be sent at a specific time and at the rate that was identified when the flow was set up. Now suppose packet N+1 comes in with a presentation time that indicates a presentation time slightly
before all 600 bytes have been sent—what do you do in such an instance? For constant rate data, I don’t think we should do anything in RoE to re-align timescales. I think that the RoE equipment should adapt their clocks to match the timing of their time references, whether that’s GNSS, cesium oscillator, SyncE,
1588, or other mechanisms. In the case of 1588, the ITU-T recommendations are to do a minimum of 16 sync messages per second, so the RoE equipment should receive time updates frequently through that protocol—and we don’t need to replicate that in RoE. Even
worse, the mechanism in RoE could conflict with more mature technologies available to RoE members. --kb ------------------------------------------------------------------ From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Richard Tse 1904.3 members: As a follow up to the discussion we had at the Feb/2016 plenary, I would like to look more deeply at data path vs control path time distribution mechanisms when the client and the Ethernet network have different timescales. Please see
the attached presentation. We can discuss this at the next call on Tuesday.
Richard Tse Senior Principal Engineer Microsemi 8555 Baxter Place Burnaby, BC Canada V5A 4V7 Phone: +1-604-415-6015 Email: Richard.Tse@xxxxxxxxxxxxx Web: www.microsemi.com
|