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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 27 May 2021 20:19:06 +0000
    From:        "Koning, Paul" <Paul.Koning%dell.com@localhost>
    Message-ID:  <8765AE3A-B5B7-4B67-82CE-93473A5B9921%dell.com@localhost>

  | In this particular case it's converting frequency to period,
  | that is a sensible conversion.

But it isn't, you can't convert 60 ticks/second into some number of
milliseconds, the two are different units.   That's just the same as
you can't convert metres/second (velocity) into seconds.   Given a
particular velocity, and some number of metres, you can calculate the
time it takes to move that far, but that isn't converting velocity
into seconds.

What it is happening is that (in one direction of the other, depending
upon which function) it is converting between the number of ticks that
occur and the duration of an interval (which of course depends upon the
frequency, but it is not converting the frequency).

The hztoms() function is no different than a ustoms() function, except
that in the former we have a semi-variable (the frequency) which is simply
a constant (1000) in the second - but that's only a variable because we
allow HZ to vary (by architecture, and sometimes, configuration).   Calling
ustoms() thousandtoms() would be absurd.   So is calling this one hztoms().

  | You could say "hztoperiodinus" but that's rather verbose.

That doesn't help, we're still not converting a frequency to a period.

And in another reply:

Johnny Billquist <bqt%softjar.se@localhost> said:
  | Frequency essentially means a counting of the number of  time something
  | happens over a specific time period. With hertz, the time  period is one
  | second.
 
Sure.

  | So then converting the number of times an event 
  | happens in a second into how long it is between two events makes total 
  | sense.

It would, but that's not what the functions do.   What they do is tell
how many ticks occur in a specific number of milliseconds (or vice
versa).   Your calculation is just (in milliseconds) 1000/hz, and assuming
hz isn't varying, is a constant.

  | A tick is not a duration. A tick is a specific event at a specific time.  It
  | has no duration. You have a duration between two ticks.

Sure, reasonable point, but as Mouse said, when we're dealing with this
stuff the number of ticks is counted as a representation of the number
of those durations, and we just say how many ticks happened.  The ticks
represent the duration between them - that might be slightly sloppy, but
it isn't outright wrong.

kre