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: http://www.aslab.com
> 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()
On Fri, 13 Apr 2001, Alan Cox wrote:
> > 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()
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: http://www.aslab.com
Andre Hedrick wrote:
>
> On Fri, 13 Apr 2001, Alan Cox wrote:
>
> > > 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()
Actually we could do the same thing they did for errno, i.e.
#define jiffies get_jiffies()
extern unsigned get_jiffies(void);
>
> 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
On Thu, 12 Apr 2001, george anzinger wrote:
> Actually we could do the same thing they did for errno, i.e.
>
> #define jiffies get_jiffies()
> extern unsigned get_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: http://www.aslab.com
Andre Hedrick <[email protected]> writes:
> On Thu, 12 Apr 2001, george anzinger wrote:
>
> > Actually we could do the same thing they did for errno, i.e.
> >
> > #define jiffies get_jiffies()
> > extern unsigned get_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.
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
"Eric W. Biederman" wrote:
>
> Andre Hedrick <[email protected]> writes:
>
> > On Thu, 12 Apr 2001, george anzinger wrote:
> >
> > > Actually we could do the same thing they did for errno, i.e.
> > >
> > > #define jiffies get_jiffies()
> > > extern unsigned get_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.
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.
>
> 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
On Thu, Apr 12, 2001 at 09:04:28PM -0700, Andre Hedrick wrote:
> On Thu, 12 Apr 2001, george anzinger wrote:
>
> > Actually we could do the same thing they did for errno, i.e.
> >
> > #define jiffies get_jiffies()
> > extern unsigned get_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.
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...
> 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.
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)
> 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
On Fri, Apr 13, 2001 at 08:20:56AM -0400, Mark Salisbury wrote:
> 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
--
Michael A. Raymond Office: (651) 683-3434
Irix Core Kernel Group
Mark Salisbury wrote:
>
> > 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.
>
> 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
>
> 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)
Andre Hedrick wrote:
>
> 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 */
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.
--
** [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.
On Thursday 12 April 2001 23:52, Andre Hedrick wrote:
> 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.
>
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
--
Roger Larsson
Skellefte?
Sweden
Roger Larsson wrote:
>
> On Thursday 12 April 2001 23:52, Andre Hedrick wrote:
> > 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.
> >
>
> 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...
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