weird asymmetric PAUSE autoconfiguration code ?
M.Herbert
Gigabit Ethernet added _asymmetric_ flow control to the previous
(100Mb/s) symmetric version of the 802.3x standard. My concern is
about the related change in the autonegociation protocol for link
configuration.
Let me first take for a moment a purely "mathematical" point of view
about this negociation issue, ignoring compatibility. There are four
possible final link configurations: (-,-) (TX,-) (-,RX) (TX,RX). "TX"
means "I am sending you PAUSE frames and "RX" means "I am listening to
your PAUSE frames".
Being able to propose any *combination* of these four states (for
instance, to say: "I'm OK for (-,-) or (TX,-) and I reject the two others")
require no less than 4 bits, coding one "yes/no?" bit for each state.
An "optimization" to save a bit or two can be to order the proposals:
any proposition for one state implies acceptance of all inferior
states. Then you just have to propose a rank instead of a subset.
Partial orders may also help: for instance you can assume that
any subset implicitely includes the empty (_,_) proposition.
Admit in addition that the TX and RX negociations are independent
of each other, and then only 2 bits would be needed, one for proposing
(TX or -) and one for proposing (RX or -). Add a legacy, symmetric
bit for compatibility and 3 bits as a whole are enough.
----------------
Back to reality, with a legacy SYMmetric bit and _only one_ (why?)
extra ASM_DIR bit, I understand from reading the standard that we have
this (weird?) negociation code, that does not fit any of the schemes
above.
Reading table 3 of Annex 28B in 802.3
<http://standards.ieee.org/getieee802/802.3.html> (part 2)
I understood the following, please correct me if I am wrong.
for (SYM, ASYM) bits:
(0,0) still means:
"let's both do nothing, end of negociation".
(1,0) still means:
"depending on you,
- let's both control each other,
- or do nothing".
NEW!
(0,1) means:
"depending on you,
- I will asymmetrically control YOU,
- or we'll do nothing".
(1,1) means:
"depending on you, we will:
- you will asymmetrically control ME,
- or we will control each other,
- or we'll do nothing
Tabular representation of this code:
proposed states (TX,_) (_,_) (TX,RX) (_,RX)
sent codes
_____
(0,0)
OLD ----------------
(1,0)
_______________
(0,1)
NEW __________________________
(1,1)
Funny quote from here:
<http://www.ieee802.org/3/z/public/presentations/nov1996/RS8023x.pdf>
"One (possibly two?!) additional Auto-Negotiation capability bits
are needed to allow negotiation of symmetrical and asymmetrical flow
control with full backwards compatibility" -- Rich Seifert
I also noticed there is still a free reserved bit in the base page.
This was also discussed here:
<http://www.ieee802.org/3/z/public/minutes/San0197.txt>
but these quick notes do not bring much light.
Another funny thing is that most linux drivers propose free and
independent proposals of TX and RX in autonegociation... I wonder how
they implement it! In practice, I tend to manually configure
everything to avoid this complexity.
Thanks in advance for any explanation/pointer for this negociation
code. In particular from people that were in 802.3z at end of 1996!
Rich Seifert
wrote:
> Gigabit Ethernet added _asymmetric_ flow control to the previous
> (100Mb/s) symmetric version of the 802.3x standard. My concern is
> about the related change in the autonegociation protocol for link
> configuration.
>
> Let me first take for a moment a purely "mathematical" point of view
> about this negociation issue, ignoring compatibility. There are four
> possible final link configurations: (-,-) (TX,-) (-,RX) (TX,RX). "TX"
> means "I am sending you PAUSE frames and "RX" means "I am listening to
> your PAUSE frames".
>
Remember, AutoNegotiation advertises what a device is *willing* to do
(or capable of doing), not what may actually happen as a result of the
negotiation. That said, there are four possibilities:
(1) I have no flow control capability.
[Encoded as PAUSE=0, ASM_DIR=0]
This case is simple; it means the device either has no use for flow
control, or that it was built without any such capability (e.g., it was
built before Ethernet flow control was designed).
(2) I both assert and respond to flow control. This is the pre-Gigabit,
symmetric mode of operation, and implies a full implementation of the
PAUSE mechanism (both send and receive) within the device.
[Encoded as PAUSE=1, ASM_DIR=0. Note the backwards compatibility, since
prior to Gigabit Ethernet the "ASM_DIR" bit was "reserved: set to zero,
ignore on receipt]
Prior to the standardization of Gigabit Ethernet, there was no such
thing as "asymmetric" flow control. A device that wanted to assert flow
control HAD TO also respond to flow control messages. It was all or
nothing. A link partner could not tell a device to respond to flow
control messages, but not to ever send them.
(3) I can *assert* flow control, but cannot respond (i.e., I want to be
able to send PAUSE frames, but I will ignore any you send me).
[Encoded as PAUSE=0, ASM_DIR=1. Note the backwards compatibility again;
a legacy "symmetric-only" device will see this advertisement as "I have
no flow control capability", since PAUSE=0; this is the proper
interpretation, since the legacy device wants "all or nothing", not
"receive my messages but don't send any of your own".]
This new, asymmetric capability might be advertised by a device that has
(limited) receive buffers, but virtually no transmit buffer capability
(e.g., a so-called "buffered distributor"; see Chapter 11 of my book,
"Gigabit Ethernet"). Sending a PAUSE frame to such a device would be
futile, since the device has no place to save the frames its partner
wants throttled.
Furthermore, the circuitry required to implement PAUSE receive is much
more complex than that required for PAUSE transmit. A device that only
needs to send PAUSE frames can build a fixed-content PAUSE frame (in
hardware) and simply send it whenever some trigger event occurs. To
respond to PAUSE frames requires parsing and decoding many fields (MAC
addresses, protocol type, MAC Control fields, etc.), along with the
required timers implied by the protocol. There is no need to implement
this circuitry in a device that cannot provide any benefit from PAUSE
receive in the first place.
(4) I can both assert and respond to flow control AND I am willing to
operate either symmetrically OR asymmetrically in EITHER direction.
[Encoded as PAUSE=1, ASM_DIR=1. Again, we have perfect backwards
compatibility. A legacy "all or nothing" device will see this as an
advertisement for symmetrical flow control.]
Now, either link partner may be in any of these four states. The
Auto-Negotiation protocol will resolve the advertisements as follows:
Local Device Link Partner Result
---------------------------------------------------------------------
PAUSE ASM_DIR PAUSE ASM_DIR
0 0 Any Any No flow control
0 1 0 Any No flow control
0 1 1 0 No flow control
0 1 1 1 Asymmetric, toward partner only
1 0 0 Any No flow control
1 Any 1 Any Symmetric flow control
1 1 0 0 No flow control
1 1 0 1 Asymmetric, from partner only
If you look at the semantics of the various encodings (provided
earlier), you can work out why you get the indicated result for each
possible combination. (This is a good exercise for the student!)
> ----------------
>
> Back to reality, with a legacy SYMmetric bit and _only one_ (why?)
> extra ASM_DIR bit,
I hope you can now see why only one ASM_DIR bit is required. Bits
(especially those on the base page) are "expensive", and we found a way
to save one without sacrificing any capability.
>
> Funny quote from here:
> <http://www.ieee802.org/3/z/public/presentations/nov1996/RS8023x.pdf>
>
> "One (possibly two?!) additional Auto-Negotiation capability bits
> are needed to allow negotiation of symmetrical and asymmetrical flow
> control with full backwards compatibility" -- Rich Seifert
>
This was a presentation made early on during the development of the
standard. I recognized that we would need at least one bit for
asymmetrical operation. Two might be required either to support
additional possibilities, or to simplify the encoding. In the end, we
only needed one bit.
> Thanks in advance for any explanation/pointer for this negociation
> code. In particular from people that were in 802.3z at end of 1996!
>
There is a fairly complete explanation in Chapter 12 of my book,
"Gigabit Ethernet"; it includes the table I provided above (with more
text, of course, and better-than-ASCII graphics!).
I hope this helps.
[FYI: I was the chair and editor of IEEE 802.3x.]
--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 395-1966 FAX
Send replies to: usenet at richseifert dot com
M.Herbert
> Remember, AutoNegotiation advertises what a device is *willing* to do
> (or capable of doing), not what may actually happen as a result of the
> negotiation. That said, there are four possibilities:
>
> [...]
>
> Furthermore, the circuitry required to implement PAUSE receive is much
> more complex than that required for PAUSE transmit. A device that only
> needs to send PAUSE frames can build a fixed-content PAUSE frame (in
> hardware) and simply send it whenever some trigger event occurs. To
> respond to PAUSE frames requires parsing and decoding many fields (MAC
> addresses, protocol type, MAC Control fields, etc.), along with the
> required timers implied by the protocol. There is no need to implement
> this circuitry in a device that cannot provide any benefit from PAUSE
> receive in the first place.
>
> > Back to reality, with a legacy SYMmetric bit and _only one_ (why?)
> > extra ASM_DIR bit,
>
> I hope you can now see why only one ASM_DIR bit is required. Bits
> (especially those on the base page) are "expensive", and we found a way
> to save one without sacrificing any capability.
I think I now do see why: you just "sacrified" the capability to
advertise RX-only ("I can respond to flow control, but will never
assert it myself") since this case makes sense only from an
exhaustive, theoretical point of view but not in the real world, as
clearly explained above.
Right?
User-unfriendliness
-------------------
There is still an issue IMHO: this flow control autonegociation
protocol is not "user-friendly", as first stated at end of my message
two steps above.
[Warning: I consider here the (very?) specific case of some user
wishing to enable flow direction in only one direction, but not
"forcing it" manually and still relying on the safety of
autonegociation to possibly fall back on some other, _agreed_ final
configuration.]
It seems this protocol is so unfriendly that people developping
ethernet configuration interfaces don't have the time to understand it
(I guess they just don't care). They keep providing user-friendly (but
wrong!) independent TX and RX settings. It seems no one mentions that
advertising RX capability implies advertising TX capability (assuming
this is the way they implement it :-(
One must admit that their task is complicated since on the other hand,
the _manual_ configuration obviously allows independent configuration
of TX and RX (or not?)
Examples:
- ethtool's user interface. ethtool is meant to be THE standard
ethernet configuration tool for linux. Search for "-A" in:
http://gd.tuwien.ac.at/linuxcommand.org/man_pages/ethtool8.html
or for the latest, official version:
http://cvs.sourceforge.net/viewcvs.py/gkernel/ethtool/ethtool.8
Conclusion: you are supposed to be able to independently toggle:
autoneg, tx, rx
- extract from bcm5700 linux driver man page:
rx_flow_control
Enables or disables receiving flow control (pause)
frames. This parameter is used together with
auto_flow_control. The valid values are:
0 pause receive disabled
1 pause receive enabled if auto_flow_control
is set to 0, or pause receive advertised if
auto_flow_control is set to 1 (default)
- The documentation of the Intel e1000 linux driver:
http://support.intel.com/support/network/sb/CS-009209.htm#parameters
is so terse that it does not make the difference between
configuration of advertised flow control capabilities and manual
flow control configuration. One wonders who are the fools who care
about that :-)
- On the other hand, Sun Gigaswift User's guide (for Solaris) shows
two "adv-pause-cap" and "adv-asmpause-cap" settings. At least
something consistent with reality! On the other, other hand, it
seems there is no way to manually configure TX and RX.
- to be continued...
About The Book
--------------
> There is a fairly complete explanation in Chapter 12 of my book,
> "Gigabit Ethernet"; it includes the table I provided above (with more
> text, of course, and better-than-ASCII graphics!).
I carefully read the "flow control" and "automatic configuration"
chapters, but I must admit I skipped/missed this chapter 12 "Physical
layer"! I was also quickly turned away by the optical stuff at the
beginning, seemed irrelevant to me :-(
One problem I had with The Book is that the autonegociation protocol
is very well described in the optical section of this "physical layer"
chapter 12, but the equivalent for UTP is located elsewhere far away
(in the "automatic configuration" chapter), a bit redundant-ly, much
less exhaustive, and less up-to-date: no asymmetry! It seems that,
since the book preceded the 1000Base-T standard, you were very careful
not say anything about 1000Base-T autonegociation and asymmetry,
whereas it ends up being... the very same autonegociation as
1000Base-X.
"Gigabit Ethernet" - 2nd edition anyone ? :-)
PS for people here that (still?) do not have it: this is a great book.
"Advertising" it here a little bit definitely feels ok, especially
considering the quality and quantity of free support provided by the
book's author in this group :-)
Rich Seifert
wrote:
> I think I now do see why: you just "sacrified" the capability to
> advertise RX-only ("I can respond to flow control, but will never
> assert it myself") since this case makes sense only from an
> exhaustive, theoretical point of view but not in the real world, as
> clearly explained above.
>
> Right?
>
Sort of. Since *all* of the implementation complexity is in the
receiver/parser, there is no great benefit to having the ability to
receive without also having the ability to send PAUSE frames.
Also, here's another take on it (and we expressly discussed this during
the standards meetings). Just because a device has the *capability* to
send PAUSE frames does not mean that it must ever actually send one.
There is no algorithm or specification of when it is appropriate (or
necessary) to assert flow control; it is left as application-dependent.
That said, assume that you do have a device that can receive, but not
send PAUSE frames. There is no problem if the device advertises that it
CAN send PAUSE frames (even though it can't). Since it is never required
to actually send such a frame, there is no observable means of
distinguishing between a device that CAN send PAUSE frames but chooses
not to, and a device that is incapable of sending PAUSE frames. Since
there is no distinction, you are free to advertise a capability that you
will never assert!
>
> It seems this protocol is so unfriendly that people developping
> ethernet configuration interfaces don't have the time to understand it
> (I guess they just don't care). They keep providing user-friendly (but
> wrong!) independent TX and RX settings. It seems no one mentions that
> advertising RX capability implies advertising TX capability (assuming
> this is the way they implement it :-(
>
The underlying protocol mechanism does not have to map 1:1 to the user
interface. Since (as discussed above), one can advertise symmetrical
PAUSE capability, yet (internally) decide never to send any PAUSE
frames, it is perfectly feasible to construct a user or programming
interface that gives the appearance of "truly independent"
transmit/receive functionality. I would argue that such a user interface
is more intuitive than the protocol mechanism, and that is a Good
Thing(tm).
> One must admit that their task is complicated since on the other hand,
> the _manual_ configuration obviously allows independent configuration
> of TX and RX (or not?)
>
Assuming that I have a device with symmetric PAUSE capability, I can
choose to enable the transmit and receive functions independently, via
manual configuration. However (as discussed above), I can do this using
Auto-Negotiation as well (even though the protocol mechanism has no such
express encoding).
>
> - On the other hand, Sun Gigaswift User's guide (for Solaris) shows
> two "adv-pause-cap" and "adv-asmpause-cap" settings. At least
> something consistent with reality! On the other, other hand, it
> seems there is no way to manually configure TX and RX.
>
Here, Sun has simply passed the raw protocol mechanism to the user as a
programming interface. This is the easiest approach from an engineering
perspective, but makes poor sense to a user/programmer. As you note, it
is easier to conceptualize that the interface has independent transmit
and receive flow control. That is the metaphor that belongs in the user
interface, NOT the (admittedly ugly, but more efficient) protocol
signaling bits.
>
> One problem I had with The Book is that the autonegociation protocol
> is very well described in the optical section of this "physical layer"
> chapter 12, but the equivalent for UTP is located elsewhere far away
> (in the "automatic configuration" chapter), a bit redundant-ly, much
> less exhaustive, and less up-to-date: no asymmetry! It seems that,
> since the book preceded the 1000Base-T standard, you were very careful
> not say anything about 1000Base-T autonegociation and asymmetry,
> whereas it ends up being... the very same autonegociation as
> 1000Base-X.
That's correct. When I wrote the book, 1000BASE-X was just completed,
and 1000BASE-T was many months away. Since lots of things can change
during the development of a standard, I was reluctant to include details
that might well turn out to be wrong once the standard was finalized.
Thus, there is nothing about 1000BASE-T Auto-Negotiation; the chapter on
"Automatic Configuration" covered the historical stuff (10/100BASE-T)
only.
> "Gigabit Ethernet" - 2nd edition anyone ? :-)
>
There was strong interest from the publisher to do this. We actually
have a contract in place, the outline is signed off, and I was ready to
move ahead when my personal interests changed somewhat, and the project
became no longer feasible.
(Here's a decode of that last sentence: For the past two years, I have
put most of my technology work on hold and am now a second-year law
student at Santa Clara University. Law school consumes most of my time
and energy; I still sit on some corporate boards and do some consulting,
but there are insufficient spare hours to do a book at this time.)
glen herrmannsfeldt
(snip)
> Also, here's another take on it (and we expressly discussed this during
> the standards meetings). Just because a device has the *capability* to
> send PAUSE frames does not mean that it must ever actually send one.
> There is no algorithm or specification of when it is appropriate (or
> necessary) to assert flow control; it is left as application-dependent.
> That said, assume that you do have a device that can receive, but not
> send PAUSE frames. There is no problem if the device advertises that it
> CAN send PAUSE frames (even though it can't). Since it is never required
> to actually send such a frame, there is no observable means of
> distinguishing between a device that CAN send PAUSE frames but chooses
> not to, and a device that is incapable of sending PAUSE frames. Since
> there is no distinction, you are free to advertise a capability that you
> will never assert!
From a network protocol standard point of view, I agree. But from a
customer/purchaser I don't. If I buy a device and its buffer
overflows much of the time I would say that the device isn't working
properly. If the specification sheet says it supports receive PAUSE
but not transmit PAUSE, and buyers know this in advance, well, I
can't argue about it. Still, I won't expect them to stay in
business very long.
For a device with ports running at different speeds, it would
seem that buffers could fill up pretty fast.
-- glen
vsath...@gmail.com
> In article <87ekqp7...@free.fr>, marc.h...@free.fr (M.Herbert) wrote:> I think I now do see why: you just "sacrified" the capability to > advertise RX-only ("I can respond to flow control, but will never > assert it myself") since this case makes sense only from an > exhaustive, theoretical point of view but not in the real world, as > clearly explained above.> > Right?> Sort of. Since *all* of the implementation complexity is in the receiver/parser, there is no great benefit to having the ability to receive without also having the ability to send PAUSE frames.Also, here's another take on it (and we expressly discussed this during the standards meetings). Just because a device has the *capability* to send PAUSE frames does not mean that it must ever actually send one. There is no algorithm or specification of when it is appropriate (or necessary) to assert flow control; it is left as application-dependent.That said, assume that you do have a device that can receive, but not send PAUSE frames. There is no problem if the device advertises that it CAN send PAUSE frames (even though it can't). Since it is never required to actually send such a frame, there is no observable means of distinguishing between a device that CAN send PAUSE frames but chooses not to, and a device that is incapable of sending PAUSE frames. Since there is no distinction, you are free to advertise a capability that you will never assert! > > It seems this protocol is so unfriendly that people developping > ethernet configuration interfaces don't have the time to understand it > (I guess they just don't care). They keep providing user-friendly (but > wrong!) independent TX and RX settings. It seems no one mentions that > advertising RX capability implies advertising TX capability (assuming > this is the way they implement it :-(> The underlying protocol mechanism does not have to map 1:1 to the user interface. Since (as discussed above), one can advertise symmetrical PAUSE capability, yet (internally) decide never to send any PAUSE frames, it is perfectly feasible to construct a user or programming interface that gives the appearance of "truly independent" transmit/receive functionality. I would argue that such a user interface is more intuitive than the protocol mechanism, and that is a Good Thing(tm).> One must admit that their task is complicated since on the other hand, > the _manual_ configuration obviously allows independent configuration > of TX and RX (or not?)> Assuming that I have a device with symmetric PAUSE capability, I can choose to enable the transmit and receive functions independently, via manual configuration. However (as discussed above), I can do this using Auto-Negotiation as well (even though the protocol mechanism has no such express encoding).> > - On the other hand, Sun Gigaswift User's guide (for Solaris) shows > two "adv-pause-cap" and "adv-asmpause-cap" settings. At least > something consistent with reality! On the other, other hand, it > seems there is no way to manually configure TX and RX.>Here, Sun has simply passed the raw protocol mechanism to the user as a programming interface. This is the easiest approach from an engineering perspective, but makes poor sense to a user/programmer. As you note, it is easier to conceptualize that the interface has independent transmit and receive flow control. That is the metaphor that belongs in the user interface, NOT the (admittedly ugly, but more efficient) protocol signaling bits.> > One problem I had with The Book is that the autonegociation protocol > is very well described in the optical section of this "physical layer" > chapter 12, but the equivalent for UTP is located elsewhere far away > (in the "automatic configuration" chapter), a bit redundant-ly, much > less exhaustive, and less up-to-date: no asymmetry! It seems that, > since the book preceded the 1000Base-T standard, you were very careful > not say anything about 1000Base-T autonegociation and asymmetry, > whereas it ends up being... the very same autonegociation as > 1000Base-X.That's correct. When I wrote the book, 1000BASE-X was just completed, and 1000BASE-T was many months away. Since lots of things can change during the development of a standard, I was reluctant to include details that might well turn out to be wrong once the standard was finalized. Thus, there is nothing about 1000BASE-T Auto-Negotiation; the chapter on "Automatic Configuration" covered the historical stuff (10/100BASE-T) only.> "Gigabit Ethernet" - 2nd edition anyone ? :-)> There was strong interest from the publisher to do this. We actually have a contract in place, the outline is signed off, and I was ready to move ahead when my personal interests changed somewhat, and the project became no longer feasible. (Here's a decode of that last sentence: For the past two years, I have put most of my technology work on hold and am now a second-year law student at Santa Clara University. Law school consumes most of my time and energy; I still sit on some corporate boards and do some consulting, but there are insufficient spare hours to do a book at this time.)--Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way(408) 395-5700 Los Gatos, CA 95033 (408) 395-1966 FAXSend replies to: usenet at richseifert dot com
The problem in the implementation (as said in the standard) will appear when the two non-legacy devices are connected(i.e) both devices are able to understand both
PAUSE and ASM_DIR bit. But before jumping into the problem, I will explain the root cause for the issue.
Encoding table from IEEE std :
######################################################################
Table 28B–2—Pause encoding
PAUSE (A5) ASM_DIR (A6) Capability
0 0 No PAUSE
0 1 Asymmetric PAUSE toward link partner
1 0 Symmetric PAUSE
1 1 Both Symmetric PAUSE and Asymmetric PAUSE toward local device
#####################################################################
The following are the possible cases that can be configured in a device. The encoding of PAUSE and ASM_DIR is derived from the IEEE std table,
################################################################################
Case RX TX Asymmetric capability Make sense? PAUSE ASM_DIR
################################################################################
1 0 0 0 Yes 0 0
2 0 0 1 No
3 0 1 0 No
4 0 1 1 Yes 0 1
5 1 0 0 No
6 1 0 1 Yes 1 1
7 1 1 0 Yes 1 0
8 1 1 1 Yes 1 1
################################################################################
As you can see, there are 5 different possibilities that make sense. (Case 7 means, the device is legacy and can support only symmetric flowcontrol. Case 8 is a device
which can support asymmetric flowcontrol as well). But we are encoding these 5 possibilities into 2 bits. Clearly, while doing that we are encoding 2 of the 5
possibilities into one coding. I hope you are able to understand why I marked certain cases as "Doesn't make sense", for example, in case #3, a device can only be
asymmetric capable (because only TX = ON ).
Now I will explain the problem. Let us say I enable (RX=ON; TX=OFF) in local end and the peer end with (RX=ON; TX=OFF). Under this condition, both the local admin and
the peer admin would like only to honor the PAUSE frames and NOT send any PAUSE frames from their device. As per the above table, the local end will transmit (
PAUSE=1;ASM_DIR=1) and the peer end will transmit ( PAUSE=1;ASM_DIR=1). This combination maps to case #6 in the below table.
IEEE 802.3-2000
Table 28B-3
Pause Resolution
Local Remote Local Resolution Remote Resolution
Case PAUSE ASM_DIR PAUSE ASM_DIR TX RX TX RX
################################################################################
1 0 0 x x 0 0 0 0
2 0 1 0 x 0 0 0 0
3 0 1 1 0 0 0 0 0
4 0 1 1 1 1 0 0 1
5 1 0 0 x 0 0 0 0
6 1 x 1 x 1 1 1 1 <<<
7 1 1 0 0 0 0 0 0
8 1 1 0 1 0 1 1 0
Thus, eventhough both the local admin and peer admin want to only honour PAUSE frames, we are making it as flowcontrol RX,TX=OFF on both sides as a result of
resolution.
One solution would be to take into consideration the User config also while writing the capability into hardware. For example, in the above case, eventhough as per the
negotiation we are turning RX=ON and TX=ON; we should check with the user config and turn TX=OFF.
##############################################################################
Rich worte,
> send PAUSE frames. There is no problem if the device advertises that it
> CAN send PAUSE frames (even though it can't). Since it is never required
> to actually send such a frame, there is no observable means of
> distinguishing between a device that CAN send PAUSE frames but chooses
> not to, and a device that is incapable of sending PAUSE frames. Since
> there is no distinction, you are free to advertise a capability that you
> will never assert!
Note that, there are differences between devices that that CAN send PAUSE frames but chooses not to, and a device that is incapable of sending PAUSE frames. For
example, a network admin might turn RX=ON,TX=OFF eventhough the device is capable of RX=ON, TX=ON. What most vendors do is they configure the hardware based on negotiation result and ignore the user config.
-Shathish