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.
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.
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.
(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
-----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