kern.sched.preemp_tresh

So what does kern.sched.ule.interact actually do? And why does setting it to 0 or 100 'largely "turns off" any impact from interactivity-scoring' ?
So if setting to 0 means nothing is interactive and 100 means everything is interactive, then my understanding is "if everything is equal, then it doesn't have any effect".
Like when your boss gives you 12 tasks you ask "which is highest priority" and the answer is "they are all the highest priority": that tells you none of them are the highest priority so you just "pick one" and start working on it.
 
I don't follow this. The last time I looked, interactivity was a percentage which was added to the nice value to get the priority; the priorities were spit between interactive and batch. Interactive levels were assigned to dedicated queues (one per priority) with the batch levels handled by a ring of queues that guaranteed batch tasks all got some time. So being interactive wasn't a purely boolean distinction because there were many levels handled in priority order.

So what does kern.sched.ule.interact actually do? And why does setting it to 0 or 100 largely turn off any impact from interactivity-scoring ?

That fair, I I did hedge with largely turns off.

I was looking here: https://github.com/freebsd/freebsd-...5c5ea8337054897116/sys/kern/sched_ule.c#L1753

Code:
    score = imax(0, sched_interact_score(td) + nice);
    if (score < sched_interact) {
        [...]
    } else {

If kern.sched.ule.interact is set to 0, the score tested here will never be < 0, and it will never put in the interactive priority ranges, or use the score to adjust priority. Everything will be treated as batch, and scheduled accordingly.

If kern.sched.ule.interact is set to 100, score will (in the absence of nice) typically be less than 100, so most user-space tasks will be put into the interactive priority ranges, and they will have a priority within the interactive range influenced by their score. A "very interactive" process won't get some of the special treatment vs. "somewhat interactive" that it would receive vs a "batch / non-interactive" process.

Basically having the threshold somewhere between 0 and 100 lets it further refine scheduling decisions to favor interactive processes, and the value relates to "just how interactive" (it may seem strange, but "sleeps more than it runs" is the sign for "interactive" as it implies waiting for input) a process has to act to get that special treatment.

Things like "do I preempt some other task running on a different processor to run me" are always answered "yes" if the waiting-to-be-scheduled process is interactive and the victim process is batch.
 
So if setting to 0 means nothing is interactive and 100 means everything is interactive, then my understanding is "if everything is equal, then it doesn't have any effect".
Like when your boss gives you 12 tasks you ask "which is highest priority" and the answer is "they are all the highest priority": that tells you none of them are the highest priority so you just "pick one" and start working on it.
Unless something has changed radically (which is possible), that's wrong. Making them all interactive doesn't mean that they all have the same priority, it means that the choice of which task runs next is based only on priority. This is similar to how the 4BSD scheduler works, and some people have claimed to get better interactive desktop performance from this.

The downside to only using priority is that the lower priority tasks can get starved of cpu time (just like idle priority tasks can); so to counter this ULE handles batch level tasks in a way that takes account of priority, but allows low priority tasks to go ahead of higher priority task eventually. In a heavily loaded system it's then possible for a desktop GUI process that just dips into the batch region to get stuck behind resource hog processes - even if they are "niced" resource hogs.
 
Unless something has changed radically (which is possible), that's wrong. Making them all interactive doesn't mean that they all have the same priority, it means that the choice of which task runs next is based only on priority. This is similar to how the 4BSD scheduler works, and some people have claimed to get better interactive desktop performance from this.
Perhaps I didn't say it clearly enough.
Setting the sysctl to 0 or 100 is removing the "extra" from the calculation. Not "making them all interactive".

Schedule priority is "X + interactive score"
if you set "interactive score" to min (0) or max(100) you are removing/limiting the effect of the interactive score.
That is what Eric A. Borisch is saying up in post #20.
 
This actually makes a massive difference if you are recording audio with jack
it really helps with xruns

Code:
kern.sched.ule.preempt_thresh=224

I have Carla (audio host for plugins) set up with the deepfilter-net ladspa plugin
and LSP plugins with a noise gate, parametric eq, multiband compressor, compressor and a limiter

Then using qjackctl i pipe the audio into obs studio using a jack input source
which give me much better audio for my mic than using the obs studio plugins

I previously did the same thing with Ardour
but Ardour is broken at the moment and you have to patch it which takes about 11 hours to build with Poudriere

And when i updated to the latest quarterly branch Ardour broke again

So i installed Carla

Note if you just search for Carla nothing shows up

Code:
pkg search carla

But if you search for audio/carla it does show up

Code:
[i] pkg search audio/carla
audio/carla                    Audio plugin host for Jack and PulseAudio

Carla install

Code:
doas pkg install audio/carla
 
Note if you just search for Carla nothing shows up

pkg search carla
Well, if you say you searched for Carla but actually typed in carla, then no results is currently the correct response as pkg-search(8) and companions (I'm expecting all) are by default case sensitive, for quite some time actually.
However, the documentation is lagging behind: PR 294639 and comment on commit. So the document changes have been committed to pkg - development but have not been included in pkg-2.7.5. It is allready included in ports-mgmt/pkg-devel version 2.7.99.3.
 
Carla was just capitalized as the name of the application

Note if you just search for Carla nothing shows up

but not in the search

Code:
pkg search carla

i was just making the point you have to search like this

Code:
pkg search audio/carla

maybe i wasnt clear about that
 
Carla was just capitalized as the name of the application



but not in the search

Code:
pkg search carla

i was just making the point you have to search like this

Code:
pkg search audio/carla

maybe i wasnt clear about that
But I just did:
Code:
 pkg search Carla
Carla-2.6.0.a1.g20260319       Audio plugin host for Jack and PulseAudio

which I think is what Erichans was pointing out.
 
My bad

i always search using lowercase

Code:
[i] Yes Master ? pkg search carla
[djwilcox@pollux ~/desktop]

[djwilcox@pollux ~/desktop]
[i] Yes Master ? pkg search audio/carla
audio/carla                    Audio plugin host for Jack and PulseAudio

[i] Yes Master ? pkg search Carla
Carla-2.6.0.a1.g20260319       Audio plugin host for Jack and PulseAudio
 
My bad

i always search using lowercase

Code:
[i] Yes Master ? pkg search carla
[djwilcox@pollux ~/desktop]

[djwilcox@pollux ~/desktop]
[i] Yes Master ? pkg search audio/carla
audio/carla                    Audio plugin host for Jack and PulseAudio

[i] Yes Master ? pkg search Carla
Carla-2.6.0.a1.g20260319       Audio plugin host for Jack and PulseAudio
And that usually works, but sometimes doesn't :)
 
The paper on sched_ule: https://www.usenix.org/legacy/event/bsdcon03/tech/full_papers/roberson/roberson.pdf

Worth reading before turning knobs.

See also sysctl -d kern.sched.ule, and, of course, the source.
in one of the threads here there is a link to a presentation on ULE
Thread: What is sysctl kern.sched.preempt_thresh; one of my link overviews
Note that the original 2003 Roberson article, the FreeBSD journal article (2014) & the video presentation of Kirk McKusick (2020) are mostly about the ULE scheduler as it was when it was introduced as the default scheduler. Things have changed. Currently the ULE scheduler has, for example, no more calendar queue to guarantee fairness; this has been implemented in another way. There is now only one run queue per CPU. The state of the available schedulers and ULE as of 15.1:
 
Interesting. That implies you can detect the difference between a 2ms and a 10ms delay on say hitting a key and having it appear. Don't take that the wrong way; it's an analogy with speech and telephony. Look at everything related to voice on the POTS network and you wind up with 8KHz bandwidth with sampling at a rate lower than you would think.

Or audiophiles stating that vacuum tube amps and analog inputs are light years ahead of any digital system. I truly believe some people can tell the difference, most can't but the actual input makes a difference in what can be heard. I'm saying that as someone that can't carry a tune if you put it in a bucket.

I do a lot of work with A/V and "legacy" systems.

In my experience the vast majority of people can detect the difference between say 4ms response to input given vs. 10+ms provided they are using a display device and input device that can actually meet these thresholds.

The latency built into most input/video devices the vast majority of people interact with everyday has massively increased since about the middle 2000s-2010s. Basically, when the switch from wire input devices to wireless devices and the switch from CRTs to "modern" displays like LCDs occurred. These were sold as upgrades to the general public and maybe in some ways they were. But when it came to many applications they were massive down grades for "enthusiasts" on both the production and consumption sides of interacting with content.

Now we're into a situation where it's about 15-20 years later and we have large numbers of so-called tech savy people that have never interacted with "legacy" devices and applications built for them. I'll skip a lot of technical stuff on the production side of this equation here in an attempt to avoid derailing this thread too much. Instead, I'll give you a common example most people are probably familiar with: gaming. In particular, two genres where this built-in delay chain is most noticeable. FPS and Fighting games.

Let's go with 2D/pseudo-2D fighting games because it's an easier engine for someone not familiar with how games are programmed to wrap their heads around.

The old arcade boards Neo-Geo and Capcom games were built around were designed to draw near-instantly (for our purposes it might as well be instant) to the monitor. Which was a CRT. They ran at a true 60fps. Which was locked because it was easier to build game logic around a known frame rate. Similarly, all input was instantly processed because it wasn't going through some wireless/"universal wired" protocol but instead the input device (joystick+buttons) were wired directly to the purpose built computer inside of the cabinet. There wasn't even an OS/kernel in those days. Games were programmed in asm and everything was generally optimized as much as possible due to resource limitations of that era's processors and memory limitations.

So I press a button, the game logic says it takes 4 total frames for the action that button causes to appear on screen. The software draws the first frame of that action's animation to screen 4 frames later. Since the game must seem fair to both players my opponent can actually react to this action even with only visual ques (the frame being drawn) by holding back on his joystick. Which was the common input for block. Which came out "instantly" (1-2 frames) on most games in that era.

If the 4 frame action I did is a "jab" (fastest offensive move) this would mean all offensive actions can be reacted to (at least blocked). Of course most of these games had stronger offensive actions like say a "high punch" which would cause more damage when they connected but had more start-up time/frames (let's say 15 frames or 1/4th of a second). I can tell you having spent a lot of time in the arcade growing up that it was very common for even semi-novice players to react to a "slow" 15-frame start-up move with something like a 4-frame jab. In fact, it was so common that strategies were quickly developed even in the pre-mainstream internet days from people in the local arcade sharing what they call "tech" these days between each other. Well word of mouth and magazines (and BBSs of course) but I'm sure you get my point.

On modern display devices and with modern input devices (even custom built) it's impossible to design a fighting game like this. Instead, all modern games have some form of built-in delay added. Add in the modern need for netplay and that is also used as justification for adding this delay as well. As a result, we've ended up with games like modern Street Fighter. Where jabs are now very "slow" compared to the SF games of yore. With every move having a 5+ frame delay (it's usually more) added on top of whatever the input actions own delay is listed as (so if a jab is 5 frames on its own add +5-6 more frames for the inherent delay from the system itself). Then on top of this add whatever delay is coming from both your input device and display device. Even high refresh rate 144+hz modern high-end monitors advertised to have low delay can never come anywhere close to what a bog standard CRT could do (display sprites "instantly" (the beam had to draw the lines first of course)).

This has led to the decline in games where fast reaction times used to be the entire point.

Consider the most popular FPS games from the mid-late 90s compared to the most popular FPS games today or even 15 years ago once HDTVs were seen as the new default. Like compare Q3A or CS being played on a CRT to something like Call of Duty (or basically any other FPS released since Halo). You'll see the same thing happening to them that has happened to fighting games. Game play is nowhere near as fast, many "easy mode" (some would say cheating) mechanics like bullet curving if your point of aim was close to a model were added, delay in input being processed globally (bullets/actions come out slower, slow animations) and "come back mechanics" were added. I could go on but you get the idea.

I've seen many modern "pros" on the gaming/arcade circuit play worse than new-average players of old fighting/FPS games when they've attempted to play them against average-expert players of those games on period correct hardware. They all say the same thing: everything is happening to fast.

You'd think a 15 year old could easily beat up a 50+ year old on a fighting game with mostly the same mechanics as the modern version. Even with lots of practice these young guys typically can't adapt. You boot up the game on an emulator on a modern display device and use modern input devices and they do a little better. You let them play a new player and they might take some wins. But the moment they face an average-expert player (some of which haven't touched the game in decades) they quickly start having trouble. Once the old guy plays a couple of rounds and gets back into the groove of things muscle memory quickly takes over and they start whooping up on the young guys.

The young people are at a disadvantage because they didn't spend years using CRTs and input devices from that era. So they simply aren't used to having to react within 2-5ms of things being drawn on screen. Where people that grew up with using that stuff everyday just seem to have a knack for it. I've had more than a few of those old guys tell me they were surprised they did as well as they did in a real match. Since many gave up video games years ago because in their words "New games aren't fun, they're too easy and slow".

This isn't some isolated thing either. It's not as doable now but in the CRT -> HDTV transition era when a lot of compeitive FPS and fighting game tournaments were happening on the Xbox 360 console there were tons of teams comprised of "old farts" (25+ years old) who were winning tournaments left and right because they had a secret strategy. Which consisted of playing on regular old CRT TVs and using wired input devices.

A lot of games supported this but one that comes to mind is L4D1. On Xbox 360 if you played Left 4 Dead 1 using the composite output on the console it would output 480i@60fps. All the HD outputs (even 720p IIRC) could only manage 30-40fps or somewhere around there. This gave the people playing on CRTs a huge advantage despite their view of the map being smaller horizontially. They could react to things faster and spin their POV around faster even using standard input devices (the wireless controller). Of course, many of them used keyboard+mouse through a wired adapter on top teams and you could modify the values of your save file if it was stored on a usb thumb drive to push the sensitivity settings beyond what was possible through the games GUI. Which led to a lot of cheating accusasions.

But even without the save file modification and with a standard input device the difference was night and day if you played on a CRT using the composite video output instead of an HDMI cable or componnent output. The people on HDTVs were not only playing at nearly half the frame rate they were also having to deal with the LCD display device's inherant display lag.

I could go on and on about this and we haven't even gotten into audio. Which is a whole other can of worms. For that I'll just say: Yes, for many applications latency does matter and it matters a lot.

I'll just leave it at it isn't a placebo effect and in general the quality of hardware for A/V stuff has gone down the shitter since about the year 2000. A lot of the old analog stuff doesn't just sound/look better because analog is better (in some ways it is). Most of it comes down to the "digital" things we've been sold as high-tech improvements were built as cheaply as possible and in a lot of ways the technology wasn't better than what it was replacing. At least not quality wise. TVs for example were mostly switched over to modern flat screens because they were not only cheaper to produce. They were much cheaper to ship.

All that said: Yes it's easy to get rich selling snake oil to audiophiles. But just because those people exist doesn't mean everything they say is wrong. Typically, those types are just repeating something they heard from someone that heard it from someone else. But if you actually go digging you'll see there is usually some facts buried under all of the BS.

There are also many good examples of modern (well semi-modern) games working around the limitations of modern display/input devices and delivering an expereince very close to what we used to get on CRTs. Sadly, these games are few and far between and becoming rarer with each passing year. Which is how you end up with formerly great things like Street Fighter and Guilty Gear turning into what they have now. Thankfully, the older versions still have a large following and there are enough of us around keeping old hardware alive and properly emulating them and adding features like netplay to old games to ensure those will be around for many years to come. The player counts on such games keep increasing each year to. Since like me many have grown tired of seeing their beloved past times being sold out for profit and thankfully a lot of people have smartened up and stopped giving money to the companies whoring out their old IPs for cash. Sadly, we're vastly outnumbered by legions of idiots that will defend anything, hand over $500+ dollars for a game that would have cost $50 just 15 years ago (with all the "DLC" included) and only want to press X to win. But I digress.

I would argue that reaction times have actually decreased across the board in the human population over the past 1-2 generations since many are no longer exposed to situations that train reaction time. People do not go outside and participate in activities (mostly sport) that require fast reaction times on average anymore. The display and input devices they interact with daily now have 10x times the lag devices had between the 1950s-early 2000s. They've grown used to the inherant lag of such devices. Hence why you don't hear many complaining about the new TV and game console they bought taking sometimes 10+ms to respond to input or notice that a lot of those modern games are sending inputs to some server and back even during "local" play. But put them on an old puzzle/fighting/FPS games on a CRT and they'll all complain about how "fast" and "unfair" it is.

There are good reasons why CRTs and Amigas are still sitting on my desk and are part of my daily work flow in the 2020s. There is simply no way to replace them or to properly deal with content produced in that era with modern display devices and hardware.

Even a lot of the complaints about the "crappy quality" of mpeg2 video and analog video sources are just from people attempting to view them on modern display devices. Since CRTs by their nature "hid" a lot of stuff that looks like "artifacts"/"bad mastering" on "modern" display devices.

I've also found that most young people that claim to love this old hardware aren't really into it for anything but the "asthetic" of them and know very little about how they actually work. So you'll see them parroting as many myths about things like CRT monitors as the audiophiles love to parrot about stuff like the "warmth" of analog. Again: They aren't totally wrong. They just don't really understand the fact they're attempting to use to justify paying hundreds of dollars for something you could have dug out of the local dumpster for free just a decade ago.
 
Back
Top