RE: [802.3ae] D3.1 Clause 45 and Clause 48 potential inconsistenc ies
Pat,
I think that in this case the Draft should be written
in a better way. Following this thread, I think that
the term "detect a local fault" is defined in a very
general and not accurate way. And even you admitted
that there is an un-necessary duplication. You may fix
it or not; But the problem is not "misreading the
spec" as you wrote. As a matter of fact, I think it
was read very carefully. I think that you should be
thankful for such comments.
Regards
James
> -----Original Message-----
> From: THALER,PAT (A-Roseville,ex1)
[mailto:pat_thaler@xxxxxxxxxxx]
> Sent: Tuesday, July 24, 2001 10:06 PM
> To: Boaz Shahar
> Cc: HSSG (E-mail)
> Subject: RE: [802.3ae] D3.1 Clause 45 and Clause 48
potential
> inconsistenc ies
>
>
> Boaz,
>
> I agree with Rich. I notice that you consistantly
misread the
> text of clause
> 45. Whenever it says "detects a local fault
condition" you quote it as
> "detects an LF condition" and this seems to be the
source of the
> misunderstanding. The former means that the the
device has
> detected a fault
> in itself. The fault could be an inability to sync
to the
> incoming signal or
> it could be an implementation dependent fault
detection capability.
>
> We have no requirements (and no options) for any
sublayer
> except the RS to
> detect an incoming LF signal and we specify no rules
for such
> detection
> except at the RS. That is why there are no bits in
Clause 45
> for "detects an
> LF signal". There are only bits that are set when a
local
> fault condition is
> detected.
>
> Regarding your question about the apparent
duplication of local fault
> reporting bits. I have never understood why in
status
> register 1 we have a
> bit that indicates that the receive link is up while
in
> status register 2 we
> have a bit that indicates it's inverse - a receive
local fault. (Note
> however that, since they both latch, they may not at
a given
> time contain
> inverse values. One may have been cleared by reading
while
> the other still
> is latched.) The duplication has fallen below my
personal
> threshold for
> raising a comment. Since in Status register 1 never
has many
> bits used and
> the other bits in Status register 2 generally report
static
> information such
> as abilities, it would be logical to move the
receive and
> transmit local
> fault detection bits to status register 1 and to
remove the
> receive link up
> bit.
>
> The bit in 5.24.12 is different than the bits in
status
> registers 1 and 2 in
> two significant ways. First, it only indicates a
failure to achieve
> alignment to the incoming signal while the other two
bits can reflect
> implementation dependent fault detection. Secondly,
it is not
> latched. The
> bits in the lane status registers represent a
snapshot of the
> status of the
> receive link synchronization: the status of each
lane plus
> the ability to
> deskew across the lanes.
>
> Regards,
> Pat Thaler
>
>
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/