RE: (Another) Question Regarding Open-Loop Control Mechanism
Dave,
You can look at walker_1_0700 page 16. The diagram shows that from T the
receiver expects a transition to either Z or S. The same is reflected in the
state machines. This is of course necessary in order to support a 12 byte
gap because if the IPG begins with a T falling on the first byte of a block
then an S after a minimum IPG would fall in the middle of the next block.
(Remember that the T is part of the IPG time.) Also, we need to be able to
support IPG as short as 9 bytes because of we adopted the IPG spacing/lane
alignment strategy in haddock_1_0700.
You are correct that the state machine is defined in terms of code blocks
and not octets, but since it allows for a T block followed immediately by an
S block it works for 9 octet IPGs.
Pat
-----Original Message-----
From: David Gross [mailto:dgross@xxxxxxxxxxxxxxxxxx]
Sent: Wednesday, September 06, 2000 1:16 PM
To: pat_thaler@xxxxxxxxxxx
Cc: boazs@xxxxxxxxxxxx; bebrown@xxxxxxxxxxxxxxx;
stds-802-3-hssg@xxxxxxxx
Subject: Re: (Another) Question Regarding Open-Loop Control Mechanism
Pat,
I'm curious about something. Doesn't the PCS also require that a certain
sequencing be followed in which you go from a T to a Z (Idle) to an S.
This is all fine, except that it seems as if the function specified
within each state act on an entire codeword (66 bits in the TX path or
64 data + 8 control in the RX path), not just one octet. Because of this
it would seem that the minimum would look something like DDDDDDDT
ZZZZZZZZ SDDDDDDD. This is 8 Z's and 1 T. Please tell me if I'm off and
the sequencing really works only on an octet by octet basis.
-Dave
pat_thaler@xxxxxxxxxxx wrote:
>
> Boaz, see below. My comments are proceeded by my initials. Pat
>
> -----Original Message-----
> From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
> Sent: Wednesday, September 06, 2000 6:06 AM
> Pat,
>
> > -----Original Message-----
> > From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
> > Sent: Tuesday, September 05, 2000 7:27 PM
> > Boaz,
> >
> > Actually, the worst case for any sublayer is (in this note, the term
> > non-synchronous means a sublayer with an output data rate
> > different speed
> > than its input data rate:
> >
> > MAC is sending at maximum speed.
> > Each of n non-synchronous sublayers between the
> > transmitting MAC and the
> > target sublayer is transmitting slightly slower (say a
> > fraction of a PPM)
> > than the one above it.
> > The target sublayer is transmitting at the minimum speed.
> > All the sublayers exceed the discard threshold simultaneously.
> >
> > The target sublayer must have enough FIFO to wait n + 1 IPGs
> > if there is at
> > least one discardable /R/ per IPG.
> >
> > This doesn't change the total number of /R/'s that are
> > dropped over that in
> > your example, but this case requires the target sublayer to
> > have more FIFO.
> > The layers above it are dropping /R/s less frequently, but
> > when they all
> > coincide, the bottom device has to buffer the excess (<3 bits
> > per packet)
> > from n + 1 packets.
>
> Agree. The worst case, however, is when the clock difference of the
various
> non-synchronous devices is not equal.
>
> <PAT> I'm not sure what you mean to say here. If you mean that the worst
> case for any sublayer is when it has the slowest clock and all the
sublayers
> above it are near the maximum but successively slightly slower, then I
> agree. That is when it needs the most room over the upper threshold.
>
> >
> > It is possible to allow the DTE-XGXS to be a non-synchronous
> > layer. Doing so
> > imposes a cost of additional FIFO for each lower layer. It is
> > a small cost,
> > but sublayers must know the maximum number of non-synchronous
> > layers between
> > them and the transmitting MAC in order to size their FIFOs.
>
> That is right. However, the standard can Permit it, not require it, thus
> leave it open to implementation. Isn't it? This implies that a system that
> once in a while transmit IPG which is smaller than the Minimal one is
> acceptable.
>
> <PAT> High levels of interoperability are part of Ethernet's popularity.
> Generally, if we write the spec so that a transmitter is allowed to do
> something, then we require the receiver to work under that condition. If
we
> allow the DTE-XGXS to be a non-synchronous sublayer, then we should
require
> all the other non-synchronous sublayers to have enough elasticity to
> tolerate plus the other non-synchronous sublayers between them and the
MAC.
>
> >
> > By the way, while we talk about dropping /R/s, that only
> > applies to XGXS
> > layers. 64b/66b PCS works in terms of idles. When addapting
> > to a WIS layer,
> > it will need to discard about 60 bytes per max packet to
> > adapt to the Sonet
> > payload capacity. The open-loop control mechanism will extend
> > the minimum
> > IPG so that it has enough idles, but when the signal is on
> > the XAUI less
> > than half of the extra idles will be /R/s. Obviously, the
> > adaptation to the
> > WIS data rate will require the ability to drop amy idle
> > beyond a minimum gap
> > regardless of its representation on the XAUI.
>
> I see. So, this has to be done by the 64/66 PCS? If so, it can drop any
IDLE
> pattern, even Idles that came from /K/ or /A/, isnt it? The only
limitation
> is that the 64/66 will verify that while it drops IDLES it never comes to
a
> state where the column with /T/ is immediately followed by a column with
> /S/, because there is not 64/66 encoding for such column pair.
>
> <PAT> In the 64/66 code, a /T/ and an /S/ can not fall within the same 8
> byte block. They can occur on adjacent blocks. Therefore, if a /T/ happens
> to fall in the last 4 bytes of the block, an /S/ could fall within one 4
> byte column of it by being the first byte of the next block. Thinking
about
> it, I have realized I was mistaken when I said that the shortest IPG that
th
> 64/66 code could always handle was 8. Since the /S/ must always fall on
the
> first or fifth byte and we know it will be sent such that it does, a gap
as
> short as 5 ensures that the /T/ and the /S/ fall on separate 8 byte
blocks.
> 64/66 can always encode any IPG of at least 5. When a /T/ falls in the
last
> half of the block, it can encode even shorter IPGs down to 1 byte when the
> /T/ falls on the last byte of the block. We (802.3ae) will have to decide
> what limits we want to put on IPG shrinkage. We have agreed that the gap
can
> get as short as 9 bytes. I believe it would be possible to write the
> standard so the gap is never allowed to shrink below that or to allow it
to
> shrink to something smaller.
>
> Pat
>
> Boaz
>
> >
> > Pat
> >
> > -----Original Message-----
> > From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
> > Sent: Monday, September 04, 2000 9:02 AM
> > To: 'Brown, Ben [BAY:NHBED:DS48]'; 802.3ae
> > Subject: RE: (Another) Question Regarding Open-Loop Control Mechanism
> >
> >
> >
> > Ben,
> > I think it doesn't matter. as a matter of fact, I think this
> > case is easier.
> > Assume (Just theoretically) that you really have 10 devices
> > with 20ppm clock
> > difference between one to its successor. So, you have to delete an /R/
> > column each ~130 packets in each. Now, the worst case, I
> > think, is if the
> > threshold is exceeded simultaneously in all the devices.
> >
> > So, in the next IPG, 10 devices would like to remove an /R/
> > column from the
> > data stream. If, in addition, there is only a single /R/
> > column in the IPG,
> > (Minimal one), one device deletes it, and the rest of the
> > devices will have
> > to wait to the next IPG (s). However, since for each the
> > difference is only
> > 20ppm, they can wait much more than 10 packets until next /R/ removal.
> >
> > So, you still do not have a problem, if you can wait a little AFTER
> > threshold crossing.
> >
> > By the way, I'm not so sure that I stated my purpose in this
> > discussion
> > clearly....So here its again: I think that the standard can permit a
> > deletion of /R/ column in the transmit direction by the
> > DTE-XGXS if the MAC
> > and the DTE-XGXS are not driven by the same clock source.
> >
> > Boaz
> >
> > > -----Original Message-----
> > > From: Brown, Ben [BAY:NHBED:DS48] [mailto:bebrown@xxxxxxxxxxxxxxx]
> > > Sent: Monday, September 04, 2000 4:37 PM
> > > To: 802.3ae
> > > Subject: Re: (Another) Question Regarding Open-Loop Control
> > Mechanism
> > >
> > >
> > >
> > >
> > > Boaz,
> > >
> > > One thing to remember is that all the devices in the path must
> > > have a 200 ppm max difference. If there are 10 devices, there
> > > isn't 200 between the first 2 devices then another 200 between
> > > the next 2 devices and so on. If each successive device is slower,
> > > then there might be 20 ppm difference between each set with 200
> > > ppm between the first and the last.
> > >
> > > How does this change your analysis?
> > >
> > > Ben
> > >
> > > Boaz Shahar wrote:
> > > >
> > > > Hello Pat,
> > > > Please see below:
> > > >
> > > > > -----Original Message-----
> > > > > From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
> > > > > Sent: Sunday, September 03, 2000 8:40 PM
> > > > > To: boazs@xxxxxxxxxxxx; pat_thaler@xxxxxxxxxxx;
> > > > > stds-802-3-hssg@xxxxxxxx
> > > > > Subject: RE: (Another) Question Regarding Open-Loop
> > > Control Mechanism
> > > > >
> > > > >
> > > > >
> > > > > Boaz,
> > > > >
> > > > > You appear to be making invalid assumptions. Whenever the
> > > > > clock rate out of
> > > > > a sublayer is slower than the clock rate out of the sublayer,
> > > > > the elasticity
> > > > > buffer
> > > > > will fill. If the clocks are only slightly different, then it
> > > > > will fill
> > > > > slowly, but it will
> > > > > eventually reach its high water mark and need to delete
> > > > > idles. If there are
> > > > > several sublayers in the path that have successively slower
> > > > > clocks out, then
> > > > >
> > > > > there can occur times when more than one has reached the high
> > > > > water mark
> > > > > and will need to delete idles.
> > > > >
> > > > > As long as they have enough additional room in the elasticity
> > > > > buffer to wait
> > > > >
> > > > > for the next opportunity to delete, this is not a problem.
> > > > > The important
> > > > > point is that it may take more than one packet before an
> > > > > opportunity to
> > > > > delete occurs. Since the maximum accumulation during a
> > > packet is less
> > > > > than 3 bits (when clocks differ by 200 ppm), the deletion of
> > > > > 4 bytes will
> > > > > remove the accumulation from many packets.
> > > >
> > > > Agree. So lets look at the path: MAC-XGXS-PHY-PHY-XGXS-MAC,
> > > assuming max
> > > > frequency difference of 200ppm end to end, and any of the
> > > entities works
> > > > with a different clock source. In the worst case, it may
> > > happen that in all
> > > > entities, the threshold is exceeded at the same time , but
> > > there is only one
> > > > /R/ column in the IPG. Then, only one entity can delete the
> > > /R/ column, but
> > > > since this deletion is enough for many packets, in the next
> > > IPG the next
> > > > entity will delete /R/ and so on. 3 bits/packet means that
> > > /R/ column is
> > > > enough for about 13 packets. so more then 10 entities can
> > > delete /R/ before
> > > > the first one has to delete /R/ column again.
> > > > So, if your water mark is far enough from the end of your
> > > FIFO, and thus
> > > > enables you to wait to the next packet IPG if you do not
> > > find an /R/ column,
> > > > then even if you have more than 10 entities with different
> > > clock, you should
> > > > not have a problem.
> > > >
> > > > >
> > > > > Secondly, the 64b/66b encoding requires that the minimum
> > > > > interpacket gap
> > > > > be 8 bytes. Take the case where the last byte of a packet
> > > fell on the
> > > > > last byte of a code block. The next block would encode the T
> > > > > that terminates
> > > > > the packet and that block cannot encode an S. The
> > > earliest an S can be
> > > > > sent is the start of the next block which means that the idle
> > > > > has to be
> > > > > 8 bytes. If an XGXS is allowed to send the 64b/66b PCS a
> > > gap less than
> > > > > 4 bytes, in some cases the 64b/66b PCS would have to insert a
> > > > > set of idles
> > > > > and later (when a larger gap arrives because one should not
> > > > > get repeated
> > > > > short gaps) delete a set.
> > > >
> > > > Do Not Agree In your example, the original gap was 3(/K/)
> > > +1 (The /T/) + 8
> > > > (Two columns of Idle while packet is generated) which is 12
> > > bytes. Deleting
> > > > the /R/ column leavs you with 8, which is enough.
> > > >
> > > > >
> > > > > Thirdly, since the XGXS is an optional sublayer, it cannot
> > > > > provide functions
> > > > >
> > > > > such as idle deletion or insertion to other layers. It may
> > > > > perform that
> > > > > function
> > > > > for to meet its own timing needs. A 64b/66b PCS may interface
> > > > > directly to
> > > > > the XGMII and therefore must provide rate adaptation for
> > > the WAN PHY.
> > > >
> > > > I agree that it does not solve the problem if the 64/66
> > > attached directly to
> > > > the XGMII. In this case, this Clock Tolerance compensation
> > > function must be
> > > > somewhere between the XGMII to the 64/66, at the beginning
> > > of the PCS.
> > > >
> > > > > (The layers below the 64b/66b PCS can not provide that
> > > > > function because
> > > > > the stream has been scrambled before it reaches them and they
> > > > > just transmit
> > > > > bits without acquiring lock to the blocks.
> > > > >
> > > > > Regards,
> > > > > Pat
> > > > >
> > > >
> > > > However, I think you cannot require that the clocks in the
> > > MAC, DTE-XGXS,
> > > > and PHY will be the same.
> > > >
> > > > Best Regards,
> > > > Boaz
> > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
> > > > > Sent: Sunday, September 03, 2000 12:21 AM
> > > > > To: 'pat_thaler@xxxxxxxxxxx'; HSSG (E-mail)
> > > > > Subject: RE: (Another) Question Regarding Open-Loop
> > > Control Mechanism
> > > > >
> > > > >
> > > > >
> > > > > Pat,
> > > > > I do not see any problem with removing the first /R/ column
> > > > > of the XAUI,
> > > > > even if the MAC generated a 12 bytes gap. It just that if the
> > > > > DTE-XGXS chip
> > > > > is doing it, the minimum gap of the transmitter can be as
> > > low as 9-4=5
> > > > > bytes.
> > > > >
> > > > > However, this happens only if the PHY clock frequency is much
> > > > > lower tnan the
> > > > > MAC clock. There is no "danger" that in the other side (In
> > > > > the receive side)
> > > > > there will be a need for further compresion of the IPG
> > > > > because the 200ppm
> > > > > difference is End-To=End requirement.
> > > > >
> > > > > In the WAN-PHY case, this can be done by the PHY-XGXS.
> > > > >
> > > > > I do not think it is good idea to limit the /R/ removal
> > > > > operation for IPG
> > > > > which are grater than 2 columns, because if you do that, you
> > > > > have to provide
> > > > > additional IPG criteria like "Avarage size of IPG" or to say
> > > > > that you must
> > > > > provide an IPG which is at least 3 columns periodically, and
> > > > > it is complex.
> > > > >
> > > > > I think we can agree that while packets are generated, the
> > > > > min IPG is 2
> > > > > columns as in the current proposals, but may decrease to one
> > > > > column before
> > > > > going to the MDI.
> > > > >
> > > > > Regards,
> > > > > Boaz
> > > > > -----Original Message-----
> > > > > From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
> > > > > Sent: Thursday, August 31, 2000 7:27 PM
> > > > > To: boazs@xxxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
> > > > > Subject: RE: (Another) Question Regarding Open-Loop
> > > Control Mechanism
> > > > >
> > > > >
> > > > > Boaz,
> > > > >
> > > > > Part of the purpose of the non-extended IPG (that is, the
> > > > > traditional 96
> > > > > bits) is to allow physical
> > > > > layer devices to drop some of the idle in order to move
> > > between clock
> > > > > domains that have the
> > > > > ppm clock difference. The difference in maximum size packet
> > > > > duration between
> > > > > slowest and
> > > > > fastest clocks is less than 3 bits. The MAC does not need to
> > > > > lengthen the
> > > > > gap to compensate
> > > > > for this.
> > > > >
> > > > > Because our physical layer devices will only be able to drop
> > > > > or add idles in
> > > > > increments of 4
> > > > > bytes, dropping an idle from a 12 byte IPG will reduce it to
> > > > > 8 bytes. We
> > > > > will need to consider
> > > > > the limits on shortening idle in order to specify the
> > limit of IPG
> > > > > shrinkage. For instance, if
> > > > > a device gets a 9 byte IPG, can it shorten that IPG or should
> > > > > it wait for a
> > > > > longer idle? For
> > > > > some alignments, the 10GBASE-R PCS encoding requires 8
> > > bytes of idle
> > > > > (counting the /T/
> > > > > as part of the idle) to produce valid codes so at least for
> > > > > that case, it
> > > > > will need to look for
> > > > > a long enough IPG before shortening. Since short gaps can
> > > not happen
> > > > > constantly, within
> > > > > a packet or two a long enough one will arrive.
> > > > >
> > > > > By the way, if you do the calculation for the open-loop
> > > > > control mechanism,
> > > > > you will see that
> > > > > when extending the IPG to adapt to the WIS data rate, it adds
> > > > > less than a
> > > > > byte per a minimum
> > > > > size packet. Therefore, a 10GBASE-R PCS doing the adaptation
> > > > > for WIS also
> > > > > receives IPGs
> > > > > as short as 9 bytes and will need to wait for a long enough
> > > > > IPG to do the
> > > > > idle deletion.
> > > > >
> > > > > Regards,
> > > > > Pat
> > > > >
> > > > > -----Original Message-----
> > > > > From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
> > > > > Sent: Tuesday, August 29, 2000 11:53 PM
> > > > > To: HSSG (E-mail)
> > > > > Subject: (Another) Question Regarding Open-Loop Control
> > Mechanism
> > > > >
> > > > >
> > > > >
> > > > > Shimon:
> > > > > When the MAC device and the PHY device are driven by a
> > > different clock
> > > > > source, How does Clock Tolerance Compensation between
> > > the two done?
> > > > > (That is, since the max difference between the two is 200ppm,
> > > > > then the MAC
> > > > > may always adjust the rate to the nominal rate - 200ppm? And
> > > > > if so: Is it
> > > > > acceptable ?)
> > > > >
> > > > > Sorry if this was asked before.
> > > > > Boaz
> > > > >
> > >
> > >
> > > --
> > > -----------------------------------------
> > > Benjamin Brown
> > > Router Products Division
> > > Nortel Networks
> > > 1 Bedford Farms,
> > > Kilton Road
> > > Bedford, NH 03110
> > > 603-629-3027 - Work
> > > 603-624-4382 - Fax
> > > 603-798-4115 - Home
> > > bebrown@xxxxxxxxxxxxxxxxxx
> > > -----------------------------------------
> > >
> >