RUNPTY and TIMESLICE in *CLS objects

Hello,

I've read again and again through the Work Management manual but I can't make sense with my Linux background about those attributes.

While RUNPTY might be closely related to the "niceness" — see https://en.wikipedia.org/wiki/Nice_(Unix) —, I struggle to understand the real world impact of different time slice values.

https://en.wikipedia.org/wiki/Preemption_(computing)#Time_slice says:

The period of time for which a process is allowed to run in a preemptive multitasking system is generally called the time slice or quantum. The scheduler is run once every time slice to choose the next process to run. The length of each time slice can be critical to balancing system performance vs process responsiveness — if the time slice is too short then the scheduler will consume too much processing time, but if the time slice is too long, processes will take longer to respond to input.

Is this definition true for IBM i also?

Time slices on Linux are much much smaller than the default 2 or 5 seconds. See https://stackoverflow.com/questions/16401294/how-to-know-linux-scheduler-time-slice

In general, it's said, larger time slices for batch jobs allow more work to be done in a given time frame. But won't that affect interactive jobs waiting to be scheduled to run? I never had the impression I needed to wait 5 seconds until a background compiler run allowed me to page down a subfile in an interactive 5250 screen. Not even remotely, not even on my slow 150.

I'd be grateful for some enlightenment.

(Background of my question: Imagine a compiler runs in batch, and consumes CPU, and there is a concurrent need to measure the time between two events coming in from the network in another, unrelated process, and somehow save the result. For that I want that time measuring program to be as small as possible, as efficient as possible, and running with the highest possible priority for user applications, which means RUNPTY=0. This should make sure that timing is measured with sufficient accuracy, and the system itself isn't just serving the counting program, because it's small, efficient and thus quickly done with its job after each packet. But what about a meaningful TIMESLICE value for that program?)

:wq! PoC