RE: Minimum IPG w/ WIS ?
Pat,
Thanks for the feedback. I have a question about trying to shrink the IPG
(sent with the packet) down to 10 or 11 bytes. Its been my understanding we
are trying to stay with a more conservative calculation in order to avoid
the possibility of overrunning the WIS on transmit, relative to the PPM
tolerances of the clock speeds we are running at. Additionally, the per
packet IPG actually sent with the packet still has the window of 9-15 bytes
(12 bytes average over time), which is driven by the 64/66 encoding scheme.
Looking at both of these together would imply you want to drive the IPG down
even further to a window of 7-13 bytes, or 8-14 bytes. If that is true,
does this push us below the 5 byte minimum IPG limit, if a rate-compensation
column-strip occurs on the other end (post elte extraction)? Or, will the
re-insertion of idles used to bring the data back up to a 10 Gb/s rate
always guarantee avoidance of this? Is this a non-issue altogether?
Regards,
Mike
-----Original Message-----
From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
Sent: Tuesday, February 27, 2001 1:20 PM
To: Julio.Hernandez@xxxxxx; Mike.Bly@xxxxxxxxxxxxxxxxxxxx;
stds-802-3-hssg@xxxxxxxx
Subject: RE: Minimum IPG w/ WIS ?
Mike and Julio,
Actually I disagree with the statement that stretching of the IPG must take
into account preserving the 12 byte IPG. As I commented on D2.0, the
10GBASE-R PCS can encode any IPG of 5 characters or more and the 12
character average IPG would only shrink to about 11 characters if we didn't
account for it in calculating the stretch. For the speed difference with the
WIS a calculation that didn't include IPG would produce a valid encodeable
data steam. The one downside is that if we wanted to accomodate a much more
severe speed difference in the future (decreasing ifsStretchRatio) would be
that the calculation without the IPG might produce very short IPGs.
We could also discard the excess bits left over in ifsStretchCount at the
end of the frame which would produce a shrinkage of average in the WIS
encoded stream of about another character. If we did both, the average IPG
in WIS encoded stream for back to back packets would be 10 characters which
is plenty.
For generality, we are sacrificing about a byte of throughput per frame, but
I didn't get support for the changes and it isn't broken.
What Mike said about the inability to add and delete idles is correct with
respect to the Sonet framer. It is just getting encoded scrambled data and
has no idea what is IPG vs data. The transmitting PCS handles the deletion
of idles to get things to the Sonnet data stream rate and the receiving PCS
handles insertion of the idles to restore things back to the 10 Gb/s rate.
We do not specify where in the PCS this function must reside. However, since
one cannot be sure of having 8 byte 64B/66B block of data available to
delete during IPGs and there is no way to delete half a block, it would be
difficult to do idle deletion on the 64B/66B encoded data.
Regards,
Pat
-----Original Message-----
From: Julio.Hernandez@xxxxxx [mailto:Julio.Hernandez@xxxxxx]
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
>