Re: [EFM-P2MP] Comment resolution help
Lior,
Thanks for your response. Could you provide new text to fill this
section in?
The information below doesn't provide the level of detail necessary by this
scribe.
Apparently there are some related comments, 234 and 232 among them,
that should be considered as well.
Are there others out there with opinions? Let's keep the replies on the
reflector so the conversation doesn't drag to a halt if I don't check my
email
for a day or 2.
Thanks,
Ben
Lior Khermosh wrote:
>I think that an alternative way would be to bound the code group alignment
>time (maybe overlaps to CDR lock time?). During that time I think that the
>behavior of the alignment mechanism is not really a concern. If that is a
>reasonable way then what would you consider to be the bound, or could we
>just say that it is included in CDR lock time?
>
>Best Regards,
>Lior
>
>
>-----Original Message-----
>From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
>[mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org]On Behalf Of
>Benjamin Brown
>Sent: Monday, June 16, 2003 5:21 PM
>To: 802.3ah_p2mp
>Subject: [EFM-P2MP] Comment resolution help
>
>
>
>
>All,
>
>I've received a comment from Piers that makes some amount of sense to
>me but doesn't offer a concrete solution. I'll try to work something up
>before next week but in the meanwhile, if anyone has some ideas before
>the meeting, I'd love to hear them.
>
>Thanks,
>Ben
>
>65.3.4, Page 591, Line 43
>
>Comment:
>
>Statement that "T_Code_group_align is defined in CROSS REF 36.3.2.4,
>value is less than 4 octets." doesn't seem to be fully supported by
>36.3.2.4, which says "In the event the PMA sublayer detects a comma+
>within the incoming rx_bit stream, it may realign its current code-group
>boundary, if necessary, to that of the received comma+ as shown in
>Figure 36–3." May, not shall. And then "During the code-group alignment
>process, the PMA sublayer may delete or modify up to four, but shall
>delete or modify no more than four, ten-bit code-groups in order to
>align the correct receive clock and code-group containing the comma+.
>This process is referred to as code-group slipping." That's 4 slips max,
>not a maximum time - it doesn't say it must slip at each comma+.
>
>If the burst's training sequence is idles, doesn't only every other
>code-group contain a comma? That would be 8 code-groups at best, not 4?
>
>Suggested Remedy:
>
>Write out explicitly what a PMA has to do to be usable in burst mode.
>
>
>--
>-----------------------------------------
>Benjamin Brown
>178 Bear Hill Road
>Chichester, NH 03258
>603-491-0296 - Cell
>603-798-4115 - Fax
>benjamin.brown@ieee.org
>-----------------------------------------
>
>
>
>
>
--
-----------------------------------------
Benjamin Brown
178 Bear Hill Road
Chichester, NH 03258
603-491-0296 - Cell
603-798-4115 - Fax
benjamin.brown@ieee.org
-----------------------------------------