Mailing List Archive

> I've just noticed a bug with having my scheduler set to 1000Hz (by editing
> /usr/src/linux/include/asm/param.h, of course). Although scheduling does,
> in fact, seem smoother, ps returns that a process has been running longer
> than it really has; in fact, it's by exactly a factor of 10, go figure.
> Just to prove this, I ran the following simple script (PID 1097 is,
> obviously, rc5des):
That is elementary. The running time counts are in JIFFIES,
which are in the HZ units. The 'ps' has 'HZ' compiled in
when it was made. In fact the system does not tell the internal
HZ value out in any easy to use way. So sad.
$ cat /proc/interrupts |grep timer;sleep 1;cat /proc/interrupts |grep timer
8: 75924461 timer
8: 75925508 timer
The delta is 1047 interrupts; HZ at the machine is 1024...
/Matti Aarnio <matti.aarnio@sonera.fi>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Fri, 22 Jan 1999, Matti Aarnio wrote:
> > I've just noticed a bug with having my scheduler set to 1000Hz (by editing
> > /usr/src/linux/include/asm/param.h, of course). Although scheduling does,
> > in fact, seem smoother, ps returns that a process has been running longer
> > than it really has; in fact, it's by exactly a factor of 10, go figure.
> > Just to prove this, I ran the following simple script (PID 1097 is,
> > obviously, rc5des):
>
> That is elementary. The running time counts are in JIFFIES,
> which are in the HZ units. The 'ps' has 'HZ' compiled in
> when it was made. In fact the system does not tell the internal
> HZ value out in any easy to use way. So sad.
Ah, I see... is there any way for the ps/top/etc. utilities to get at the
HZ rate so this behaviour can be fixed?
> $ cat /proc/interrupts |grep timer;sleep 1;cat /proc/interrupts |grep timer
> 8: 75924461 timer
> 8: 75925508 timer
>
> The delta is 1047 interrupts; HZ at the machine is 1024...
Yeah, this makes sense, definitely. I suppose a ps binary could try to
work out the jiffy rate from that, but it'd be inaccurate at best (mine at
1000 returns 1013 interrupts).
I guess I can just deal with it and remember to divide by 10.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On 21-Jan-99 Quantum Porcupine wrote:
> (I'm not subscribed to the list, as my quota can't handle the load. :)
> Please reply to me as well as to the list, if possible.)
>
> I've just noticed a bug with having my scheduler set to 1000Hz (by editing
> /usr/src/linux/include/asm/param.h, of course). Although scheduling does,
> in fact, seem smoother, ps returns that a process has been running longer
> than it really has; in fact, it's by exactly a factor of 10, go figure.
> Just to prove this, I ran the following simple script (PID 1097 is,
> obviously, rc5des):
You need the latest version of the ps-utils. The URL was posted a week or two
ago.
-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Fri, 22 Jan 1999, David B. Rees wrote:
> On 21-Jan-99 Quantum Porcupine wrote:
> > (I'm not subscribed to the list, as my quota can't handle the load. :)
> > Please reply to me as well as to the list, if possible.)
> >
> > I've just noticed a bug with having my scheduler set to 1000Hz (by editing
> > /usr/src/linux/include/asm/param.h, of course). Although scheduling does,
> > in fact, seem smoother, ps returns that a process has been running longer
> > than it really has; in fact, it's by exactly a factor of 10, go figure.
> > Just to prove this, I ran the following simple script (PID 1097 is,
> > obviously, rc5des):
>
> You need the latest version of the ps-utils. The URL was posted a week or two
> ago.
Ah, okay, I must not have seen that post; since i figured it was a
scheduler bug, I only searched on "scheduler" on the various archive
index pages. Now I know what to search for. Thanks. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Quantum Porcupine writes:
> (I'm not subscribed to the list, as my quota can't handle the load. :)
> Please reply to me as well as to the list, if possible.)
Get the list on the web or find a news gateway.
> I've just noticed a bug with having my scheduler set to 1000Hz (by editing
> /usr/src/linux/include/asm/param.h, of course). Although scheduling does,
> in fact, seem smoother, ps returns that a process has been running longer
> than it really has; in fact, it's by exactly a factor of 10, go figure.
Upgrade ps to support 1000 HZ.
http://www.cs.uml.edu/~acahalan/linux/procps-990103.tar.gz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Quantum Porcupine <joshagam@cs.nmsu.edu> replied thus:
> On Fri, 22 Jan 1999, Matti Aarnio wrote:
...
> > That is elementary. The running time counts are in JIFFIES,
> > which are in the HZ units. The 'ps' has 'HZ' compiled in
> > when it was made. In fact the system does not tell the internal
> > HZ value out in any easy to use way. So sad.
>
> Ah, I see... is there any way for the ps/top/etc. utilities to get at the
> HZ rate so this behaviour can be fixed?
POSIX way would be to have sysconf() call to extract this information.
Linus' earlier comments (mid December?) ignoring, I do think Linux would
benefit from the sysconf() / pathconf() / fpathconf() trio.
Apparently *only* SPARC systems have it. (For SunOS compability.)
It is somewhat difficult to modifying presentation machinery of some
values in e.g. /proc/123/stat "file" to scale them so that they always
present their value as if the HZ would be the ``classical constant''
for given platform. For example, where would the ``classical constant''
be taken from, if the only instance of ``HZ'' is modified ?
In this case the deprecated sysconf(_SC_CLK_TCK) would be THE answer
to solve the problems that ps/top/et.al. have.
/Matti Aarnio <matti.aarnio@sonera.fi>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

