| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hello, Hidekazu and all,
It's like we're in the meeting room.
I totally agree to your argument.-- about the definition of RTT.
For the reference point, I also agree.
One thing I'd like to mention is the need for bounding the delay of rx and tx processing of the ONU.(or OLT)
if the processing delay is not bound, a poor implementation makes the RTT value too big that the procesing delay plays the dominant part of the RTT formation. (remember, the fiber delay is about 200 usec round-trip in 20 km fiber)
putting processing latency bound of 20 or 30 usec doesn't do any harm.
One more thing --
To receive variable length packets with the same receiver circuit, we need constant delay through the CRC verification.
this delay should be the same for long frame or short frame. Just storing received frames with the CRC check result and reading the frames at the other end of the FIFO whenever there's any valid received frame does not work. It makes the inter-frame distance change, as a result, it makes the delay changed for frames. For example, it takes a long time to read out a long frame from the FIFO, but a short frame following the long frame with some inter-arriaval distance gets read right away after the reading-out of the former long frame finishes. We need to keep the inter-frame distance up to the point where we extract the time stamp.
That's what I liked to say.
Regards,
Chan
원본 내용:
보낸사람: Hidekazu Miyoshi[miyoshi-hidekazu@sei.co.jp]
받는사람: stds-802-3-efm-p2mp@ieee.org
제목: RE: [RE] [EFM-P2MP] Definition of Timestamp in MPCP messages
받은날짜: 2003/05/06 화 20:12
Hello, Chan and Antti,
I agree with most of the Chan's opinion except the need for an upper
bound of the transmit + receive latency (25usec or 30usec). Chan pointed
out a case where longer frames are exchanged, but we are now focusing on
a discussion of TIMESTAMPs in MPCP messages, which are a fixed size of
64 Byte. So I think the issue can be simpler.
Let me summarize this issue briefly. In the current draft, RTT includes
certain times other than just a propagation time on fiber and processing
delay of a higher layer. If we suppose that the reference point of
TIMESTAMP is the time of transmitting the first bit of a MPCP message
from the MAC layer, RTT would contain below times.
A: Processing time of the lower layer at a sender
B: propagation time on fiber
C: time to receive a whole frame at a receiver
D: processing time of the lower layer at a receiver
E: time to examine the frame validity at a receiver
One big issue is whether or not RTT should indicate exactly the
propagation time on fiber (B). In my opinion, I don't see any problem if
RTT includes all the times shown above. Since the size of MPCPDU is
fixed to 64Byte, the times required A, C, D and E are almost constant.
Thus, as long as these delays are within the delay variation, no more
than 32 bit times, defined in the current draft, considering these
delays into RTT does not cause any problem. All we have to do is
defining a reference point. That's it. We don't have to introduce any
other parameters. I hope this would make our life easier.
Regards,
Hidekazu