RE: Minimum IPG w/ WIS ?
Certainly Idle insertion and deletion must happen before 64/66 encode and
after decode since the 64/66 encoding depends on the number of idles.
Cheers,
Paul
At 09:54 AM 2/21/2001 -0800, Julio.Hernandez@xxxxxx wrote:
>Mike,
>
>WRT;
>Mike > Yes, the original 12 byte IPG is considered part of
>Mike > the payload in the WIS, so the stretching of the IPG
>Mike > must account for this by adding these 12 bytes into
>Mike > the payload portion of the equation.
>
>Thanks for the confirmation. (-:
>
>WRT:
>Mike > And since what is placed in the sonet frame might as
>Mike > well be considered jibberish in the sonet world,
>Mike > there's no way of extracting these needed idles prior
>Mike > to placing the stream within the sonet frame, to reduce
>Mike > the payload. Nor is there any way to re-introduce
>Mike > these needed idles on the other end when the ethernet
>Mike > stream is extracted from the sonet frame.
>
>I am probably not the right person to authoritatively answer
>this for you, but from my perspective, this is not a accurate
>statement.
>
>This is absolutely possible, and performed by vendor implementation
>specific elasticity FIFOs before the Encoder, and after the Decoder.
>
>Mike > The part I'm still fuzzy on is on the transmit side of this,
>Mike > where this "ethernet stream" is created. Which block
>Mike > handles removal of these stretched IPG bytes, so we only
>Mike > send 12+pkt in the sonet frame? Is it the 64b/66b, the
>Mike > WIS, or the gearbox? It has to be pre-scrambling of the
>Mike > stream, that's obvious, but is it pre-encoding?
>
>See previous answer ...
>
>
>Best Regards,
>Julio
>
>
>
>
>
>Mike Bly <Mike.Bly@xxxxxxxxxxxxxxxxxxxx> on 02/21/2001 08:49:37 AM
>
>To: "'THALER,PAT (A-Roseville,ex1)'" <pat_thaler@xxxxxxxxxxx>, Julio
> Hernandez/SSI1@SSI1, stds-802-3-hssg@xxxxxxxx
>cc:
>Subject: RE: Minimum IPG w/ WIS ?
>
>
>
>
>Julio,
>
>Yes, the original 12 byte IPG is considered part of the payload in the
>WIS,
>so the stretching of the IPG must account for this by adding these 12
>bytes
>into the payload portion of the equation.
>
>We are actually sending ethernet idles in the sonet frame's payload
>along
>with the ethernet packets. I don't claim to be an expert on why, but
>I'll
>try not to butcher it too badly. It has to do with the encoding schemes
>requiring N number of codes between packet's in order to guarantee
>recognition of said packets, when the descrambled ethernet stream (which
>was
>extracted from the sonet frame, post-transmission) is presented to the
>64b/66b decoder and/or 8b/10b decoder. And since what is placed in the
>sonet frame might as well be considered jibberish in the sonet world,
>there's no way of extracting these needed idles prior to placing the
>stream
>within the sonet frame, to reduce the payload. Nor is there any way to
>re-introduce these needed idles on the other end when the ethernet
>stream is
>extracted from the sonet frame.
>
>The part I'm still fuzzy on is on the transmit side of this, where this
>"ethernet stream" is created. Which block handles removal of these
>stretched IPG bytes, so we only send 12+pkt in the sonet frame? Is it
>the
>64b/66b, the WIS, or the gearbox? It has to be pre-scrambling of the
>stream, that's obvious, but is it pre-encoding?
>
>Regards,
>
>Mike
>
>-----Original Message-----
>From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@xxxxxxxxxxx]
>Sent: Tuesday, February 20, 2001 5:39 PM
>To: Julio.Hernandez@xxxxxx; THALER,PAT (A-Roseville,ex1);
>stds-802-3-hssg@xxxxxxxx
>Subject: RE: Minimum IPG w/ WIS ?
>
>
>
>Julio,
>
>First off, the minimum IPG does not occur in the WIS case. IPGs at the
>receiving RS will tend to be much longer than the minimum because the
>receiving PCS will put the data rate back up to 10 Gb/s reinserting the
>bytes that the transmitting PCS stripped out (plus or minus a little
>because
>of clock compensation).
>
>So IFS stretch isn't particularly relevant to your question. However, I
>will
>point out that I do not get same results as you for IPG sizes with WIS.
>The calculation for IFS stretch is:
>
>ifsStretchSize := (ifsStretchCount + headerSize + frameSize +
>interFrameSpacing) div ifsStretchRatio
>
>which is for a min frame the integer part of (64 + 512 + 96 plus 0 to
>104 in
>ifsStretchCount) divided by 104 which means IFS stretch for a min size
>frame
>is 6 to 7
>
>For a max frame, 512 becomes 1522 * 8 for a stretch of 118 to 119
>octets.
>
>These are the IPG sizes going into the RS. Coming out of the RS some
>IPGs
>may be shrunk or enlarged by up to 3 octets to align the Start to lane
>0.
>
>These numbers shouldn't be surprising because the payload capacity of
>WIS is
>about 8% less than 10 Gb/s.
>
>So, what does cause the minimum IPG. When attached to a LAN Phy, the MAC
>puts out a minimum IPG of 96 BT = 12 octet times.
>
>The RS may delay the start of a packet up to 3 octet times to align it
>to
>lane 0 and it may not need to delay the start of the next packet at all.
>Therefore, the RS can shrink any individual IPG by up to 3 characters.
>Note
>that this doesn't change the average of IPG lengths. Those 3 characters
>will
>eventually show up added to IPGs when the RS again delays the start of
>packets. It is a jitter in packet start rather than a loss of overall
>idle
>time. Never the less,
>minimum IPG out of an RS is 9 characters.
>
>If a sublayer doing clock compensation has just reached the FIFO level
>where
>it wants to delete an idle column, then it will delete it when it gets a
>chance. That might be just as that 9 character IPG arrives and it will
>delete 4 characters from it leaving a 5 character IPG. As you point out,
>it
>won't need to delete again for quite a few columns. (However, you should
>find that it may worst case to delete one in every 50,000 columns rather
>than one in 100,000 because the incoming clock worst case is +100 PPM
>and
>the outgoing clock is -100 PPM for a difference of 200 PPM.)
>
>Of course, each XGXS and each PCS in the link may be doing clock
>compensation. That is unlikely, but each of these sublayers is allowed
>to.
>So there can be up to 6 sublayers doing clock compensation in a path. It
>is
>possible for each of them to be running slightly slower than the one
>before
>it. Then on a very improbable moment, all their FIFOs could reach the
>point
>where they want to delete idle at the same time. If packets are being
>sent
>with minimum IPG, they won't all get to delete in the first IPG. They
>will
>shorten IPGs to the minimum until each of them has had a chance to
>delete a
>column. Over times, all of the deletions will average to one out of
>every
>50,000 columns or less, but in the worst case, 6 of those deletions
>could be
>clumped close together.
>
>I hope this clarifies the process for you.
>
>Regards,
>Pat
>
>
>-----Original Message-----
>From: Julio.Hernandez@xxxxxx [mailto:Julio.Hernandez@xxxxxx]
>Sent: Tuesday, February 20, 2001 4:25 PM
>To: pat_thaler@xxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
>Subject: RE: Minimum IPG w/ WIS ?
>
>
>
>
>Pat,
>
>I have been tracking this IPG thread, because I too am trying
>to understand what is intended for minimum IPG (actually IFG -
>Inter Frame Gap, no ?) in the 10Gb/s WIS application, and I
>would like to pose the following observation for clarification
>by those who understand it better.
>
>If I read the algorithm correctly in section 4.2.8, specifically
>page 32, lines 16-22, it looks like the MAC is taking the minimum
>IPG/IFG called out in the table in section 4.4.2 (page 41, lines
>15-16), into account when counting bits to determine its "stretch
>size" (bytes/octets that will be added in the IFG/IPG to adapt for
>the WIS rate). As well as, the preamble and SFD bytes (header size).
>
>So, if I understand it all correctly, that should mean that in a
>PCS+WIS application, the MAC generated data stream into the XGMII
>inputs of the PCS will contain:
> 1. 12 bytes/octets minimum of IPG/IFG for a minimum size
> packet/frame per frame, and
> 2. 26 bytes/octets minimum of IPG/IFG for a maximum size
> packet/frame per frame
>In both cases the "interFrameGap" AKA "interFrameSpacing" as
>defined in the present version of D2.1, is maintained.
>
>My confusion comes in with the note on page 41, lines 42-45,
>in section 4.4.2, as you were discussing earlier;
>This notes says that this "interFrameGap shrinkage" to 5
>bytes/octets is;
> "... as measured at the XGMII receive signals at the DTE."
>
>Keeping in mind that +/-100ppm is only one 4-byte column to
>be deleted/added every 10,000 4-byte columns, worst case.
>I guess I am not clear on how this would ever bring the IFG/IPG
>down to 4-5 bytes (1 column) of IPG/IFG on a frame-by-frame
>basis ?
>
>Your clarification on this matter would be sincerely
>appreciated. (-:
>
>Thanks, & Best Regards,
>Julio
>==================================================
>
>
>
>
>pat_thaler@xxxxxxxxxxx on 02/20/2001 01:02:24 PM
>From: pat_thaler@xxxxxxxxxxx on 02/20/2001 01:02:24 PM
>To: sanjeev@xxxxxxxxx, pat_thaler@xxxxxxxxxxx, pat_thaler@xxxxxxxxxxx,
> stds-802-3-hssg@xxxxxxxx, yariv@xxxxxxxxxxxxx
>cc:
>Subject: RE: RS minimum IPG
>
>
>
>
>
>Sanjeev,
>
>I can't quite parse what you've said. In any case, Shimon has pointed
>out
>where it is specified in 4.4.2. Note that the numbers in 4.4.2 are
>
> 10 Mb/s 47 BT
> 100 Mb/s not specified
> 1 Gb/s 64 BT
> 10 Gb/s 40 BT (= 5 Phy characters)
>
>As you can see, consistancy between speeds was not particularly a goal.
>
>Pat
>
>-----Original Message-----
>From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
>Sent: Tuesday, February 20, 2001 12:45 PM
>To: pat_thaler@xxxxxxxxxxx; pat_thaler@xxxxxxxxxxx; sanjeev@xxxxxxxxx;
>stds-802-3-hssg@xxxxxxxx; yariv@xxxxxxxxxxxxx
>Subject: RE: RS minimum IPG
>
>
>
>At 01:10 PM 02/20/2001 -0700, pat_thaler@xxxxxxxxxxx wrote:
> >I dashed off my response too quickly. I meant to say "I don't know of
> >anyplace a minimum receive IPG of 4 is stated for 10 Gb/s."
> >
> >Pat
>
>The original question was why everybody is talking about
>shrinking the IPG to 4 bytes. The receive IPG is never shrinked
>to 4 bytes and and it is never less than 5 bytes at RS receive
>theoritically,
>for explained or unexplaned reasons, it is an issue that
>specify the preamble and the min IPG that
>are "consistence" with the slower speeds those are 4 bytes
>min IPG and SFD at RS. I am not sure of you chasing the the place.
>
>Thanks
>-Sanjeev
>
>
> >
> >-----Original Message-----
> >From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
> >Sent: Tuesday, February 20, 2001 9:48 AM
> >To: sanjeev@xxxxxxxxx; stds-802-3-hssg@xxxxxxxx; yariv@xxxxxxxxxxxxx
> >Subject: RE: RS minimum IPG
> >
> >
> >
> >Sanjeev,
> >
> >Where do you find such a definition in the standard? I don't know of
> >anyplace a minimum receive IPG of 5 is stated. Further, that is a
>parameter
> >that has varied based on speed so what it was at 100/1000 Mb/s does not
> >limit our choice at 10 Gig.
> >
> >Regards,
> >Pat
> >
> >-----Original Message-----
> >From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
> >Sent: Monday, February 19, 2001 11:25 AM
> >To: stds-802-3-hssg@xxxxxxxx; yariv@xxxxxxxxxxxxx
> >Subject: Re: RS minimum IPG
> >
> >
> >
> >The min IPG varies from 9 bytes to 15 bytes
> >based on the packet size and due to clock compensation
> >the PHY may delete a column that will lead to min
> >IPG of 5 Bytes. So, thoeritically it should not be
> >less than 5 bytes but the spec. always defines it
> >to be 4 bytes as this was in the 100/1000 mbps
> >specs.
> >
> >Thanks
> >-Sanjeev
> >
>
>
>
>
Paul A. Bottorff, Director Switching Architecture
Enterprise Solutions Technology Center
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
email: pbottorf@xxxxxxxxxxxxxxxxxx