From owner-freebsd-stable@FreeBSD.ORG Tue Nov 16 02:03:30 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 736BE106566B for ; Tue, 16 Nov 2010 02:03:30 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 313D68FC0A for ; Tue, 16 Nov 2010 02:03:29 +0000 (UTC) Received: by iwn39 with SMTP id 39so185180iwn.13 for ; Mon, 15 Nov 2010 18:03:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=fTSHzMeqix0nSnxKlVU5MxAHhQMsEc38BR5hyCkYd0Q=; b=G3ihSxeXomFKKNyIoFiXo1VaFCul6O4qxPuyiUKM3O6YfrpnodMi4lE4dg9o7z2rlo suigyquIUoMQAAUoceAXf16t/pzJIREJRq9gWE1A9fi8ObsQxU+Kp4PS+GhK5AoUwfqt sbtlA6MesCD5DViBE3GBcl4hNgkUBjSsSb9O8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=wCwZ3euvd6eIWDsOlHPN1yoPF8Nfsow1EBXKip0hOT5u+K9PbUUnWUtBZaDZ6pqS+w GwCGMkZgQvDVXIu67cxE3iDKHqdzqFFoEqJ7EJxmC4j73Hi6QwxBFiM82mFjeGQb1KBQ oChZ77Wcrc0OeGo4qPqDFgCU0aFZUm8+XTiog= Received: by 10.42.193.17 with SMTP id ds17mr5067777icb.276.1289873009615; Mon, 15 Nov 2010 18:03:29 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id i16sm523507ibl.6.2010.11.15.18.03.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Nov 2010 18:03:27 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 15 Nov 2010 18:03:25 -0800 From: Pyun YongHyeon Date: Mon, 15 Nov 2010 18:03:25 -0800 To: uqs@spoerlein.net Message-ID: <20101116020325.GI1257@michelle.cdnetworks.com> References: <20101106093700.GW85693@acme.spoerlein.net> <20101107112421.GH85693@acme.spoerlein.net> <20101107231020.GB1279@michelle.cdnetworks.com> <20101108214112.GY85693@acme.spoerlein.net> <20101114094103.GA64243@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101114094103.GA64243@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: Abysmal re(4) performance under 8.1-STABLE (mid-August) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 02:03:30 -0000 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 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 metric 0 mtu 1500 > > > > > > ?? ?? ?? ??options=389b > > > > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > > > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 > > > > > > ?? ?? ?? ??nd6 options=3 > > > > > > ?? ?? ?? ??media: Ethernet autoselect (100baseTX ) > > > > > > ?? ?? ?? ??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 dropped.