Quote:>Thanks for the very interesting ndd part!!!
>So I see my own server seems to use only 10MBit/s at the moment
>ndd -get /dev/eri link_mode
>0
link_mode tells the link is in half-duplex mode, but says nothing
about the speed, the speed you'd get by querying link_speed.
Quote:>But unfortunately I seem not able to set anything on my Sun:
># ndd -set /dev/eri link_mode 1
>operation failed: Permission denied
Yes, the status variables are read-only, however they're somewhat
controlled by other, writable variables.
Quote:># ndd -get /dev/eri \?
...
>adv_autoneg_cap (read and write)
>adv_100T4_cap (read and write)
>adv_100fdx_cap (read and write)
>adv_100hdx_cap (read and write)
>adv_10fdx_cap (read and write)
>adv_10hdx_cap (read and write)
...
So, there are the ones you can set per interface. "adv" as in advertise,
"cap" as in capability. Default is to advertise all but 100T4. The
mode selection can be restricted by setting one or more of these to
zero. Note though, that just doing f.ex.
ndd -set /dev/eri adv_100hdx_cap 0
does not take effect until setting the adv_autoneg_cap. So, even if you
were happy of the current value of adv_autoneg_cap, you must write its
value to make effective the other changes.
Before making any changes, it's good to find out what capabilities are
advertised bu the link partner (the switch, that is). These you get by
querying:
Quote:>lp_autoneg_cap (read only)
>lp_100T4_cap (read only)
>lp_100fdx_cap (read only)
>lp_100hdx_cap (read only)
>lp_10fdx_cap (read only)
>lp_10hdx_cap (read only)
... the significant being lp_autoneg_cap (i.e. does the link partner have
automatic link speed/mode negotiation enabled). If this is zero, the all
the others will be zero as well (and you must find whoever configured the
switch port to tell you what settings are forced there).
One more thing; the changes made with ndd are not persistent - the values
are only kept until next reboot. To make the changes permanent, you'll
need to edit /etc/system. Google for "/etc/system adv_100fdx_cap" to find
the proper syntax (also described in some books on docs.sun.com; something
may also be in manual page for "eri").
As I wrote in my earlier message, the issue is not to force full duplex;
the issue is to make parameters equal at both ends of the cable. Most
often the automatic negotiation handles this (if either end of the link
has negotiation disabled, then negotiation must be disabled on both ends
AND both ends must be forced to equal mode). When your hardware is less
than 5 years in age, the negotiation should work just fine; earlier than
that were not implementing the specifications so well - and apparently
even the specs were not that well settled then, so for older hardware
forcing the mode might be the only properly working option - but for
anything even remotely current disabling the negotiation typically
creates more problems than solves.
With negotiation, when a cable link becomes active (a machine is powered
up, or a able is connected), both ends start sending and listening for
special negotiation packets. These packets contain simple bit array about
modes supported at the sending end, so 100fdx, 100hdx, 10fdx and 10hdx.
When a machine configured for negotiation receives this kind of packet,
it looks through its own supported and enabled modes, and picks the first
in from the list in the above order. So, I can have a machine that is
configured for negotiation and 10Mbit/s only operation, and machine
that is configured for all the available modes, and these will negotiate
the link just fine -- the faster machine will see the negotiation packet
sent by the slower machine and will just choose the best mode supported
by the other end.
In a situation where one end of link is forced to some "desired" mode
and has negotiation disabled, but the other end of the link is trying
to negotiate (and has multiple allowed modes), the "flexible" end will
go into "hunt" mode (after timing out on waiting for the negotiation
packets), and will start going through the modes in order 10hdx, 10fdx,
100hdx, 100fdx. Sounds good, going from worst to best - especially
considering that traditionally the devices that have not been able to
negotiate have been the legacy systems only capable of half-duplex
communication - so this approach has ended up in both ends of the link
in matching modes. What happens today, however, is that some people,
remembering the old problems with negotiation, force devices to 100fdx
mode. If this is done, _and_ the other end of the link is trying to
negotiate from unrestricted set of parameters, things go wrong. The
device will try (and fail) first the 10Mbit/s modes, then it will try
the 100Mbit/s half-duplex mode. With this, when the link is not congested,
communication will succeed, even when the other end is configured for
full-duplex, so the device will settle for this, and will neven even
try the full-duplex mode. As a result of this, we have a link where one
end is in 100hdx mode, the other in 100fdx mode; the devices are
communicating, but performance problems arise immediately when the
link gets any significant amount of traffic.
So, with speed mismatch you get no traffic through - so on a link
that passes any traffic you're not having a speed mismatch. A duplex
mismatch will pass traffic through, and with small amounts of traffic
will mostly go unnoticed - but with large amounts of traffic it will
be almost non-functional (much worse than f.ex. a properly configured
half-duplex link).
Summary: Only disable negotiation when you're experiencing trouble that
you can reasonably show being a consequence of problems in negotiation.
(of course, there may be cases with f.ex. stubborn network admins who
only provide switch ports with negotiation disabled -- if this happens
to be your case, then your only remedy is to force the parameters on
the machine side as well).
--
Wolf a.k.a. Juha Laiho Espoo, Finland
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
by