1833432 Members
3067 Online
110052 Solutions
New Discussion

Re: timeslice

 
SOLVED
Go to solution
Darren Murray_1
Frequent Advisor

timeslice


Hi,

I have tuned my kernel parameter timeslice to be 10.

I have had a software vendor come in and do a review of the system and they have recommended that it should be to 20.

Now Ive always tuned the parameter from 1 to 10 and thought I should leave it at that.

The server is a N-Class with 4 x 440Mhz.
8 REPLIES 8
Michael Tully
Honored Contributor

Re: timeslice

Hi Darren,

Setting the timslice value to 20 should not pose a problem. Just remember setting this too low (-1) or a higher value, may cause the process to continue running without checking for signals. Have a look at the information from the kernel parameter page below.

HTH
Michael
==============================================
timeslice
timeslice defines the scheduling-timeslice interval.

Acceptable Values:
Minimum
-1
Maximum
2147483647 (approximately 8 months)
Default
10 (ten 10-msec ticks)
Specify integer value or use integer formula expression. For more information, see Specifying Parameter Values.

Description
The timeslice interval is the amount of time one process is allowed to run before the CPU is given to the next process at the same priority. The value of timeslice is specified in units of (10 millisecond) clock ticks. There are two special values:

0
Use the system default value (currently ten 10-msec ticks, or 100 milliseconds).

-1
Disable round-robin scheduling completely.

Impact on System
timeslice imposes a time limit which, when it expires, forces a process to check for pending signals. This guarantees that any processes that do not make system calls can be terminated (such as a runaway process in an infinite loop). Setting timeslice to a very large value, or to minus 1, allows such processes to continue operating without checking for signals, thus causing system performance bottlenecks or system lock-up.

Use the default value for timeslice unless a different value is required by system applications having specific real-time needs.

No memory allocation relates to this parameter. Some CPU time is spent at each timeslice interval, but this time has not been precisely measured.

Related Parameters
None.

Additional Information
Overview of process parameters
List of process parameters
Browse configurable kernel parameters help
Anyone for a Mutiny ?
T G Manikandan
Honored Contributor

Re: timeslice

This parameter is used to prevent the processes monopolizing the CPU and thus allowing processes to be executed on a specific time frame.

Tuning to 20 should not cause any problems.Tuning the parameter to higher values can result in problems.

However,HP does not recommend to tune the parameter from its default values.


Thanks

Sridhar Bhaskarla
Honored Contributor

Re: timeslice

Darren,

HP does not recommend to deviate from the default value of 10.

However, you may run into political issues if the recommendation is from the vendor.

So, the best bet is to make it 20 and run load tests and see how the system responds. Put it back to 10 and compare the results with that of 20. If you see no difference, then convey it to the vendor and keep the running kernel. If you see the difference you know what to do.

-Sri
You may be disappointed if you fail, but you are doomed if you don't try
Wodisch
Honored Contributor
Solution

Re: timeslice

Hi,

your "batch" processes will love it, but your intercative processes may starve!
Only change "timeslice" in very small increments/decrements (like 1 or 2!), then check for your results - and don't change aynthing else at the same time as that would certainly spoil your measurement!

FWIW,
Wodisch
PS:In three words: try "12" first!
Darren Murray_1
Frequent Advisor

Re: timeslice

Another query....the server runs a oracle database and runs a java application.

Does this mean that all heavy batch jobs will suck up CPU and the guys who are just keying data and doing small update will be affected?

Im going to adjust to 12 and suck and see.

What would be a good measure to see any improvement? less context switching?

thanks for your help
A. Clay Stephenson
Acclaimed Contributor

Re: timeslice

Less context switching might be a good thing (and it might not). You have to balance batch jobs getting bigger chunks of time with users perceiving the system as "sluggish". If this machine is largely a dedicated application and/or database server with almost all users connected as application clients then you can get away with larger timeslice settings. I have on rare occasions gone up to 100 but 10 is a good all aroiund value and you are not going to see much improvement with values over 10 - on the other hand going much below 10 can very quickly lead to problems. Stephen Cuillo has the best definition of timeslice that I have ever heard: "It's the maximum number of ticks that you ain't gonna get". Think about that a little and it makes sense.
If it ain't broke, I can fix that.
Sridhar Bhaskarla
Honored Contributor

Re: timeslice

Hi Darren,

I am assuming that the software vendor is the one who supplied you with the software/application.

If your vendor recommended a setting, then there could be a reason because he knows how his software works. Probably the work it does may need 20 ticks.

Use "it depends" concept. Probably his software may benefit from minimum context switching. Do testing with a variety of settings and go with your findings.

-Sri
You may be disappointed if you fail, but you are doomed if you don't try
Jeff Schussele
Honored Contributor

Re: timeslice

Hey Clay,

Hate to quibble here & no disrespect to Stephen intended, but it seems to me that because it's the max ticks value that any equal priority process can get AND because there's no guarantee your process is next in the priority queue, wouldn't it make more sense to say:

"It's the *minimum* number of ticks you ain't gonna get."

Maximum would be good IF there were only 2 processes - both with the same priority & they both wanted to remain processing beyond 10 ticks....
And for that matter 10 as a minimum may not be accurate either IF the preceeding process(es) only needed 1 or 2 ticks.....

Hmmmmm......intriguing to say the least, and I do like the analogy........

My $0.02,
Jeff

PERSEVERANCE -- Remember, whatever does not kill you only makes you stronger!