RE: Origin of delay constraints in Clause 44 (PMA-PMD)
Hello:
I get to post a reply to my own question... Hopefully this helps out
everyone else as much as it educated me.
This reply was from Tom Mathey (thanks!), and the included text was by Rich
Siefert. Sorry about my delay posting this to the reflector.
Dave
------
David Kabal
Picolight
Phone: 303-530-3189 ext. 272
Fax: 303-527-4968
>Hello:
>
>Last meeting's discussion on the Serial PMD conference call yielded a set
of
>general questions regarding delay constraints in Clause 44:
>
>1) Why is there no restriction on the maximum cable delay? (p166-167,
>Section 44.3)
>
>2) Why does the delay specified for the PMA-PMD include 2 m of fibre?
(p167,
>Table 44-2)
>
>3) Why is the specified PMA-PMD delay only 512 bit times, whereas, for
>example, a 14336 bit time delay is allowed for the WIS? (p167, Table 44-2)
>
>Thanks,
>Dave
Item 1)
There is no restriction on the maximum cable delay since this delay is
provided as a management variable: 30.3.4.1 aPAUSELinkDelayAllowance. A
system administrator provides this value. The user then adds the "bits in
flight on the wire" to the amount of memory or buffer space needed to
operate within the PAUSE command restrictions. Rich Seifert recently had a
rather complete description of this in the usenet group for Ethernet,
included below.
Item 3)
This one is less clear. However, the 14336 bit time is 1792 bytes, or /64
for 28 Pause Quantum. As the WIS may be just starting overhead transmission
just as a 64/66 encoded MAC packet arrives, the WIS delays the encoded
packet by 576 + 64 bytes = 640 = 10 Pause Quantum. Same for receive. So 10
for tx + 10 for rx = 20 total. Table 44-2 allows for 28 Pause Quantum.
The remaining 8 may be for internal tx and rx processing, such as shown in
Figure 50-3. Note that the 14336 bit time is the sum of tx and rx, and may
be split as the designer wishes.
At the editors meeting in later January, the group decided to round all
delays up to groups of 512 bits, equal to one (1) Pause Quantum. To our
knowledge, the PMA-PMD needed only a few number of clock cycles from input
to output. If the actual delay is greater than 512 bit times, please submit
a comment to increase value in Table 44-2 (or reconsider why the PMA-PMD has
such a long delay).
-------------- Included text by Rich Siefert
If a device is using PAUSE flow-control to prevent frame loss, it needs to
send PAUSE frames *before* its input buffer overflows, because there is a
time lag between issuing the PAUSE frame and stopping the flow as seen at
the receiver. There are a number of elements to this time lag, including:
-The time required to finish transmitting a frame-in-progress
-The time required to transmit the PAUSE frame itself
-The time required for the receiver at the other side to parse and process
the PAUSE frame
-The time required for the receiver to finish transmitting a
frame-in-progress, and
-The round-trip propagation delay of the link
Until all of these times expire, bits can continue to arrive at the input
and cause possible buffer overflow.
The first four time elements listed are fixed and known (in the worst-case)
by the stations, as they are a function only of the link data rate, the
frame lengths, and the 802.3X specification limits. The last element, link
propagation delay, can vary depending on whether one is using a 100 m UTP
link, a 2 km multimode fiber link, or some proprietary long-distance link.
This latter case is especially important, since full-duplex Ethernet
eliminates the delay constraint imposed by the CSMA/CD algorithm. It is
possible to use full-duplex Ethernet over virtually unlimited distances. A
number of manufacturers make long-distance fiber transceivers that operate
over 100 km or greater distances. In addition, the amount of buffer space
required to compensate for the link propagation delay will vary with the
data rate; higher data rates require a greater buffer allowance for the
propagation delay.
If one is using the PAUSE flow-control mechanism, it is important to know
how much allowance your partner has made for the link propagation delay; if
it is too short for the link in use, the mechanism will not properly
prevent frame loss. (Of course, you already know how much allowance YOU
have made; you only need to find out if "the other guy" has the right
number, too.)
The management object you mention, aPAUSELinkDelayAllowance, tells you this
value. It is measured in bits, as this makes the value independent of the
link data rate. (Bits also makes more sense, since it reflects how much of
the receiver input buffer has been allocated for the link delay. Memory is
measured in bits, not time.)
I hope this helps. There is also a complete explanation of the PAUSE time
allocations and their use in managing receiver buffer overflow in BOTH of
my recent books: Gigabit Ethernet (©1998, Addison-Wesley, Chapter 6) and
The Switch Book (©2000, John Wiley, Chapter 8).
[I was the chair of the committee, and editor/author of the IEEE 802.3X
standard itself.]
--
Rich Seifert Networks and Communications Consulting
rich@xxxxxxxxxxxxxxx 21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 395-1966 FAX