× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I could be wrong on the value to use now-a-days...it's also been years
since I worked the admin side.

But as I understand it, the issue with the default is that basically most
jobs would never hit it given the speed of modern processors.
Most jobs give up the timeslice due to an I/O wait.

But if you get a job that actually hits it, you've got a job holding the
CPU for what amounts to an eternity now-a-days.
You don't really want that.

On a lightly loaded system, it probably doesn't matter. On a busy system,
that's a bad thing.

Charles

On Thu, Dec 16, 2021 at 10:47 AM Roger Harman <roger.harman@xxxxxxxxxxx>
wrote:

Admittedly, I haven't dealt with work management in YEARS.

But, wouldn't a tiny timeslice like that lend itself to inducing thrashing
with all the potential swaps?

Not criticizing, just curious.



-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Charles Wilt
Sent: Thursday, December 16, 2021 8:30 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: RUNPTY and TIMESLICE in *CLS objects

Time slice on the IBM i really only comes into play in a CPU intensive
workload...

If your job is waiting for screen or disk I/O, the system will trade it out
for something that is ready to use the CPU now.

Having said that, last I heard the default timeslice assigned to IBM
defined classes (ex: 2000 interactive / 5000 batch) haven't changed since
the first AS-400 was shipped.

CPU's where much slower then. :)

A much more modern CPU appropriate timeslice is 200 / 500 I believe.

Charles


On Thu, Dec 16, 2021 at 9:22 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:

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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FNice_&amp;data=04%7C01%7C%7C7b7b3431e1c8482a5a2e08d9c0b15450%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752690116928789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=bgJZAvLP5Wr8fpsN5BKuWcdi%2BG0DmWeZjJZkn3GCGJc%3D&amp;reserved=0(Unix)
-, I struggle to understand the
real world impact of different time slice values.


https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FPreemption_&amp;data=04%7C01%7C%7C7b7b3431e1c8482a5a2e08d9c0b15450%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752690116928789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TKaKEGwcFdnR7l7lwEFOUmLXEFJ4oDyak19dsd3tbto%3D&amp;reserved=0(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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F16401294%2Fhow-to-know-linux-scheduler-time-slice&amp;data=04%7C01%7C%7C7b7b3431e1c8482a5a2e08d9c0b15450%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752690116928789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=wDwLJPgEKhbRzXK3HdURhBN3E6WchBSiHGqEJCwHkLQ%3D&amp;reserved=0

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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fmidrange-l&amp;data=04%7C01%7C%7C7b7b3431e1c8482a5a2e08d9c0b15450%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752690116928789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=jJhGTVyrEJWAWQ6XXI3INw6qn3ulcPESWMHi6Y35gak%3D&amp;reserved=0
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fmidrange-l&amp;data=04%7C01%7C%7C7b7b3431e1c8482a5a2e08d9c0b15450%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752690116928789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ZIYXowcGzim0woOtEbbNrBBddapRurV9r7yrd5bXDww%3D&amp;reserved=0
.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Famazon.midrange.com%2F&amp;data=04%7C01%7C%7C7b7b3431e1c8482a5a2e08d9c0b15450%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752690116928789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=MSd1iIJJ5SzjhEgkQEk%2FZoPsxjIvt3t2ZHq2%2Fiu1zqQ%3D&amp;reserved=0

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fmidrange-l&amp;data=04%7C01%7C%7C7b7b3431e1c8482a5a2e08d9c0b15450%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752690116928789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=jJhGTVyrEJWAWQ6XXI3INw6qn3ulcPESWMHi6Y35gak%3D&amp;reserved=0
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fmidrange-l&amp;data=04%7C01%7C%7C7b7b3431e1c8482a5a2e08d9c0b15450%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752690116928789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ZIYXowcGzim0woOtEbbNrBBddapRurV9r7yrd5bXDww%3D&amp;reserved=0
.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Famazon.midrange.com%2F&amp;data=04%7C01%7C%7C7b7b3431e1c8482a5a2e08d9c0b15450%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637752690116928789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=MSd1iIJJ5SzjhEgkQEk%2FZoPsxjIvt3t2ZHq2%2Fiu1zqQ%3D&amp;reserved=0
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.