Re: (Another) Question Regarding Open-Loop Control Mechanism
Yes you're right, I must have been looking at an older slide deck. But
now that I see the new TX process and RX process, I have another
question. If you allow for the sequence TZZZZZZZ ZZZZSDDD, what happens
if you get an error somewhere. It would appear as if the condition to
get out of the error state is to wait for ZZZZZZZZ, but this won't
appear between frames given the above circumstance and the next frame
will also be "errored". Perhaps I'm mistaken, but it would seem as if
the next perfectly good frame will be trashed? Is this correct?
-Dave
pat_thaler@xxxxxxxxxxx wrote:
>
> 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
> > > > -----------------------------------------
> > > >
> > >