Confusion with RT priorities of MPD threads

Need help with MPD?
Post Reply
tuxx
Posts: 20
Joined: March 21st, 2015, 5:21 pm

Confusion with RT priorities of MPD threads

Post by tuxx »

Hi all,

I was recently reading the MPD documentation and I saw that rtio and output threads of MPD use the FF real-time scheduler and have a real-time priority.

My output is:

Code: Select all

ps H -q `pidof -s mpd` -o 'pid,tid,cls,rtprio,comm'

Code: Select all

  PID   TID CLS RTPRIO COMMAND
  478   478  TS      - mpd
  478   498  TS      - io
  478   499  FF     50 rtio
  478   500  TS      - player
  478   501  TS      - decoder:sndfile
  478   502  FF     50 output:9018k2m
However my OS is not RT (in fact my current testing kernel does not even use CONFIG_PREEMPT ) . What is happening in this situation?

What are FF and 50 doing on a non RT OS like mine? Do they have any effect or no?

Thank you in advance.

max
Forum team
Posts: 985
Joined: January 15th, 2013, 3:43 pm

Re: Confusion with RT priorities of MPD threads

Post by max »

"my OS is not RT" means you run the Linux kernel without the preempt-rt patch?

The vanilla Linux kernel has a real-time scheduler, and that is what MPD uses. But the Linux kernel is not a hard real-time kernel. For the purposes of playing music, it does not need to be. MPD's latency requirements for stutter-free playback are very relaxed, and nobody gets hurt if MPD stutters once in a blue moon.

The preempt-rt patch makes more internal kernel operations preemptible and has a bunch of other optimizations to reduce the kernel's latency and give better latency guarantees (which still doesn't make Linux a hard real-time kernel, just better). But what it does not is add a real-time scheduler. Because that scheduler has already been merged 13 years ago into the vanilla kernel.

Yes, the real-time scheduler has an effect. Under heavy load situations, the kernel tries very hard to give MPD enough CPU time to keep the music running, which reduces the chance of stuttering.

TL;DR the vanilla kernel is just fine for you, because it has everything MPD needs

tuxx
Posts: 20
Joined: March 21st, 2015, 5:21 pm

Re: Confusion with RT priorities of MPD threads

Post by tuxx »

Hi Max,

thank you very much for your reply.

As far as I know there are 3 levels of "real-time" kernel:

1. Real Time Kernel (Linux kernel with the CONFIG_PREEMPT_RT patch)
2. Vanilla Linux kernel with CONFIG_PREEMPT
3. Vanilla Linux kernel without CONFIG_PREEMPT

As I am writing these words, I am doing some tests and my kernel does not even use CONFIG_PREEMPT. So my current case is 3 and I was wondering if I get any benefit from the FF scheduler and PR 50.

As I understand there is always a benefit from FF scheduler and a real-time priority and options 1, 2 and 3 just reduce/increase the overall latency.

Thanks again!

max
Forum team
Posts: 985
Joined: January 15th, 2013, 3:43 pm

Re: Confusion with RT priorities of MPD threads

Post by max »

tuxx wrote:
December 13th, 2019, 2:13 pm
As I understand there is always a benefit from FF scheduler and a real-time priority and options 1, 2 and 3 just reduce/increase the overall latency.
True.

A real-time CPU scheduler and kernel preemption are orthogonal features. Both help with keeping real-time deadlines.

Note that kernel preemption doesn't come for free. It adds overhead, and thus wastes some CPU. It's a trade-off.

tuxx
Posts: 20
Joined: March 21st, 2015, 5:21 pm

Re: Confusion with RT priorities of MPD threads

Post by tuxx »

Max,

Thank you very much for your clarifications.

For the rest of the MPD threads, shouldn't we care at all? Would a renice of -16 or -18 or any other suggested vaule be a good idea for them?

max
Forum team
Posts: 985
Joined: January 15th, 2013, 3:43 pm

Re: Confusion with RT priorities of MPD threads

Post by max »

tuxx wrote:
December 13th, 2019, 3:11 pm
For the rest of the MPD threads, shouldn't we care at all? Would a renice of -16 or -18 or any other suggested vaule be a good idea for them?
MPD uses large buffers, so playback can survive even when non-realtime threads don't get scheduled for several seconds. Only output and rtio are vital for playback, because those are the ones who fill the hardware buffer, and the hardware buffer is usually small (in the tens or hundreds of milliseconds). If those threads don't get scheduled for 500ms to refill the DAC hardware buffer, your DAC will get angry.
No, I wouldn't renice those other threads. There's no real justification for why those should be more important than other threads on your computer.

tuxx
Posts: 20
Joined: March 21st, 2015, 5:21 pm

Re: Confusion with RT priorities of MPD threads

Post by tuxx »

Thank you very much for your answers Max!

Post Reply