Re: Questions about cdrtools-2.01a33
> > What HZ value out of {100,1000} is preferable (if one is not willing
> > to put in question the operating system itself) ?
>
> Well, picking wrong value will have undesired side effect, most notably
> commands timing out earlier than they should have or "never" timing out.
Up to now, it works fine ... i believe.
> The right value varies from platform to platform, and I mean from Linux
> on one hardware platform to Linux on another hardware platfrom. Meaning
> that if you choose value of 100, which is suitable for i[3456]86 and
> hard-code it, you ought to keep compiling your application on i[3456]86
> for all eternity.
Hey ! I may have confessed to be stupid. But i'm not *that* stupid :-)
The question about HZ was because cdrtools-2.01a33 did not compile
on my SuSE 9.0 and i just did the hack with the smallest possible
footprint to get it over that undefined symbol HZ. I happen to know
where it is defined on my system and already stumbled over the strange
fact that it is 100 for userland applications and 1000 for kernel
oriented code (an adjtimex(2) application works correctly with
HZ 1000 but the compiler gets to see HZ 100).
It is a mess. Joerg is right to reject any responsibility for that.
I just asked for some friendly advice in case anybody knew anything.
> So what's wrong with asking OS, e.g. with
> sysconf(_SC_CLK_TCK)? A.
In first place : i did not know about _SC_CLK_TCK
but second : it returns 100 within the adjtimex(2) application where this
value is clearly wrong. SuSE 9.0 adjtimex() rejects input that was computed
based on HZ 100 (man: "... buf.tick ... range 900000/HZ to 1100000/HZ ...")
(Whatever that all may mean for cdrtools.)
In my system's /usr/include/asm/param.h i read :
#ifdef __KERNEL__
# define HZ 1000 /* Internal kernel timer frequency */
# define USER_HZ 100 /* .. some user interfaces are in
"ticks" */
# define CLOCKS_PER_SEC (USER_HZ) /* like times() */
#endif
#ifndef HZ
#define HZ 100
#endif
My current assumption is that cdrecord would prefer the kernel oriented value
of 1000. Well, trying 100 didn't break it either. At least not visibly.
Any idea where i could try to learn about the roots of this mess ?
Have a nice day :)
Thomas
Reply to: