public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nate Diller <nate.diller@gmail.com>
To: awesley@acquerra.com.au
Cc: Roger Heflin <rheflin@atipa.com>, linux-kernel@vger.kernel.org
Subject: Re: kernel 2.6.13 buffer strangeness
Date: Fri, 9 Sep 2005 17:35:20 -0700	[thread overview]
Message-ID: <5c49b0ed0509091735436260bb@mail.gmail.com> (raw)
In-Reply-To: <432225E0.9030606@acquerra.com.au>

On 9/9/05, Anthony Wesley <awesley@acquerra.com.au> wrote:
> Hi Nate and Roger,
> 
> First off, thanks fo taking some time to answer my call for help :-)
> 
> I've already spent some time fiddling with dirty_ratio before I posted my
> question - yes, I can make different things happen by increasing or
> decreasing it, but overall I still have the same problem - my video
> streaming runs out of steam after at most 50 seconds instead of the 3
> minutes that I think it should take.
> 
> Setting dirty_ratio and dirty_background_ratio to 15/10 respectively makes
> things worse, I hit the wall after only about 25 seconds.
> 
not surprising

> Setting dirty_ratio and dirty_background_ratio to 85/80 makes things worse -
> disk writes start after about 15 seconds and I hit the wall after about 35
> seconds.
> 
so dirty_background_ratio is working, that's why it took a long time
to start writing anything out

> Setting dirty_ratio and dirty_background_ratio to 90/10 puts me back at
> around 50 seconds, i.e. where I started.
> 
this setting should do the trick, so there's something going on here
that isn't expected.

> So as far as I can see there is *no way* to get 3 minutes worth of buffering
> by adjusting these parameters.
> 
> Just to remind everyone - I have video data coming in at 25MBytes/sec and I
> am writing it out to a usb2 hard disk that can sustain 17MBytes/sec. I want
> my video capture to run at full speed as long as possible by having the
> 7MBytes/sec deficit slowly eat up the available RAM in the machine. I have
> 1.5Gb of RAM, 1.3Gb available for buffers, so this should take 3 minutes to
> consume at 7MBytes/sec.
> 
> So, I've tried all the combinations on dirty_ratio and
> dirty_background_ratio and they *do not help*.
> 
dirty_ratio is the tubable you want, if it's not working correctly,
either there's a problem with your setup, or a bug

> Can anyone suggest something else that I might try? The goal is to have
> 25MBytes/sec streaming video for about 3 minutes. 
> 
how sure are you that you're getting 17MB/s during this test?  can you
run "vmstat 1" while this is running to verify?  which FS and
scheduler?

just for interest, what's the raw disk bandwidth (use hdparm, or run a
dd, or something)?  it would obviously be much better to sustain
25MB/s to disk

> Or is this simply not possible with the current kernel I/O setup? Do I have
> to do something elaborate myself, like build a big RAM buffer, mount the
> disk synchronous, do the buffering myself in userland...??
> 
this should be possible, although it could be considered a bit risky WRT OOM.

NATE

