Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [EN] Actually I wanted ... but  (Read 7039 times)

Offline ralul

  • User
  • Posts: 1.814
[EN] Actually I wanted ... but
« on: 2012/07/17, 15:03:05 »
Actually as siduction has its anniversary I had wanted to propose to Towo to realease a new BFS featured siduction kernel.

Con Kolivas had released a new bug fixed BFS 424, linux-3.4-ck3 a few weeks ago. But nevertheless I get strange process times. Notably there is a "rcuc" thread running over the top in the "millions" of his process time. This doesn't crash down the system but made me suspicious. The scheduler is such a central infrastructure, there should be no bugs at all!

It motivated me to make some experiments with interesting results!

@Towo, the RCU subsystem is a common memmory management subsystem?
(I remember the "big kernel lock" issue was there?)

Setting from default 500 to
CONFIG_RCU_BOOST_DELAY=1000
I got a crazy Linux-Bfs system: Throughput very well, video and sound went uninterruptedly. But no interactivity at all! It even was hard to "pull the trigger" to reboot. But then instead setting
CONFIG_RCU_BOOST_DELAY=100
I got more crazy overflowed process times.

This in mind I just try a brand new Linux-3.4.5 source
- without BFS patches
- CONFIG_RCU_BOOST_DELAY=400
- up a bit: CONFIG_RCU_BOOST_PRIO=9
It seems to provide a better system with just as less latency! But using mainline CFScheduler!

PS: I have a three year old system. Using it on older systems might fail?
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline ralul

  • User
  • Posts: 1.814
Actually I wanted ... but
« Reply #1 on: 2012/07/17, 15:34:43 »
An additional detail:
Generally I observed that setting
CONFIG_HZ_1000=y
does not better latency. Instead it reduces throughput and leakes energy in the dust. If a system is well configured a

CONFIG_HZ_300=y
# CONFIG_NO_HZ is not set
is enough serving for interactivity. CONFIG_NO_HZ does really nothing or very little energy saving.
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline ralul

  • User
  • Posts: 1.814
Actually I wanted ... but
« Reply #2 on: 2012/07/20, 12:35:07 »
Seemingly I found a way to have a more stable experience with BFS. I am just waiting for responses at:
http://ck-hack.blogspot.de/2012/07/bfs-424-linux-34-ck3.html?showComment=1342779419986#c5724856803648054229

setting up
CONFIG_RCU_BOOST_PRIO=14
made the grade ...
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
RE: Actually I wanted ... but
« Reply #3 on: 2012/07/20, 14:54:03 »
as a side note here, a kernel with CONFIG_HZ_300=y isn't usable for audio/midi/video production. In that case, you will feel the latency difference very well. It leads to jitter in the audio output when you play live.


greets
brummer

Offline ralul

  • User
  • Posts: 1.814
RE: Actually I wanted ... but
« Reply #4 on: 2012/07/20, 15:17:10 »
@brummer, as I know you having the RT kernel patches in place, I doubt you have proven this your statement with BFS (not compatible with RT patches).

I am sure you would need to
- increase audio buffers overall (to last 1/300s not only 1/1000s)
- use the jackd task with schedtool -R
- use the audio editing applications with schedtool -I
having a "near" realtime experience with BFS ...
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
RE: Actually I wanted ... but
« Reply #5 on: 2012/07/20, 15:56:00 »
that have nothing to do with BFS or not, it's simply the work frequency of in/output tasks. So, the time accuracy of a synthesiser, for example, depends on this setting. BFS or not.
Realtime in the kernel tree didn't mean "as fast as possible", it mean accuracy, a exact time schedule table, reproducible at any time, under any circumstances, stable in latency. Otherwise you get jitter, like you describe in your statements above.


greets
brummer

Offline ralul

  • User
  • Posts: 1.814
RE: Actually I wanted ... but
« Reply #6 on: 2012/07/20, 16:17:23 »
Yes, for sure regarding accuracy. And the schedtool -R just tries this as well.

But CONFIG_HZ_300:
What is it about? In our times cpus have a factor of several million times more Hertz. I think this frequency is just about the scheduler reappearing to ajust the timeslices of running tasks. Thus bigger buffers should do the trick. Or is your synthesizer hardware somehow hardcoded to small buffers?

If your whole environment is hardcoded to smaller timeslices and smaller buffers you have to do it that way ...
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
RE: Actually I wanted ... but
« Reply #7 on: 2012/07/20, 16:44:36 »
The point is simply that you need accurate time-slices for audio production, and not only therefore, also industrial or medicinal uses needs those. And as smaller they are, as more accurate they are. Therefore you need CONFIG_HZ_1000=y
Also, as bigger your buffer, as higher your latency. So you loss double.

Trying to get faster by loss accuracy cant be the way, isn't it?

Offline ralul

  • User
  • Posts: 1.814
RE: Actually I wanted ... but
« Reply #8 on: 2012/07/20, 17:10:19 »
"Trying to get faster by loss accuracy cant be the way, isn't it?"
Thats why german Autobahn is broad. And Heisenberg physics ...
I mean this is a common scheme.

For audio production I would use CONFIG_HZ_1000 as well, I just doubt your statement it "isn't usable for audio" at all.
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
Re: Actually I wanted ... but
« Reply #9 on: 2012/07/20, 17:42:15 »
For sure I have nothing against that you play around with the BFS scheduler and let us know your results, in opposite, I found it interesting. Just for your statement here:

Quote from: "ralul"
An additional detail:
Generally I observed that setting
CONFIG_HZ_1000=y
does not better latency. Instead it reduces throughput and leakes energy in the dust. If a system is well configured a

CONFIG_HZ_300=y
# CONFIG_NO_HZ is not set
is enough serving for interactivity. CONFIG_NO_HZ does really nothing or very little energy saving.


I have a other conclusion, for sure you increase latency when you switch to CONFIG_HZ_300=y
If you feel it, or not, only depend on what you do with your system.

I clearly speak about audio production, but also any use of the linux kernel in the industry/medicine depend on accuracy.

But anyhow, I'm interested in hearing how you experiences with the BFS going on.   :)

greets
brummer

Offline ralul

  • User
  • Posts: 1.814
Re: Actually I wanted ... but
« Reply #10 on: 2012/07/20, 18:21:21 »
Yes, it was too generally expressed. I wanted to emphasize that another config variable can more effectively manipulate the result:

- down default of: CONFIG_RCU_BOOST_DELAY=500
- up the default of: CONFIG_RCU_BOOST_PRIO=1

might better work in regard of latancy than
- high value: CONFIG_HZ_1000
experiencing siduction runs better than my gentoo makes me know I know nothing