From owner-freebsd-stable@FreeBSD.ORG Sun Nov 7 23:11:19 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 F10A3106566C for ; Sun, 7 Nov 2010 23:11:19 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A42148FC08 for ; Sun, 7 Nov 2010 23:11:19 +0000 (UTC) Received: by yxl31 with SMTP id 31so3181669yxl.13 for ; Sun, 07 Nov 2010 15:11:19 -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:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=oZArevvnQbjePFnrABziZwobllOvhu7oBOznUVep2YA=; b=J4iH/7G8dwecA4dcX0HgcuUJYdAl1EqR+h30fCjFr5xtwzhHJHxekJEUJP9kOAcG3F 8nCYqGdB/vu9PKrGZtZuL64N6yag1+lBmGnqt4PoffOkAVuMw4+TWBVhnxvlqN/nSZnA /lP7nm/ODoAhMyvm5dmsTI6wnTC71cbUZJauA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Xgb3fOaxnd7V7Onrnljlq3QE1Oe0b/Wpsi356S7u4MbxF6Sak7mzA6vPgPpO5wjklE gmu1eaXoaoQw6pU/Juh9Li7UHnNwN+PTbhFSCDdAsgGDBkgTZVZ82TjXZwf2n+NyQ7ue xAGmS1Gw/JXUWyic+j0yA5iyQQ8xt90ufwhVY= Received: by 10.150.143.14 with SMTP id q14mr5907344ybd.3.1289171478915; Sun, 07 Nov 2010 15:11:18 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id p38sm1825700ybk.16.2010.11.07.15.11.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 07 Nov 2010 15:11:17 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 7 Nov 2010 15:10:20 -0800 From: Pyun YongHyeon Date: Sun, 7 Nov 2010 15:10:20 -0800 To: stable@freebsd.org Message-ID: <20101107231020.GB1279@michelle.cdnetworks.com> References: <20101106093700.GW85693@acme.spoerlein.net> <20101107112421.GH85693@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101107112421.GH85693@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i Cc: 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: Sun, 07 Nov 2010 23:11:20 -0000 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. > > > # ifconfig re0 > > > re0: flags=8843 metric 0 mtu 1500 > > > ?? ?? ?? ??options=88 > > > ?? ?? ?? ??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 100baseTX (100baseTX ) > > > ?? ?? ?? ??status: active > > > > > > > This time, it seems you used forced media configuration > > instead of auto. It still shows duplex mismatch so it's > > normal to see poor performance. What makes me wonder > > is why you have duplex mismatch? > > Did you use forced media configuration on link partner? > > What happens when you use different switch? > > Sadly, none of these options are available to me :/ > But even 100/half should give more than enough performance, right? > No, with half-duplex link, you can't send frames while RX is in progress. The reverse is also true for half-duplex link. The more severe problem is your link partner think it established full-duplex link so it does not care about possible collisions. Either change your link partner's media configuration to half-duplex or auto. auto is preferred one, of course.