RE: D1.1 Clause 49 State Machine comments
Alex,
Rick Walker had checked that out. See page 13 of walker_1_0700. The
red line for 50% BER covers that case since the scrambler will cause
occurance of an invalid sync header 50% of the time when you are not
at the right position. However, lock would occur faster if the threshold
for moving to the next candidate was lower.
I'm sure it works the way it is, but I like your suggestion of a
lower threshold for bad_sh when not in lock. It is just a decision
I feel has to be made next week rather than something an editor can
change.
Pat
-----Original Message-----
From: Alex Deng [mailto:adeng@xxxxxxxxx]
Sent: Thursday, November 02, 2000 4:37 PM
To: pat_thaler@xxxxxxxxxxx
Cc: stds-802-3-hssg@xxxxxxxx; shprasad@xxxxxxxxx
Subject: Re: D1.1 Clause 49 State Machine comments
I belive you have tested there will be no other positions will have 64
continuous
valid sync_head. I don't know if you have some extreme cases that
good_sh_eq_64
always= false, and bad_sh alwyas <32, you will stuck on NO_FRAME_LOCK.
Will this happen?
pat_thaler@xxxxxxxxxxx wrote:
>
> 5. Come back to Figure 49-8 on page 184:
> I still prefer from 'NO_FRAME_LOCK" to "SLIP" should
> use"sh_valid=false",
> not
> "bad_sh_eq_32=true".
> a. You also can see from Figure 36-9 in 802.3-1998, before it enter
> "SYNC_ACQUIRED"
> state, every time when they detect a single code error, it go
> back
> to the beginning state
> "LOSS_OF_SYNC".
> b. In your reply to my last comment, you said "It is cleaner to have
> the
> counter
> controlled by one machine and the new machines are more closely
> interlinked."
> but in my proposal, there is only one state machine.
>
> Response: The code you had above is another state machine even if it is
> typed rather than drawn. The state machines I've put into 49-8 generally
> execute the algorithms that were approved in the proposal for acquiring
> lock. You are suggesting different algorithms. I think making a lower
> threshold for the transition from NO_FRAME_LOCK to SLIP has merit, but
> I feel that it is a substantive enough change from what 802.3ae voted to
> adopt that it would need logic track agreement to modify it. I did make
> substantive changes to the Transmit and Receive machines modifying the
> conditions when /E/ was sent, but that was based on September's logic
> track discussion and input.
>
> Regards,
>
> --Alex Deng
> -----------------------------------------
> Alex Deng
> Cisco
> 408-853-8170
> adeng@xxxxxxxxx
> -----------------------------------------