D2.0 49.2.11.1.1 Constants E

[Alex Deng <adeng@xxxxxxxxx>]

Hi Pat,

I still think your definition of "E" is not accurate.

If I followed your definition of "E", just as I said last time,
if a packet I got from XGMII/XAUI is something like:
     ECCC/CCCC
     CCCC/SDDD ( or SDDD/DDDD)
     DDDD/DDDD
     ....
     TCCC/CCCC
will be transmitted like: E (Frame) -->E --> D ....-->T.
On the receiver side, this packet will be trashed.

But other packets like:
    CEEE/EEEE  (or CCCC/EEEE or CECC/EECC ...)
    EEEE/SDDD (or SDDD/DDDD or CEEE/SDDD ...)
    DDDD/DDDD
    ....
    TCCC/CCCC

will be transmitted like: C (Frame) -->S-->D...-->T.
On the receiver side, these packets will not be trashed.

That means this protocol is not consistent.

Thanks,

--Alex

Alex Deng wrote:

> Hi Pat,
>
> If this is the case, that means if a packet transmited like
> ECCC/CCCC     ---->E
> CCCC/SDDD     ---->E
> ...
> will be trashed,
>
> but a packet transmite like
> CEEE/EEEE     ----> C
> SDDD/DDDD  ----> S
> ...
> will not.
>
> Thanks,
>
> --Alex
>
> pat_thaler@xxxxxxxxxxx wrote:
>
> > Alex,
> >
> > I don't ever generate an ECCC/SDDD unless that is what I got from the
> > XGMII/XGXS. We don't have a Hamming distance need to propogate an error from
> > the XGMII/XGXS column before an S into the packet and the 10GBASE-X based
> > Phys won't don't discard such a packet. Therefore, it is fine as it stands.
> > An ECCC/SDDD is an S. A frame with 8 control characters and the first
> > character is an E so that the receiver will recognize an E frame sent by the
> > transmitter as an E frame. All 8 characters will be E in that case, but it
> > seemed burdensome to check for 8 Es and the first character being an E is
> > enough.
> >
> > If you do not agree, submit a comment.
> >
> > Pat
> >
> > -----Original Message-----
> > From: Alex Deng [mailto:adeng@xxxxxxxxx]
> > Sent: Tuesday, December 05, 2000 4:08 PM
> > To: THALER,PAT (A-Roseville,ex1)
> > Cc: stds-802-3-hssg@xxxxxxxx; Alex Deng
> > Subject: Re: D2.0 Figure 49-7
> >
> > Hi Pat,
> >
> > Another question:
> >
> > Page 297, 49.2.11.1.1 Constants
> > Following your definition, looks like ECCC/SDDD is a S,
> > but it should be a E, right?
> >
> > Thanks,
> >
> > --Alex
> >
> > "THALER,PAT (A-Roseville,ex1)" wrote:
> >
> > > Alex,
> > >
> > > Looks like I made a cut and past error. The type field for CCCC/ODDD
> > should
> > > be 0x2d. Since we are in task force ballot, a comment needs to be
> > submitted
> > > to correct this. Will you put a comment in on it? If not, I will.
> > >
> > > Pat
> > >
> > > -----Original Message-----
> > > From: Alex Deng [mailto:adeng@xxxxxxxxx]
> > > Sent: Tuesday, December 05, 2000 2:28 PM
> > > To: THALER,PAT (A-Roseville,ex1)
> > > Cc: stds-802-3-hssg@xxxxxxxx; Alex Deng
> > > Subject: D2.0 Figure 49-7
> > >
> > > Hi Pat,
> > >
> > > In Figure 49-7 -64b/66b Frame Formats:
> > > The "Type Field" of the first and second row are the same "0x1e".
> > > What's the type field for C0C1C2C3/O4D5D6D7 ?
> > >
> > > Thanks,
> > >
> > > --Alex