RE: (Another) Question Regarding Open-Loop Control Mechanism
Hi,
Please see below.
> -----Original Message-----
> From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
> Sent: Thursday, September 07, 2000 1:10 AM
> To: dgross@xxxxxxxxxxxxxxxxxx; pat_thaler@xxxxxxxxxxx
> Cc: boazs@xxxxxxxxxxxx; bebrown@xxxxxxxxxxxxxxx;
> stds-802-3-hssg@xxxxxxxx
> Subject: 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.
And 5 Octet IPG As well.
Boaz
>
> 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
> > > > -----------------------------------------
> > > >
> > >
>