netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sven-Thorsten Dietrich <sven@thebigcorporation.com>
To: Clark Williams <williams@redhat.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
	linux-rt-users@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: Network performance forwarding tests on RT
Date: Fri, 07 Nov 2008 13:22:43 -0800	[thread overview]
Message-ID: <1226092963.5685.14.camel@dd> (raw)
In-Reply-To: <20081106185029.0d4c5cd8@redhat.com>

On Thu, 2008-11-06 at 18:50 -0600, Clark Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 5 Nov 2008 11:52:05 -0800
> Stephen Hemminger <shemminger@vyatta.com> wrote:
> 
> > As an experiment, I rebuilt a version of Vyatta using 2.6.26-rt11 kernel.
> > This required some fixes to unionfs and aufs which I'll send to anyone who wants.
> 
> I'd like to see those fixes.

I have seen the same issues, and I think I had a patch for these laying
around - I'll defer to Stephen for his version.

> 
> > 
> > The performance of the RT PREEMPT kernel is worse than non-PREEMPT kernel.
> > 
> > Running RFC2544, frame loss test we the loss rate is worse on RT than non RT.
> > Ideally, there would be no loss, but on this platform, the best we have
> > seen is 70% loss at 64 bytes.
> > 
> 
> We've seen that as you push the workloads up to max, the additional overhead of rt_mutexes starts to show and the performance of the RT kernel drops off.  So if you're trying to push the maximum amount of bits across a wire and you don't care about event latency, then I wouldn't recommend an RT kernel. 
> 
> > 
> > Size	2.6.26		2.6.26-rt11
> > 64	80.5%		99%
> > 128	67		99
> > 256	43		92
> > 512	0		54
> > 1024	0		3
> > 1280	0		0
> > 1518	0		0
> > 
> > More importantly, with RT PREEMPT, the driver gets stuck and times out
> > under heavy load (see 99% loss above). It appears the change to network
> > scheduling related to NAPI doesn't work well under load.
> > 
> 
> Did you do anything with the priorities of interrupt threads? We generally boost hard IRQ threads (show up as [IRQ-xxx] in a ps) to SCHED_FIFO 80-85 and boost the softirq threads to between 70-75.
> 
> Since interrupt processing in RT takes place in SCHED_FIFO kernel threads, if you push the load up high enough, it's entirely possible to starve lower priority softirq/hardirq threads in the system.

ON SMP, you can also affinitize the threads on different CPUs. 

Check out Cset on the RT Wiki.

Sven

>  
> Clark
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> 
> iEYEARECAAYFAkkTkNsACgkQHyuj/+TTEp1/oACdGj3cEsNTFD3zG1uXrJSnORx8
> 1RkAoKYAPCAQ4ALi5NPRMNbEE6CjkZQj
> =kO9h
> -----END PGP SIGNATURE-----
> NrybXv^){.n+{z"^nrz\x1ah&\x1eGh\x03(j"\x1a^[mzfh~m


      parent reply	other threads:[~2008-11-07 21:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-05 19:52 Network performance forwarding tests on RT Stephen Hemminger
2008-11-07  0:50 ` Clark Williams
     [not found]   ` <ccb913ac0811062303r7f94f8a8lfe48336d6dafb9f6@mail.gmail.com>
2008-11-07 16:52     ` Stephen Hemminger
2008-11-07 21:22   ` Sven-Thorsten Dietrich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1226092963.5685.14.camel@dd \
    --to=sven@thebigcorporation.com \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    --cc=williams@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).