> regards, Anthony
> 
> Nate Diller wrote:
> 
> > On 9/9/05, Roger Heflin <rheflin@atipa.com> wrote:
> > 
> >>I saw it mentioned before that the kernel only allows a certain
> >>percentage of total memory to be dirty, I thought the number was
> >>around 40%, and I have seen machines with large amounts of ram,
> >>hit the 40% and then put the writing application into disk wait
> >>until certain amounts of things are written out, and then take
> >>it out of disk wait, and repeat when it again hits 40%, given your
> >>rate different it would be close to 40% in 50seconds.
> >>
> > 
> > yes, on 2.6 there are two tunables which are important here. 
> > dirty_background_ratio is the threshold where the kernel will begin
> > flushing dirty buffers, so it should change how soon the disk becomes
> > active.  dirty_ratio changes when the write-throttling code kicks in,
> > which is what Anthony is seeing.  The purpose of the write throttling
> > code is to limit the dirtying process to disk bandwidth, so that is a
> > Feature.  Anthony, try *increasing* dirty_ratio, you can go up to 100,
> > but you could trigger an OOM if you let it get too high, so maybe try
> > setting it at 85 or so.  This should effectively disable the write
> > throttling and give you the bandwidth you want.
> > 
> > NATE
> > 
> > 
> >>And I think that you mean MB(yte) not Mb(it).
> >>
> >>                           Roger
> >>
> >>
> >>>-----Original Message-----
> >>>From: linux-kernel-owner@vger.kernel.org 
> >>>[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of 
> >>>Anthony Wesley
> >>>Sent: Friday, September 09, 2005 4:11 AM
> >>>To: linux-kernel@vger.kernel.org
> >>>Subject: Re: kernel 2.6.13 buffer strangeness
> >>>
> >>>Thanks David, but if you read my original post in full you'll 
> >>>see that I've tried that, and while I can start the write out 
> >>>sooner by lowering /proc/sys/vm/dirty_ratio , it makes no 
> >>>difference to the results that I am getting. I still seem to 
> >>>run out of steam after only 50 seconds where it should take 
> >>>about 3 minutes.
> >>>
> >>>regards, Anthony
> >>>
> >>>--
> >>>Anthony Wesley
> >>>Director and IT/Network Consultant
> >>>Smart Networks Pty Ltd
> >>>Acquerra Pty Ltd
> >>>
> >>>Anthony.Wesley@acquerra.com.au
> >>>Phone: (02) 62595404 or 0419409836
> >>>
> >>>-
> >>>To unsubscribe from this list: send the line "unsubscribe 
> >>>linux-kernel" in the body of a message to 
> >>>majordomo@vger.kernel.org More majordomo info at  
> >>>http://vger.kernel.org/majordomo-info.html
> >>>Please read the FAQ at  http://www.tux.org/lkml/
> >>>
> >>
> >>-
> >>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> >>the body of a message to majordomo@vger.kernel.org
> >>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>Please read the FAQ at  http://www.tux.org/lkml/
> >>
> > 
> > 
> 
> -- 
> Anthony Wesley
> Director and IT/Network Consultant
> Smart Networks Pty Ltd
> Acquerra Pty Ltd
> 
> Anthony.Wesley@acquerra.com.au
> Phone: (02) 62595404 or 0419409836
>

  reply	other threads:[~2005-09-10  0:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-09  9:11 kernel 2.6.13 buffer strangeness Anthony Wesley
2005-09-09 15:09 ` Roger Heflin
2005-09-09 21:39   ` Nate Diller
2005-09-10  0:16     ` Anthony Wesley
2005-09-10  0:35       ` Nate Diller [this message]
2005-09-10  1:07         ` Anthony Wesley
2005-09-10  1:47           ` Nate Diller
2005-09-10  2:23             ` Anthony Wesley
     [not found]               ` <5c49b0ed05090922021b8f8112@mail.gmail.com>
2005-09-10  5:32                 ` Anthony Wesley
2005-09-10  6:02                 ` kernel 2.6.13 buffer strangeness - FIXED Anthony Wesley
2005-09-10 10:23                 ` kernel 2.6.13 buffer strangeness - ext2/3/reiser4/xfs comparison Anthony Wesley
2005-09-10 11:42                   ` Andrew Morton
2005-09-10 11:56                     ` Anthony Wesley
2005-09-10  0:50     ` kernel 2.6.13 buffer strangeness Anthony Wesley
2005-09-10  5:41       ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2005-09-09  8:14 Anthony Wesley
2005-09-09  8:24 ` David Lang

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=5c49b0ed0509091735436260bb@mail.gmail.com \
    --to=nate.diller@gmail.com \
    --cc=awesley@acquerra.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rheflin@atipa.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