MOLNAR Ingo <mingo@chiara.csoma.elte.hu> wrote thus:
(speaking of 'jiffies' scaled values in /proc/ and elsewere..)
> 'Hz' has a physical definition. The Linux HZ constant just says how many
> timer interrupts per second should occur. The requirement is to never let
> this (arbitrary) constant show up, but to have all API components use the
> 'real-world' definition of time.
That would be ideal, but what will you do, when your
applications using current interface need then be
changed. A flag-day ?
> > In this case the deprecated sysconf(_SC_CLK_TCK) would be THE answer
> > to solve the problems that ps/top/et.al. have.
>
> not at all. The problem is that /proc/<pid>/stat (and other kernel
> interfaces) export values that are dependent on the kernel-internal HZ
> definition. They should export 'natural' units like nanoseconds or
> microseconds, this solves the problem once for all, makes binary data
> files exchangable between different-HZ Linux boxes, etc.
Remember, we have binary interfaces, and "ASCII" ones.
For *binary* interfaces usage of structures with nanoseconds
and seconds would be best (assuming at least 32 bits for
both fields), for ASCII ones I would present times as:
12345.98765
placing the "decimal point" to mark how the time is in
seconds, and decimal franctions of it.
Presenting the fractions would be challening, though.
In order of not to loose accuracy in jiffies fraction,
you will want to present the printout with enough digits,
but how you determine the needed scalers ?
#if HZ <= 1000 /* 50, 60, 1000, whatever */
# define HZ_SCALER 1000
# define HZ_SCALER_DIGITS "3"
#elsif HZ <= 10000 /* 1024, etc */
# define HZ_SCALER 10000
# define HZ_SCALER_DIGITS "4"
#elsif HZ <= 100000 /* tock, tock, are you mad ? */
# define HZ_SCALER 100000
# define HZ_SCALER_DIGITS "5"
#else /* HZ > 100 000 ---> you are mad! */
# warning "HZ_SCALER may be too low, but your HZ is way too high!"
# define HZ_SCALER 1000000
# define HZ_SCALER_DIGITS "6"
#endif
sprintf(buf, "%d.%0"HZ_SCALER_DIGITS"d", jiffies / HZ,
((jiffies % HZ)*HZ_SCALER+HZ/2)/HZ);
with back-converting that value to HZ base my test
program (integer math all the way) kept all the time
the difference in between the original "jiffies", and
the back-coverted value in round zero.
Same algorithm can be used to translate 'jiffies'
things to 'nanoseconds', but beware 32-bit overflow
dangers... Perhaps for that reason doing it in
'microseconds' would be sensible (up to HZ=2147,
maybe even up to HZ=4294)
Looking at those expressions above I see well, why
DEC UNIX, and thus Linux/Alpha uses HZ value of
1024, and *not* 1000 ! In fact when changeing to
the scaled interfaces, I would suggest refraining
from using any other HZ values than powers of two:
16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192.
> -- mingo
/Matti Aarnio <matti.aarnio@sonera.fi>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

> $ cat /proc/interrupts |grep timer;sleep 1;cat /proc/interrupts |grep timer
> 8: 75924461 timer
> 8: 75925508 timer
>
> The delta is 1047 interrupts; HZ at the machine is 1024...
you'll get a bit closer to HZ with less execing:
grep timer /proc/interrupts ;sleep 1; grep timer /proc/interrupts
-d
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Matti Aarnio writes:
> Quantum Porcupine <joshagam@cs.nmsu.edu> replied thus:
>> On Fri, 22 Jan 1999, Matti Aarnio wrote:
>>> That is elementary. The running time counts are in JIFFIES,
>>> which are in the HZ units. The 'ps' has 'HZ' compiled in
>>> when it was made. In fact the system does not tell the internal
>>> HZ value out in any easy to use way. So sad.
>>
>> Ah, I see... is there any way for the ps/top/etc. utilities to
>> get at the HZ rate so this behaviour can be fixed?
Yes, it is very hard to keep such a secret.
> It is somewhat difficult to modifying presentation machinery of some
> values in e.g. /proc/123/stat "file" to scale them so that they always
> present their value as if the HZ would be the ``classical constant''
> for given platform. For example, where would the ``classical constant''
> be taken from, if the only instance of ``HZ'' is modified ?
It is almost silly to think that all HZ-based values could be fixed.
It is better to leave them as they are.
> In this case the deprecated sysconf(_SC_CLK_TCK) would be THE answer
> to solve the problems that ps/top/et.al. have.
Long term, I suppose it is. I'm not interested in that now though,
because Linux 2.0 and 2.2 won't support it. The library also has
a totally bogus version, so I'd need to use assembly in procps.
For those that missed it, this problem has been fixed:
http://www.cs.uml.edu/~acahalan/linux/procps-990103.tar.gz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

In article <Pine.LNX.3.96.990122165340.10290A-100000@chiara.csoma.elte.hu>,
mingo@chiara.csoma.elte.hu (MOLNAR Ingo) writes:
> On Fri, 22 Jan 1999, Matti Aarnio wrote:
>> It is somewhat difficult to modifying presentation machinery of some
>> values in e.g. /proc/123/stat "file" to scale them so that they always
>> present their value as if the HZ would be the ``classical constant''
>> for given platform. For example, where would the ``classical constant''
>> be taken from, if the only instance of ``HZ'' is modified ?
> 'Hz' has a physical definition. The Linux HZ constant just says how many
> timer interrupts per second should occur. The requirement is to never let
> this (arbitrary) constant show up, but to have all API components use the
> 'real-world' definition of time.
This requirement is broken in several places currently, mainly in sysctls.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/