Re: 9.1: boot-time delay? [WORKAROUND FOUND]

[Johnny Billquist <bqt%softjar.se@localhost>]

On 2021-05-26 11:12, matthew green wrote:
> Manuel Bouyer writes:
> > On Wed, May 26, 2021 at 05:35:53PM +1000, matthew green wrote:
> > > Manuel Bouyer writes:
> > > > On Tue, May 25, 2021 at 10:46:04PM -0000, Michael van Elst wrote:
> > > > > bouyer%antioche.eu.org@localhost (Manuel Bouyer) writes:
> > > > >
> > > > > > Another issue could be mstohz() called with a delay too short;
> > > > > > mstohz() will round it up to 1 tick.
> > > > >
> > > > >
> > > > > #  define mstohz(ms) ((unsigned int)((ms + 0ul) * hz / 1000ul))
>
> actually, this one is problematic as well.
>
> mstohz(1) here gives 0 for hz < 1000.  "(1 + 0) * hz / 1000"
> for any 'hz' less than 1000 will give 0.

I don't fully understand the discussion here.
Initially people claimed that HZ at 8000 would be a problem, which for 
me seems a bit backwards. And this comment should make that even more 
obvious.

With hz at 8000, you actually get some usable value for mstohz(1), while 
with low hz definitions, you do not.

So why would a high frequency at a clock be a problem? Seems the person 
who claimed that must have gotten things a bit backwards.

I can only see two real problems with a high clock frequency:
1. The overhead of just dealing with clock interrupts increase.
2. If there are things that just give time in ticks, then ticks become 
very short. And if the assumption is that just one tick is enough, such 
an assumption can fail.

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol