Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Minimum IPG w/ WIS ?

As Mike Bly points out to me, old habits die hard. Of course I meant to say
Gb/s below rather than Mb/s. Pat

-----Original Message-----
From: THALER,PAT (A-Roseville,ex1) 
Sent: Tuesday, February 27, 2001 1:59 PM
To: 'Roy Bynum'; THALER,PAT (A-Roseville,ex1); Julio.Hernandez@xxxxxx;
THALER,PAT (A-Roseville,ex1); stds-802-3-hssg@xxxxxxxx
Subject: RE: Minimum IPG w/ WIS ?


The Ethernet MAC runs at 10 Mbit/s on both its transmit and receive side.
There is no requirement in the standard that its receive side be slaved to
an input clock. Some implementations may do it that way, but I know of many
implementations that synchronize the input data into the MACs own clock
domain and run both sides on the same clock. 

Of course, there may also be XGXS sublayers, exposed XAUI interfaces and
exposed XGMII interfaces between the PCS and the MAC and all of those are
defined for 10 Mb/s operation and the resulting clock rates only.
Reinserting idls is not significant trouble and it allows all those devices
to operate at 10 Mb/s +/- 100 PPM data rates.


-----Original Message-----
From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
Sent: Wednesday, February 21, 2001 6:46 AM
To: THALER,PAT (A-Roseville,ex1); Julio.Hernandez@xxxxxx; THALER,PAT
(A-Roseville,ex1); stds-802-3-hssg@xxxxxxxx
Subject: RE: Minimum IPG w/ WIS ?


What is the rational for the need to put the RS receive rate back up to 
10Gb?  The Ethernet transfer rate into the MAC at the RS varies greatly 
according to the PHY speed.  Do the Ethernet frames recognize any of the 
speed differences at the MAC service layer?  Why go to the trouble of 
re-inserting idles just to make it modulo 10 again?  It seems like this is 
somewhat of an "over-kill".

Thank you,
Roy Bynum

At 08:39 PM 2/20/01 -0500, THALER,PAT (A-Roseville,ex1) wrote:

>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
>of clock compensation).
>So IFS stretch isn't particularly relevant to your question. However, I
>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
>ifsStretchCount) divided by 104 which means IFS stretch for a min size
>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
>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
>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
>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
>clumped close together.
>I hope this clarifies the process for you.
>-----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 ?
>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,
>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
>Subject:  RE: RS minimum IPG
>I can't quite parse what you've said. In any case, Shimon has pointed
>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.
>-----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
>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.
> >
> >-----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
> >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
> >