From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8CCE0201768 for ; Sun, 29 May 2011 08:51:18 -0700 (PDT) Received: by iyi20 with SMTP id 20so3824484iyi.16 for ; Sun, 29 May 2011 09:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=m7kQxRIE+bL5GwUtf7vTavEtQnBD9VZJqJRDcf3Irc4=; b=S30NI35mWxQRSjxPCoK7G/IPEVpfXGp8yMzhMPywXuquduhd9vPkvf8E7sZgfV7OEo U9mfP2SVtD4FrtBIO6kPTKrKdZjlXyI6JCYqyaYEBzkMv4qneyImnnyApRhs9HIeoYlm CYLWFfr047BEn/PHMPMNndbN67BwjYIg70GEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=QHwf4Ep4wL9Yiqbjl3ATMKFA7SY+gFQw/kvOy6ntKGSv0dJgJSNUz90e3REQRr1DyT N+39hHn+lnHWxIpmaHON8pGs4JujLLT9vnONU6MtLif1wlvyRQSr0j/eHzWUBBeM3/75 8EpP2hUX0EQUtS9Su5l/r3oNqXnKmvSQ0DBbk= MIME-Version: 1.0 Received: by 10.42.40.129 with SMTP id l1mr6078451ice.225.1306685227158; Sun, 29 May 2011 09:07:07 -0700 (PDT) Received: by 10.231.39.203 with HTTP; Sun, 29 May 2011 09:07:07 -0700 (PDT) In-Reply-To: <7i62otpks1.fsf@lanthane.pps.jussieu.fr> References: <7ifwnxbjyn.fsf@lanthane.pps.jussieu.fr> <7i62otpks1.fsf@lanthane.pps.jussieu.fr> Date: Sun, 29 May 2011 10:07:07 -0600 Message-ID: From: Dave Taht To: bloat Content-Type: multipart/alternative; boundary=90e6ba6e8a3ccc4bac04a46c5cbb Subject: Re: [Bloat] tiny monsters: multicast packets X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 15:51:18 -0000 --90e6ba6e8a3ccc4bac04a46c5cbb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, May 29, 2011 at 9:51 AM, Juliusz Chroboczek wro= te: > >> Are you seeing high CPU load in interrupt context? (Run top.) > > > Yes. 99% sirq. > > Could be due to a simplistic Ethernet driver. If you have the time and > energy, you may want to ask on dev.openwrt.org. > > I will have some energy and time, shortly. That said, several great openwrt people are on this list, and may be able t= o weigh in. I'm glad that the limit of about 130Mbit on the ethernet side for gigE coul= d be mitigated with a better driver. (and that said, 130Mbit is "good enough" for most of the world) On the other hand, making the switch that lays underneath this driver, work well, looks hard. Does anybody here speak enough Taiwanese to get enough detail on the rtl8366s to see what it would take to enable fair queueing and port mirroring? or have a relationship with realtek they could use to get this info? The datasheet has insufficient detail, and yet the switch seems enormously capable, at least in theory. The kind of numbers under load I've seen thus far (ranging from .9ms to 170ms) suggest port starvation. http://realtek.info/pdf/rtl8366s_8366sr_datasheet_vpre-1.4_20071022.pdf > -- Juliusz > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --90e6ba6e8a3ccc4bac04a46c5cbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, May 29, 2011 at 9:51 AM, Juliusz= Chroboczek <jch= @pps.jussieu.fr> wrote:
>> Are you seeing high CPU load in interrupt contex= t? =A0(Run top.)

> Yes. 99% sirq.

Could be due to a simplistic Ethernet driver. =A0If you have the time= and
energy, you may want to ask on dev.openwrt.org.

I will have some energ= y and time, shortly.

That said, several great openwrt people are on= this list, and may be able to weigh in.

I'm glad that the limit of about 130Mbit on the ethernet side for gigE=20 could be mitigated with a better driver. (and that said, 130Mbit is=20 "good enough" for most of the world)

On the other hand, making the switch that lays underneath this driver, = work well, looks hard.

Does anybody here speak enough Taiwanese to get enough detail on the=20 rtl8366s to see what it would take to enable fair queueing and port=20 mirroring?

or have a relationship with realtek they could use to get this info?
The datasheet has insufficient detail, and yet the switch seems enormously=20 capable, at least in theory. The kind of numbers under load I've seen= =20 thus far (ranging from .9ms to 170ms) suggest port starvation.

http://realtek.info/pdf/rtl8366s_8366sr_data= sheet_vpre-1.4_20071022.pdf

=A0
-- Juliusz



--
Dave T=E4ht
S= KYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--90e6ba6e8a3ccc4bac04a46c5cbb--