Abysmal re(4) performance under 8.1-STABLE (mid-August)
pyunyh at gmail.com
Tue Nov 16 02:03:30 UTC 2010
On Sun, Nov 14, 2010 at 10:41:03AM +0100, Ulrich Sp??rlein wrote:
> On Mon, 08.11.2010 at 22:41:12 +0100, Ulrich Sp??rlein wrote:
> > On Sun, 07.11.2010 at 15:10:20 -0800, Pyun YongHyeon wrote:
> > > On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Sp??rlein wrote:
> > > > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote:
> > > > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp??rlein <uqs at spoerlein.net> wrote:
> > > > > > Hello Pyun,
> > > > > >
> > > > > > On this new server, I cannot get more than ~280kByte/s up/downstream out of
> > > > > > re(4) without any tweaking.
> > > > > >
> > > > > > re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > > > > > ?? ?? ?? ??options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
> > > > > > ?? ?? ?? ??ether 00:21:85:63:74:34
> > > > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1
> > > > > > ?? ?? ?? ??inet 220.127.116.11 netmask 0xffffffc0 broadcast 18.104.22.168
> > > > > > ?? ?? ?? ??nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
> > > > > > ?? ?? ?? ??media: Ethernet autoselect (100baseTX <half-duplex>)
> > > > > > ?? ?? ?? ??status: active
> > > > > >
> > > > >
> > > > > It seems the link was resolved to half-duplex. Does link partner
> > > > > also agree on the resolved speed/duplex?
> > > >
> > > > As this is a dedicated server in a colo hundreds of km away, I have no
> > > > means to check this easily. Especially I cannot change the setting from
> > > > auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool.
> > > >
> > >
> > > I guess you can contact network administrator of the data center to
> > > check the switch configuration. IEEE 802.3 says if link parter use
> > > forced full-duplex media and you use auto media, the resolved
> > > duplex is half-duplex by definition. I think RealTek may have
> > > followed the standard. There is no reason to use manual media
> > > configuration unless your link partner is severely broken with
> > > auto-negotiation.
> > >
> > > Due to silicon bug of RealTek PHYs, rgephy(4) always use
> > > auto-negotiation so manual media configuration is a kind of
> > > auto-negotiation with limited set of available media advertising.
> > > I don't know how Linux solve the silicon bug though. One of magic
> > > DSP fixups might fix the issue, the DSP fixups vendor released is
> > > not under BSD license and does not say more detailed information
> > > for the code.
> > Luckily the provider switch me to another switch that is set to
> > autoneg, instead of hardcoded to 100/full. re(4) now happily transfers
> > with reasonable speeds, ie. 11MByte/s.
> Alas, spoken too soon. While the throughput is now up to speed, I have
> severe problems with packet loss on this device. Again, the linux rescue
> system works fine, but under a recent -STABLE (including your latest
> MFCs) I get an average packet loss of 10-20%. But it is not constant,
> meaning every 5th packet or so, but instead will drop no packets for
> minutes-hours and then blackout for 1-5 min straight (these times are
> estimates, I haven't used a stop watch or anything.)
> At first, putting the card into promisc mode seemed to alleviate the
> issue, but the average ping packet loss during the last 10h was again up
> to 10%. Due to the "blackout" nature, this drops all TCP sessions and is
> really annoying.
> Do you have any other ideas that I could try? Or should I simply switch
> to a different hardware altogether?
Could you try latest re(4) in HEAD? It has a new feature that
displays hardware MAC counters and it contains a couple of PHY
access enhancements. You would get the MAC counters on console with
"sysctl dev.re.0.stats=1". And let me know how many frames were
More information about the freebsd-stable