timeslice and user time

[Prashanth C]

Hi all,
We are using HP-UX 10.20. We were trying certain changes in timeslice value. On changing it to a lower value like 50 or 20, we observe that the CPU utilisation of a process goes up.
Question is
1) In Threaded processes, why do both utime and stime increase compared to a timeslice of 100?
2) How are utime and stime of non-threaded processes affected?

Thanks,
Prashanth

[Pete Randall]

Prashanth,

Everything I've ever read about timeslice says "leave it alone":

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xbf8393e260b0d611abdb0090277a778c,00.html

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x5862c1c4ceddd61190050090279cd0f9,00.html


Pete

[James R. Ferguson]

Hi:

The default value for 'timeslice' is 10. 'timeslice' controls the amount of time a process will execute before a context switch to a process of equal priority occurs. If the value is too small, more time will be spent context switching than doing user work and system time will be proportionally larger than user time. Setting 'timeslice' to a very large value will result in higher-priority processess "hogging" time while lower-priority ones are "starved".

Regards!

...JRF...

[Prashanth C]

Hi,
Some more information. In our system, the threads of the different processes seem to require very little amount of CPU in the order of less than 10 msec. In order to increase response time, we were exploring the option of reducing the timeslice.
On reducing timeslice, we find that both utime and stime of threaded and non-threaded processes increase.
We do understand that the stime increase can be due to more context switches. Is there any other reason why stime can increase?
Why would utime of a threaded/non-threaded process be affected by the change?
Thanks,
Prashanth

[Bill Hassell]

If you reduce the timeslice value to 5, then equal priority processes (and threads) will be allowed only 5ms of runtime before the opsystem has to stop the process, find another process to run, setup all the registers and perform a context switch. There's a fair amount of overhead in doing this so the percentage of user time per timeslice will go down (the kernel will consume more time). If you increase the timeslice value, processes and threads will run for a longer period of time (assuming no I/O occurs during the timeslice) so user time will accumulate at a higher rate as the process doesn't get interrupted by context switches.

As many sysadmins have found out, response time is very seldom fixed by changing timeslice. response time is best fixed by improving the underlying application code. If the code is a web page, change the order of processing so that something is immediately sent to the browser before processing any internal data. Perhaps set the background and common images and graphics. This makes the page seem responsive and gives the end-user soemthing to look at while the internal code is running.

[John Bolene]

time slice is the maximum cpu time of continuous cpu processing that you can get without letting the cpu go

instead of changing time slice, look at optimizing the other long running processes

changing the time slice to make short transactions run faster is the wrong approach, optimize code instead