| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dear colleagues, Jeff brings up a very good point regarding the existing Idle Insertion state diagrams, and I'd like to thank him for getting the discussion started on the reflector. It will be good to get this discussion underway and hopefully completed prior to the July meeting, which is less than 5 weeks away. At the last meeting we have taken an action item to develop a simulation environment to evaluate of all the state diagrams in Clause 92. Among other things, we have attempted to verify where the system is broken, where the system needs improvement, and where the system is working as it should. At this point in time, the environment is not fully done, but once complete, we will release the simulation environment to anyone in the Task Force that would like it. The final results of all state diagrams will hopefully be presented during the July meeting. As we got into our simulations, it became evident very quickly that the Idle Insertion block was responsible not only for a large amount of delay, but also for a varying amount of delay. We have iterated several times on improvements to the state diagram, and the new proposed diagram can be found in the attached presentation. The presentation also includes a comparison of the simulation results of the current state diagram in D1.8022 and the proposed one. We feel that the new diagram eliminates the variability, and the simulation results back this up. That being said, I think the Task Force recognizes that no new changes can be made to this intermediate draft, and that only improperly implemented comment responses can be acted upon right now. New changes can be made based off of new comments submitted for the July meeting. Based off of our simulation results, I'm planning on submitting a number of comments against the next draft. In the meantime, I look forward to having a good discussion on this and Jeff's proposals over the next couple of weeks. Eric Lynskey Teknovus -----Original Message----- From: Jeff Mandin [mailto:Jeff_Mandin@PMC-SIERRA.COM] Sent: Tuesday, June 10, 2008 8:21 AM To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG Subject: [8023-10GEPON] Idle insertion in Rx PCS All, 1. In the course of the discussion of comment 1458 in Munich, the issue of maintaining acceptable latency variation in the Rx PCS came up once again.. It was noted that the current state diagrams are broken and that a jitter buffer is required to guarantee uniform latency. Attached are revised figures 92-22, 92-26 and 92-27 (numbering from draft d1_8022) which include the jitter buffer. 2. This fix is independent of the method used for FEC_overhead() equations. However, any analysis done on the FEC overhead equations should take this into account. 3. The basic idea is that the II_FIFO[] is the length of 8 parity regions (ie. the maximum number that can occur in a packet). All received codes pass through the FIFO. The location of the parity regions is noted and the parity regions are counted up. After the frame terminates, the PCS inserts number of IDLEs corresponding to the amount of deleted parity. Put even more simply: the receiving PCS inserts the IDLEs following the frame, just as the transmitting MPCP ensures that the extra IDLEs follow the frame. 4. The figures in the current draft lack this buffering, and consequently there is significant variability in the frame latency depending on the length of the frame ie. the existing Figure 92-26 bumps the FrameReadyCount right after /T/ is received from the 66b decoder. In the case where a 64byte frame terminates in the last octet of a FEC codeword, the frame will be delayed one parity region (ie. 264 PMA bit times). Whereas a 1522 byte frame which terminates in the first octet of a FEC codeword will be delayed 8 full codewords (ie. 16320 PMA bit times). This delay variation is much greater than the 1TQ that is permitted. Specifically, if we look at lines 17-18 of current figure 92-27, we see that the amount of time that a frame is retained in the II_Fifo depends on when FrameReadyCount is bumped, for which we look to current figure 92-26 to see that it depends directly on the length of the frame. 5. Consequently, this change is necessary for technical completeness of the draft. Feedback is appreciated. Thanks, - Jeff Mandin PMC-Sierra
idle_insertion_improvements.pdf