Re: Hari and train-up sequences
Linda,
I heartily agree with you. Separately from initial power-up of both link ends
simultaneously there are many scenarios which can be encountered where 10 GbE link
operation is unreliable and would benefit from re-initialization. These scenarios
include:
- Transmitter powered up but receiver powered down;
- Receiver looses signal;
- Receiver looses sync on one or more lines and cannot regain sync (Note: loosing
sync denotes a link problem, no change from the transmitter's pattern will not
likely resolve the problem;
I fully support Linda's call for the definition of a link initialization sequence
which
a) notifies all link elements that link initialization is in progress
b) is easily distinguishable from the normal Idle/Data stream
Note that both the Hari byte-striping and word-striping proposals benefit equally
from the definition of a link initialization sequence.
Best regards,
Rich
--
Linda Cheng wrote:
> Hi all,
>
> A general comment about link initialization... Although sending Idles
> is sufficient for deskew given the remote side is receiving them, it
> is not enough to ensure proper link initialization. For example, the
> receiving side may not be "plugged in", or it may have just booted. If
> the receiving side doesn't receive enough idles or any idles, it may
> not be able to deskew properly.
>
> There should be a link initialization defined so that before a station
> transitions from transmitting its idle sequence to transmitting
> frames, it knows that the station at the far end has synced up (found
> commas, PLLs are locked, finished deskew). This sequence will be
> useful not only during system bootup, but also when loss of sync
> occurs following normal operation.
>
> I realize that adding Autonegotiation as an PAR objective failed in
> York. I take this as a backlash to complexity involved in using fast
> link pulses to distiguish between 1Gig and 10Gig. Its good to keep
> things sweet and simple, however, we should not throw out useful and
> needed functions served by Autonegotiation. For one, we are going to
> need some form of link init. This is as simple as a two part handshake.
> Going one step further, I think its a minor increment to send PAUSE
> information during link init so that system admins don't have to
> think about how to set up their networks. This is especially useful
> when stations speak asynchronous Pause.
>
> Linda
>
> > Date: Sun, 14 Nov 1999 18:54:28 -0800
> > From: Rich Taborek <rtaborek@xxxxxxxxxxxxx>
> > To: HSSG <stds-802-3-hssg@xxxxxxxx>
> > Subject: Hari and train-up sequences
> >
> > The purpose of this note is to clear up confusion regarding Hari, a
> > proposed 4-lane serial interface for 10 GbE and train-up sequences.
> >
> > It should be clear that NO TRAINING SEQUENCES are proposed for Hari.
> > Both the "Hari Coding Objectives" presentation
> >
> (http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/taborek_1_1199.pdf)
> > and "Word Striping on Multiple Serial Lanes"
> > http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/ritter_1_1199.pdf)
> > make a point of noting that no train-up is required Hari to deskew.
> >
> > The Hari Coding Objectives proposal uses the standard Idle sequence
> > proposed by Howard Frazier of Cisco to deskew multiple parallel lanes
> > while simultaneously acquiring code-group synchronization on all lanes.
>
> ---------------------------------------------------------------
> Linda Cheng Cisco Systems
> Desktop Switching Business Unit
> (408) 527-2015 (phone) 170 West Tasman Drive
> (408) 527-4698 (fax) San Jose, CA 95134-1706
> ---------------------------------------------------------------
----------------------------------------------------------
Richard Taborek Sr. 1441 Walnut Dr. Campbell, CA 95008 USA
Tel: 408-370-9233 Cell: 408-832-3957 Fax: 408-374-3645
Email: rtaborek@xxxxxxxxxxxxx