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
>
next prev parent 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