From: Dale <rdalek1967@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Video sometimes stuttering. Need help with ionice, maybe?
Date: Thu, 31 Jul 2025 09:50:37 -0500 [thread overview]
Message-ID: <3a6a5242-f7ea-bcc5-7510-f2380dafbb6e@gmail.com> (raw)
In-Reply-To: <24032501.6Emhk5qWAg@rogueboard>
Michael wrote:
> On Thursday, 31 July 2025 12:25:01 British Summer Time Dale wrote:
>> Peter Humphrey wrote:
>>> On Wednesday, 30 July 2025 18:25:00 British Summer Time Dale wrote:
>>>> I rebooted the new kernel and the BFQ setting is doing a GREAT job. I've
>>>> copied several GBs of data since the change and my videos play like a
>>>> champ. I've yet to see a single stutter or pause.
>>> Have you selected either of the other schedulers as well?
>> From my understanding, you can only select one at a time. So far, this
>> is working wonderfully. A lot better than the previous one. What
>> scheduler ones uses depends on what one needs. For some applications,
>> others may work better. For what I need, BFQ is awesome.
>>
>> Can one use more than one at a time?
>>
>> Dale
>>
>> :-) :-)
> With more than one scheduler trying to manage the IO data queues on the
> device, which scheduler will win the fight? The scheduler which messes up the
> others' queues faster? LOL! :-)
>
> On multi-queue SSDs the difference between IO schedulers is small, so setting
> it to none (noop) removes any pointless kernel load. However, some have
> reported mq-deadline performed slightly better on their gear.
>
> A quick test will prove what scheduler suits best each use case.
That was my thinking. I'm trying to think of a reason why a person
would want to use two different ones anyway. As you point out, one is
going to fight the other. It's likely best to pick the one that works
best for the situation instead of trying to apply two or more and end up
with a nasty fight. May not lose data but could upset a hard drive wear
and tear wise.
Right now, BFQ is doing great. I see no reason to switch to anything
else. From what I've read, and seen in a couple videos, BFQ is the best
option for what I need. I'll share video links below.
You know, my rig and the software I have installed, it has gave me a
awesome system. I'm thinking of upgrading the CPU tho. I have a AMD
Ryzen 7 5800X 8-Core CPU right now. Looking at a 5950X 16 core one.
May be a year off yet tho. I'm not sure how to deal with gkrellm tho.
It already goes from top to bottom of my screen. Additional cores is
going to make it to tall. May have to run more than one gkrellm
somehow. CPU cores, processes and sensor info on one and drive data on
another instance. I gotta think on that.
Video links.
https://www.youtube.com/watch?v=J-e7LnJblm8 Demo of the performance of
the bfq disk I/O scheduler on a hard disk
https://www.youtube.com/watch?v=KhZl9LjCKuU BFQ back in action
and
https://www.youtube.com/watch?v=1cjZeaCXIyM BFQ-v7r6 versus CFQ,
DEADLINE and NOOP on an SSD
Dale
:-) :-)
prev parent reply other threads:[~2025-07-31 14:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-23 7:18 [gentoo-user] Video sometimes stuttering. Need help with ionice, maybe? Dale
2025-07-23 18:44 ` Michael
2025-07-23 21:07 ` Dale
2025-07-30 17:25 ` Dale
2025-07-31 10:36 ` Peter Humphrey
2025-07-31 11:25 ` Dale
2025-07-31 13:22 ` Michael
2025-07-31 14:12 ` [gentoo-user] " Holger Hoffstätte
2025-07-31 14:53 ` Michael
2025-07-31 14:50 ` Dale [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=3a6a5242-f7ea-bcc5-7510-f2380dafbb6e@gmail.com \
--to=rdalek1967@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/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