RE: (Another) Question Regarding Open-Loop Control Mechanism
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
>