Linux-Kernel Archive: No 100 HZ timer !
Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware?
I do not care but your drives/floppy/tapes/cdroms/cdrws do:
/*
* Timeouts for various operations:
*/
#define WAIT_DRQ (5*HZ/100) /* 50msec - spec allows up to 20ms */
#ifdef CONFIG_APM
#define WAIT_READY (5*HZ) /* 5sec - some laptops are very slow */
#else
#define WAIT_READY (3*HZ/100) /* 30msec - should be instantaneous */
#endif /* CONFIG_APM */
#define WAIT_PIDENTIFY (10*HZ) /* 10sec - should be less than 3ms (?), if all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30*HZ) /* 30sec - worst case when spinning up */ #define WAIT_CMD (10*HZ) /* 10sec - maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */
Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt.
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035 Web: www.aslab.com
Quoted 7 lines
Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware?
#define
WAIT_MIN_SLEEP(2*HZ/100) /* 20msec - minimum sleep time */Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt.
The same values would be valid with add_timer and friends regardless. Its just that people who do
while(time_before(jiffies, started+DELAY))
{
if(poll_foo())
break;
}would need to either use add_timer or we could implement get_jiffies()
Quoted 12 lines · Alan Cox
Quoted 7 lines
Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware?
#define
WAIT_MIN_SLEEP(2*HZ/100) /* 20msec - minimum sleep time */Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt.
The same values would be valid with
add_timerand friends regardless. Its just that people who do
Quoted 7 lines
while(time_before(jiffies, started+DELAY)) { if(poll_foo()) break; }would need to either use
add_timeror we could implementget_jiffies()
Okay regardless of the call what is it going to be or do we just random and go oh-crap data!?!?
Since HZ!==100 of all archs that have ATA/ATAPI support, it is a mircale that FS corruption and system death is not more rampant, except for the fact that hardware is quick by a factor of 10+ so that 1000 does not quite do as much harm but the associated mean of HZ changes and that is a problem with slower hardware.
Nevermind just going nuts over the issues...
Just trying to keep the flamage down and stuff like that....
Cheers,
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035 Web: www.aslab.com
Quoted 15 lines · Andre Hedrick
Quoted 12 lines · Alan Cox
Quoted 7 lines
Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware?
#define
WAIT_MIN_SLEEP(2*HZ/100) /* 20msec - minimum sleep time */Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt.
The same values would be valid with
add_timerand friends regardless. Its just that people who do
Quoted 7 lines
Quoted 7 lines
while(time_before(jiffies, started+DELAY)) { if(poll_foo()) break; }would need to either use
add_timeror we could implementget_jiffies()
Actually we could do the same thing they did for errno, i.e.
#define jiffies get_jiffies()
extern unsigned get_jiffies(void);
Quoted 9 lines
Okay regardless of the call what is it going to be or do we just random and go oh-crap data!?!?
Since HZ!==100 of all archs that have ATA/ATAPI support, it is a mircale that FS corruption and system death is not more rampant, except for the fact that hardware is quick by a factor of 10+ so that 1000 does not quite do as much harm but the associated mean of HZ changes and that is a problem with slower hardware.
No, not really. HZ still defines the units of jiffies and most all the timing is still related to it. Its just that interrupts are only "set up" when a "real" time event is due.
George
Quoted 8 lines · george anzinger
Actually we could do the same thing they did for errno, i.e.
#define jiffies
get_jiffies()
extern unsignedget_jiffies(void);No, not really. HZ still defines the units of jiffies and most all the timing is still related to it. Its just that interrupts are only "set up" when a "real" time event is due.
Great HZ always defines units of jiffies, but that is worthless if there is not a ruleset that tells me a value to divide by to return it to a specific quantity of time.
Cheers,
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035 Web: www.aslab.com
Quoted 7 lines · Andre Hedrick
Quoted 4 lines · george anzinger
Actually we could do the same thing they did for errno, i.e.
#define jiffies
get_jiffies()
extern unsignedget_jiffies(void);
Quoted 7 lines
Quoted 3 lines
No, not really. HZ still defines the units of jiffies and most all the timing is still related to it. Its just that interrupts are only "set up" when a "real" time event is due.
Great HZ always defines units of jiffies, but that is worthless if there is not a ruleset that tells me a value to divide by to return it to a specific quantity of time.
Actually in rearranging it. jiffies should probably be redefined as the smallest sleep we are prepared to take. And then HZ because the number of those smallest sleeps per second. So we might see HZ values up in the millions but otherwise things should be pretty much as normal.
It's an interesting question though. How large should HZ be with programmable timers.
Eric
Quoted 10 lines · Eric W. Biederman
Quoted 7 lines · Andre Hedrick
Quoted 4 lines · george anzinger
Actually we could do the same thing they did for errno, i.e.
#define jiffies
get_jiffies()
extern unsignedget_jiffies(void);
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
No, not really. HZ still defines the units of jiffies and most all the timing is still related to it. Its just that interrupts are only "set up" when a "real" time event is due.
Great HZ always defines units of jiffies, but that is worthless if there is not a ruleset that tells me a value to divide by to return it to a specific quantity of time.
The definition of HZ is the number of units in a second. Thus if HZ is 100 we are talking about a 10 ms jiffie.
Quoted 6 lines
Actually in rearranging it. jiffies should probably be redefined as the smallest sleep we are prepared to take. And then HZ because the number of those smallest sleeps per second. So we might see HZ values up in the millions but otherwise things should be pretty much as normal.
Actually I think it is more useful to define it as something like 100 for the following reasons.
I think it makes the most sense to keep jiffie as a simple unsigned int. If we leave drivers, and other code as is they can deal with single word (32 bit) values and get reasonable results. If we make HZ too high (say 10,000 to get micro second resolution) we will start limiting the max time we can handle, in this case to about 71.5 hours. (Actually 1/2 this value would start giving us trouble.) HZ only affects the kernel internals (the user API is either seconds/micro seconds or seconds/nano seconds). For those cases where we want a higer resolution we just add a sub jiffie component. Another way of looking at this is to set up HZ as the "normal" resolution. This would be the resolution (as it is today) of the usual API calls. Only calls to the POSIX 1b timers would be allowed to have higher resolution. I propose that we use the POSIX standard to define "CLOCKS" with various resolution, with the understanding that the higher resolutions will have higher overhead. An yet another consideration, to get high resolution with a reasonable maximum timer interval we will need to use two words in the timer. I think it makes sense to use the jiffie (i.e. 1/HZ) as the high order part of the timer's time.
Note that all of these considerations on jiffie size hold with or with out a tick less system.
George
Quoted 7 lines · Andre Hedrick
Quoted 4 lines · george anzinger
Actually we could do the same thing they did for errno, i.e.
#define jiffies
get_jiffies()
extern unsignedget_jiffies(void);
Quoted 7 lines
Quoted 3 lines
No, not really. HZ still defines the units of jiffies and most all the timing is still related to it. Its just that interrupts are only "set up" when a "real" time event is due.
Great HZ always defines units of jiffies, but that is worthless if there is not a ruleset that tells me a value to divide by to return it to a specific quantity of time.
It makes more sense to start migrating drivers to macros such as msec_to_jiffies(), msec_to_whatever_add_timer_wants(), etc. (Names changed to protect the innocent.) And leave HZ approximately the way it is, because that's what the code expects.
A good transition is for add_timer() to be defined as
#define add_timer(a) add_timer_ns(a*1000000000/HZ)
although this causes problems with timers over 4 seconds. As much as I like nanoseconds, it's probably overkill here, since one should be requesting absolute time if it's specified in nanoseconds.
dave...
Quoted 19 lines
I think it makes the most sense to keep jiffie as a simple unsigned int. If we leave drivers, and other code as is they can deal with single word (32 bit) values and get reasonable results. If we make HZ too high (say 10,000 to get micro second resolution) we will start limiting the max time we can handle, in this case to about 71.5 hours. (Actually 1/2 this value would start giving us trouble.) HZ only affects the kernel internals (the user API is either seconds/micro seconds or seconds/nano seconds). For those cases where we want a higer resolution we just add a sub jiffie component. Another way of looking at this is to set up HZ as the "normal" resolution. This would be the resolution (as it is today) of the usual API calls. Only calls to the POSIX 1b timers would be allowed to have higher resolution. I propose that we use the POSIX standard to define "CLOCKS" with various resolution, with the understanding that the higher resolutions will have higher overhead. An yet another consideration, to get high resolution with a reasonable maximum timer interval we will need to use two words in the timer. I think it makes sense to use the jiffie (i.e. 1/HZ) as the high order part of the timer's time.
Quoted 2 lines
Note that all of these considerations on jiffie size hold with or with out a tick less system.
inner loop, i.e. interrupt timer code should never have to convert from some real time value into number of decrementer ticks in order to set up the next interrupt as that requires devides (and 64 bit ones at that) in a tickless system.
this is why any variable interval list/heap/tree/whatever should be kept in local ticks. frequently used values can be pre-computed at boot time to speed up certain calculations (like how many local ticks/proc quantum)
Quoted 3 lines
Great HZ always defines units of jiffies, but that is worthless if there is not a ruleset that tells me a value to divide by to return it to a specific quantity of time.
HZ obviously.
Alan
Quoted 8 lines · Mark Salisbury
inner loop, i.e. interrupt timer code should never have to convert from some real time value into number of decrementer ticks in order to set up the next interrupt as that requires devides (and 64 bit ones at that) in a tickless system.
this is why any variable interval list/heap/tree/whatever should be kept in local ticks. frequently used values can be pre-computed at boot time to speed up certain calculations (like how many local ticks/proc quantum)
What about machines without synchronized local ticks? We're going to
have to end up doing conversions anyway because of drift and machines without even the same speed CPUs. A time based system using local cached values such as cycles_per_usec would better be able to handle this.
Michael
Signature · 2 lines
Michael A. Raymond Office: (651) 683-3434 Irix Core Kernel Group
Quoted 20 lines · Mark Salisbury
Quoted 20 lines
I think it makes the most sense to keep jiffie as a simple unsigned int. If we leave drivers, and other code as is they can deal with single word (32 bit) values and get reasonable results. If we make HZ too high (say 10,000 to get micro second resolution) we will start limiting the max time we can handle, in this case to about 71.5 hours. (Actually 1/2 this value would start giving us trouble.) HZ only affects the kernel internals (the user API is either seconds/micro seconds or seconds/nano seconds). For those cases where we want a higer resolution we just add a sub jiffie component. Another way of looking at this is to set up HZ as the "normal" resolution. This would be the resolution (as it is today) of the usual API calls. Only calls to the POSIX 1b timers would be allowed to have higher resolution. I propose that we use the POSIX standard to define "CLOCKS" with various resolution, with the understanding that the higher resolutions will have higher overhead. An yet another consideration, to get high resolution with a reasonable maximum timer interval we will need to use two words in the timer. I think it makes sense to use the jiffie (i.e. 1/HZ) as the high order part of the timer's time.
Quoted 7 lines
Quoted 2 lines
Note that all of these considerations on jiffie size hold with or with out a tick less system.
inner loop, i.e. interrupt timer code should never have to convert from some real time value into number of decrementer ticks in order to set up the next interrupt as that requires devides (and 64 bit ones at that) in a tickless system.
A good point! If we keep jiffies and sub jiffies in the timer structure, then the sub jiffies should be in hardware defined units (i.e. what we need to directly talk to the hardware). This argues for the jiffie to be longer than the longest expected inter event interval, i.e. for it to be larger than 10 ms. Seconds and sub seconds? At least this eliminates the mpy from the high order part.
I think we need to balance the units used in the time list with the needs of the list management code. It may not be a good idea to tie it too tightly to the jiffie. Thinking aloud here...
Another though, if we keep a small conversion table to convert from jiffies to machine units for say the first 10 jiffies, then force an "non event" timer interrupt if needed. This would, I guess, get us back to a tick system, but with tick every 10 jiffies... Still thinking...
George
Quoted 4 lines
this is why any variable interval list/heap/tree/whatever should be kept in local ticks. frequently used values can be pre-computed at boot time to speed up certain calculations (like how many local ticks/proc quantum)
Quoted 15 lines · Andre Hedrick
Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware?
I do not care but your drives/floppy/tapes/cdroms/cdrws do:
/*
* Timeouts for various operations:
*/
#defineWAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms */
#ifdefCONFIG_APM
#defineWAIT_READY(5*HZ) /* 5sec - some laptops are very slow */
#else
#defineWAIT_READY(3*HZ/100) /* 30msec - should be instantaneous */
#endif /*CONFIG_APM*/
Quoted 4 lines
#define WAIT_PIDENTIFY (10*HZ) /* 10sec - should be less than 3ms (?), if all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30*HZ) /* 30sec - worst case when spinning up */ #define WAIT_CMD (10*HZ) /* 10sec - maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */
May I make a coding-style suggestion (which is ugly on one hand, neat on the other):
#define mSec *Hz/1000 /* Convert millisecs to jiffies */ #define Sec *Hz /* Convert secs to jiffies */
#define WAIT_DRQ (50 mSec) /* spec allows up to 20ms */
#ifdef CONFIG_APM
#define WAIT_READY ( 5 Sec) /* some laptops are very slow */
#else
#define WAIT_READY (30 mSec) /* should be instantaneous */
#endif /* CONFIG_APM */
#define WAIT_PIDENTIFY (10 Sec) /* should be less than 3ms (?), if all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30 Sec) /* worst case when spinning up */ #define WAIT_CMD (10 Sec) /* maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (20 mSec) /* minimum sleep time */
I think that this is more readable than the above original.
Also note that the numbers are not really repeated in the comments. If someone changes the numbers, but not the comments, it may confuse someone quite some time before he/she notices that the number that is used is not the same as the one in the comment.
Roger.
Signature · 4 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots.
Quoted 20 lines · Andre Hedrick
Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware?
I do not care but your drives/floppy/tapes/cdroms/cdrws do:
/*
* Timeouts for various operations:
*/
#defineWAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms
*/ #ifdefCONFIG_APM
#defineWAIT_READY(5*HZ) /* 5sec - some laptops are very
slow */ #else
#defineWAIT_READY(3*HZ/100) /* 30msec - should be instantaneous
*/ #endif /*CONFIG_APM*/
#defineWAIT_PIDENTIFY(10*HZ) /* 10sec - should be less than 3ms (?), if all ATAPI CD is closed at boot */ #defineWAIT_WORSTCASE(30*HZ) /* 30sec
- worst case when spinning up */ #defineWAIT_CMD(10*HZ) /* 10sec
- maximum wait for an IRQ to happen */ #defineWAIT_MIN_SLEEP(2*HZ/100) /* 20msec - minimum sleep time */
Quoted 3 lines
Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt.
Wouldn't it make sense to define these in real world units? And to use that to determine requested accuracy...
Those who wait for seconds will probably not have a problem with up to (half) a second longer wait - or...?
Those in range of the current jiffie should be able to handle up to one jiffie longer...
Requesting a wait in ms gives yo ms accuracy...
/RogerL
Signature · 3 lines
Roger Larsson Skellefteå Sweden
Quoted 29 lines · Roger Larsson
Quoted 20 lines · Andre Hedrick
Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware?
I do not care but your drives/floppy/tapes/cdroms/cdrws do:
/*
* Timeouts for various operations:
*/
#defineWAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms
*/ #ifdefCONFIG_APM
#defineWAIT_READY(5*HZ) /* 5sec - some laptops are very
slow */ #else
#defineWAIT_READY(3*HZ/100) /* 30msec - should be instantaneous
*/ #endif /*CONFIG_APM*/
#defineWAIT_PIDENTIFY(10*HZ) /* 10sec - should be less than 3ms (?), if all ATAPI CD is closed at boot */ #defineWAIT_WORSTCASE(30*HZ) /* 30sec
- worst case when spinning up */ #defineWAIT_CMD(10*HZ) /* 10sec
- maximum wait for an IRQ to happen */ #defineWAIT_MIN_SLEEP(2*HZ/100) /* 20msec - minimum sleep time */Quoted 3 lines
Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt.
Wouldn't it make sense to define these in real world units? And to use that to determine requested accuracy...
Quoted 6 lines
Those who wait for seconds will probably not have a problem with up to (half) a second longer wait - or...?
Those in range of the current jiffie should be able to handle up to one jiffie longer...Requesting a wait in ms gives yo ms accuracy...
The POSIX standard seems to point to a "CLOCK" for this sort of thing. A "CLOCK" has a resolution. One might define CLOCK_10MS, CLOCK_1US, or CLOCK_1SEC, for example. Then the request for a delay would pass the CLOCK to use as an additional parameter. Of course, CLOCK could also wrap other characteristics of the timer. For example, the jiffies variable in the system could be described as a CLOCK which has a resolution of 10 ms and is the uptime. Another CLOCK might return something related to GMT or wall time (which, by the way, is allowed to slip around a bit relative to uptime to account for leap seconds, day light time, and even the date command).
Now to make this real for the kernel we would need to define a set of CLOCKs, to meet the kernel as well as the user needs. POSIX timers requires the CLOCK construct and doesn't limit it very much. Once defined to meet the standard, it is easy to extend the definition to fix the apparent needs. It is also easy to make the definition extensible and we (the high-res-timers project
http://sourceforge.net/projects/high-res-timers) intend to do so.
George
Hi!
Quoted 6 lines
/*
* Timeouts for various operations:
*/
#defineWAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms */
#ifdefCONFIG_APM
#defineWAIT_READY(5*HZ) /* 5sec - some laptops are very slow */
Broken broken broken. CONFIG_APM has *nothing* to do with machine being laptop. Think ACPI, think mips handheld. You should assume 5seconds, always.
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.