2.4: variable HZ
Hiya... Nice patch, must try it when I find a few minutes - I think I have a few apps that are limited by select/poll behaviour.
I was looking at your jiffies_to_clock_t() macro, and I notice that it will screw up badly if the user chooses a HZ value that isn't a multiple of the normal value (e.g. 1000 is OK, 512 isn't).
How about tweaking the macro a little? Instead of:
x / (HZ/USER_HZ)
you could use:
(x/HZ*USER_HZ + x%HZ*USER_HZ/HZ)
which minimises roundoff error and also won't overflow (at least, it won't overflow as long as HZ*USER_HZ doesn't overflow!).
You could even use both versions of the macro, choosing between them at compile time depending on whether or not (HZ % USER_HZ == 0).
What do you think?
cheers
Neil
PS: I'm off-list.
Quoted 3 lines · Neil Conway
I was looking at your
jiffies_to_clock_t()macro, and I notice that it will screw up badly if the user chooses a HZ value that isn't a multiple of the normal value (e.g. 1000 is OK, 512 isn't).
OK, sure, but why specify a power-of-two HZ? There is absolutely no reason to, at least on x86.
Want 512? 500 will do just as well and has the benefit of (a) being a multiple of the previous HZ and (b) evenly dividing into our concept of time.
Robert Love
Quoted 6 lines · Robert Love
Quoted 3 lines · Neil Conway
I was looking at your
jiffies_to_clock_t()macro, and I notice that it will screw up badly if the user chooses a HZ value that isn't a multiple of the normal value (e.g. 1000 is OK, 512 isn't).
Quoted 9 lines
OK, sure, but why specify a power-of-two HZ? There is absolutely no reason to, at least on x86.
Want 512? 500 will do just as well and has the benefit of (a) being a multiple of the previous HZ and (b) evenly dividing into our concept of time.
Robert Love
At least on ix86, HZ needs to be something that CLOCK_TICK_RATE/LATCH comes out fairly close. Remember, LATCH is the divisor for the PIT and that PIT gets CLOCK_TICK_RATE for its input. If this number isn't fairly 'exact' there will be much jumping of time in the sawtooth corrector.
If you are not using ELAN, CLOCK_TICK_RATE is 1193180. If your HZ is 100, you have 1193180/100 = 1193.18, not too exact. if you use 500, you get 1193180/500 = 2386.36 which has twice as much round-off. If you use 1193180/512 = 2330.43, even a higher fractional part.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). The US military has given us many words, FUBAR, SNAFU, now ENRON. Yes, top management were graduates of West Point and Annapolis.
Richard, would you believe that this is essentially what is done with the GPS satellites in the dither process and in the clock correction process to make the drifty Rb standards as stable as ground standards?
(You'd better. I designed the beastie involved.)
{^_-} Joanne, [email protected]
----- Original Message -----
From: "Richard B. Johnson" <[email protected]>
To: "Robert Love" <[email protected]>
Cc: "Neil Conway" <[email protected]>; <[email protected]>
Sent: Friday, October 18, 2002 12:38
Subject: Re: [PATCH] 2.4: variable HZ
Quoted 40 lines · Robert Love
Quoted 7 lines · Neil Conway
Quoted 4 lines
I was looking at your
jiffies_to_clock_t()macro, and I notice that it will screw up badly if the user chooses a HZ value that isn't a multiple of the normal value (e.g. 1000 is OK, 512 isn't).Quoted 9 lines
OK, sure, but why specify a power-of-two HZ? There is absolutely no reason to, at least on x86.
Want 512? 500 will do just as well and has the benefit of (a) being a multiple of the previous HZ and (b) evenly dividing into our concept of time.
Robert Love
At least on ix86, HZ needs to be something that CLOCK_TICK_RATE/LATCH comes out fairly close. Remember, LATCH is the divisor for the PIT and that PIT gets
CLOCK_TICK_RATEfor its input. If this number isn't fairly 'exact' there will be much jumping of time in the sawtooth corrector.If you are not using ELAN,
CLOCK_TICK_RATEis 1193180. If your HZ is 100, you have 1193180/100 = 1193.18, not too exact. if you use 500, you get 1193180/500 = 2386.36 which has twice as much round-off. If you use 1193180/512 = 2330.43, even a higher fractional part.Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). The US military has given us many words, FUBAR, SNAFU, now ENRON. Yes, top management were graduates of West Point and Annapolis.-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · jdow
Richard, would you believe that this is essentially what is done with the GPS satellites in the dither process and in the clock correction process to make the drifty Rb standards as stable as ground standards?
(You'd better. I designed the beastie involved.)
{^_-} Joanne, [email protected]
Sure. I helped develop a Kalman Filter that would run in real-time. It was first implemented in Matlab (which is awful to interpret). I rewrote it in ix86 assembly, using synthetic division (where you save the remainder and use it in a subsequent division for the same element in the polynomial). The result being that the filter generates no error even though it performs multiple divisions of non-integral numbers.
These techniques are great for continuous functions. Early filtering techniques, using classical methods (average, r.m.s, r.s.s, etc.) develop a bias because of round-off. The synthetic division bounds the bias to one less than the last divisor.
If you filter enough stuff, over a long enough time, you can make gold out of shit. The onboard GPS software has a very long time to tune. Its a good candidate. In principle, the ground standard doesn't have to be very good as long as it averages correctly with low residual bias.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). The US military has given us many words, FUBAR, SNAFU, now ENRON. Yes, top management were graduates of West Point and Annapolis.
Quoted 1 line · Richard B. Johnson
If you are not using ELAN,
CLOCK_TICK_RATEis 1193180.
well, in fact it's 1193181.666... (14318180/12).
Quoted 1 line
If your HZ is 100, you have 1193180/100 = 1193.18, not too exact.
you meant 1000, I suppose ?
Quoted 3 lines
if you use 500, you get 1193180/500 = 2386.36 which has twice as much round-off. If you use 1193180/512 = 2330.43, even a higher fractional part.
those interested can try 511 Hz (/2334.994) or 1900 Hz (/627.990) which has the double advantage of being multiple of 100 Hz and have a little drift due to frac part (/628 gives 1899.97 Hz, and /627 gives 1903.001 Hz). If you don't need a multiple of 100 Hz, I noticed that dividing by 5709 gives 209.0001 Hz.
I'm also wondering why we never use the RTC as an interrupt source. Are there any incompatible PCs ?
Cheers,
Willy
Quoted 2 lines · Robert Love
OK, sure, but why specify a power-of-two HZ? There is absolutely no reason to, at least on x86.
Totally agree. However, I wasn't restricting it to powers of two. You just happened to have mentioned 512 (wrt. RedHat).
Quoted 3 lines
Want 512? 500 will do just as well and has the benefit of (a) being a multiple of the previous HZ and (b) evenly dividing into our concept of time.
512 ~= 500. 150 !~= 100. Would someone want to use 150? Maybe...
Anyway, it's no big deal if you prefer to leave your patch as-is. However, if you do, then you need to at least add a comment to the code and modify the Configure.help to make it clear that only integer multiples work properly. In fact, you could just make the HZ Config value be a "speed-up ratio" which would make various bits of the patch cleaner.
Neil