On Fri, May 28, 2021 at 05:13:02AM +0700, Robert Elz wrote:
> But it isn't, you can't convert 60 ticks/second into some number of
> milliseconds, the two are different units.
Sure you can. period = 1/frequency.
But HZ (and now hz) in the code is also used as a period, thus the idioms:
On 2021-05-28 00:46, Joerg Sonnenberger wrote:
On Fri, May 28, 2021 at 03:14:24AM +0700, Robert Elz wrote:
Date:Thu, 27 May 2021 05:05:15 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| mlel...@serpens.de (Michael van Elst) writes:
|
On Fri, May 28, 2021 at 03:14:24AM +0700, Robert Elz wrote:
> Date:Thu, 27 May 2021 05:05:15 - (UTC)
> From:mlel...@serpens.de (Michael van Elst)
> Message-ID:
>
> | mlel...@serpens.de (Michael van Elst) writes:
> |
> | >Either direction mstohz or hztoms
On 2021-05-28 00:13, Robert Elz wrote:
Date:Thu, 27 May 2021 20:19:06 +
From:"Koning, Paul"
Message-ID: <8765ae3a-b5b7-4b67-82ce-93473a5b9...@dell.com>
| In this particular case it's converting frequency to period,
| that is a sensible conversion.
But
Date:Thu, 27 May 2021 20:19:06 +
From:"Koning, Paul"
Message-ID: <8765ae3a-b5b7-4b67-82ce-93473a5b9...@dell.com>
| 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
On 2021-05-27 22:50, Mouse wrote:
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.
At least as I use it and have heard it used, `tick' can also be used to
refer to the interval between two of those events.
> 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.
At least as I use it and have heard it used, `tick' can also be used to
refer to the interval between two of those events. "How long are timer
ticks on this
On 2021-05-27 22:14, Robert Elz wrote:
Date:Thu, 27 May 2021 05:05:15 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| And both should be replaced by hztous()/ustohz().
While changing ms to us is probably a good idea, when a change
> On May 27, 2021, at 4:14 PM, Robert Elz wrote:
>
> ...
> While changing ms to us is probably a good idea, when a change happens,
> the "hz" part should be changed too.
>
> hz is (a unit of) a measure of frequency, ms (or us) is (a unit of) a
> measure of time (duration) - converting one to
Date:Thu, 27 May 2021 05:05:15 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| mlel...@serpens.de (Michael van Elst) writes:
|
| >Either direction mstohz or hztoms should better always round up to
| >guarantee a minimal delay.
|
| And
>> How heavily is hztoms used?
> [18 uses]
That's...almost none, seems to me. And these
> sys/dev/ic/mvsata.c: timeout = mstohz(timeout + hztoms(1) - 1);
> sys/dev/ic/mvsata.c: ata_delay(chp, hztoms(1), "mvsata_edma2",
> wflags);
> sys/dev/sdmmc/if_bwfm_sdio.c:
mlel...@serpens.de (Michael van Elst) writes:
>Either direction mstohz or hztoms should better always round up to
>guarantee a minimal delay.
And both should be replaced by hztous()/ustohz().
Microseconds allow a time value of ~35 minutes as 32bit signed
integer, which should be a safe range
mo...@rodents-montreal.org (Mouse) writes:
>How heavily is hztoms used? (I would expect mstohz to be used far more
>heavily.)
sys/dev/acpi/acpi_cpu_cstate.c: sc->sc_cstate_sleep =
hztoms(acpitimer_delta(end, start)) * 1000;
sys/dev/spkr_audio.c: audiobell(sc->sc_audiodev, xhz,
> # define hztoms(t) ((unsigned int)(((t) + 0ul) * 1000ul / hz))
> when hz > 1000, this returns 0 for input of 1.
True, which is correct - when hz > 1000, one tick is less than one
millisecond.
If, that is, it's defined to round down (and, if not, the
implementation you quote is broken). What
> > Me too. I was - am - rather puzzled by it.
>
> Right. That was my issue. Claiming that you'd get more problems with
> rounding and issues with coarsness when running at a higher frequency,
> when it in fact is the exact opposite. With a higher frequency you have
> more accuracy and less
On 2021-05-26 12:59, Mouse wrote:
I don't fully understand the discussion here.
Initially people claimed that HZ at 8000 would be a problem,
Well, my experience indicates that it _is_ a problem, at least when
using disks at piixide (or pciide).
Right. But not for the reason suggested. But
> I don't fully understand the discussion here.
> Initially people claimed that HZ at 8000 would be a problem,
Well, my experience indicates that it _is_ a problem, at least when
using disks at piixide (or pciide).
> which for me seems a bit backwards.
Me too. I was - am - rather puzzled by
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 -, Michael van Elst wrote:
bou...@antioche.eu.org (Manuel Bouyer) writes:
Another issue could be
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 -, Michael van Elst wrote:
> > > > bou...@antioche.eu.org (Manuel Bouyer) writes:
> > > >
> > > > >Another issue could be mstohz() called
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 -, Michael van Elst wrote:
> > > bou...@antioche.eu.org (Manuel Bouyer) writes:
> > >
> > > >Another issue could be mstohz() called with a delay too short;
> > >
Manuel Bouyer writes:
> On Tue, May 25, 2021 at 10:46:04PM -, Michael van Elst wrote:
> > bou...@antioche.eu.org (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)
On Tue, May 25, 2021 at 10:46:04PM -, Michael van Elst wrote:
> bou...@antioche.eu.org (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))
>
bou...@antioche.eu.org (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))
If mstohz() would round up to full ticks, it could actually avoid
some pitfalls.
On Tue, May 25, 2021 at 04:04:56PM -0400, Mouse wrote:
> > I suppose it's not possible to configure ahcisata in the BIOS on the
> > long-delay machines?
>
> Thank you very much! Yes. That is possible - and it fixes the delay.
> I would not have thought to look for that; I would not have
On Tue, May 25, 2021 at 10:21:40PM +0200, Christoph Badura wrote:
> On Wed, May 26, 2021 at 05:02:52AM +1000, matthew green wrote:
> > > > +optionsHZ=8000
> > this can become a problem due to integer division.
> >
> > any number of ticks less than hz (8000) will be rounded
> > down to 0
>>> I suppose it's not possible to configure ahcisata in the BIOS on
>>> the long-delay machines?
>> I would not have thought to look for that; I would not have expected
>> piixide and ahcisata to be similar enough that a BIOS setting could
>> personality-swap between them.
> IIRC, they are not
On Wed, May 26, 2021 at 05:02:52AM +1000, matthew green wrote:
> > > +options HZ=8000
> this can become a problem due to integer division.
>
> any number of ticks less than hz (8000) will be rounded
> down to 0 in a number of places now, where as before it
> was only less than 100. i've seen
On Tue, May 25, 2021 at 04:04:56PM -0400, Mouse wrote:
> > I suppose it's not possible to configure ahcisata in the BIOS on the
> > long-delay machines?
>
> Thank you very much! Yes. That is possible - and it fixes the delay.
> I would not have thought to look for that; I would not have
> I suppose it's not possible to configure ahcisata in the BIOS on the
> long-delay machines?
Thank you very much! Yes. That is possible - and it fixes the delay.
I would not have thought to look for that; I would not have expected
piixide and ahcisata to be similar enough that a BIOS setting
or twice a year in production, then ...
Any newer hardware should have ahcisaata capable SATA controllers, so
this problem should
go away as the hardware ages out.
-thanks
-Brian
On May 25, 3:33pm, Mouse wrote:
} Subject: Re: 9.1: boot-time delay?
} >> Will HZ=1000 be suff
>>> +optionsHZ=8000
> this can become a problem due to integer division.
> any number of ticks less than hz (8000) will be rounded down to 0 in
> a number of places now, where as before it was only less than 100.
Dividing by hz would be used to...all I can think of is, to convert a
tick
>> Will HZ=1000 be sufficient and does that reduce the boot time?
> The latter is a good question which is likely to hint at possible
> causes. I'll experiment with various HZ values and see what happens.
At HZ=8000, the delay (based on the bracketed numbers) is almost
exactly 22 seconds.
At
> > +optionsHZ=8000
this can become a problem due to integer division.
any number of ticks less than hz (8000) will be rounded
down to 0 in a number of places now, where as before it
was only less than 100. i've seen this trip up in the
kernel before, and sometimes that '0' means 'poll',
> Is there a reason you need a frequency that high?
Yes. I'm not just cranking HZ up to be difficult. (I might do it just
to smoke out bugs...on my _own_ machines. Except, of course, that I
don't use 9.x except at work, where the tradeoffs are different.)
> Will HZ=1000 be sufficient and does
a factor of
100 times the
default, rather than an odd 80 times the default.
-thanks
-Brian
On May 25, 9:44am, Mouse wrote:
} Subject: Re: 9.1: boot-time delay?
} Last week, I wrote, here, of a delay when booting 9.1
}
} >>> [ 3.288539] uhub2: 4 ports with 4 removable, sel
Last week, I wrote, here, of a delay when booting 9.1
>>> [ 3.288539] uhub2: 4 ports with 4 removable, self powered
>>> [ 3.288539] uhub3: 6 ports with 6 removable, self powered
>>> [25.272567] wd0 at atabus0 drive 0
>>> [25.273568] wd0:
and, in a later mail,
> [A]s soon as I
On Tue 18 May 2021 at 15:40:05 -0400, Mouse wrote:
> This leads me to the depressing conclusion that it is probably one of
> the video drivers, which are not optional for the operational kernel.
I was going to suggest that even before reading this mail. I noticed in
my new machine that with an
>> [ 3.288539] uhub2: 4 ports with 4 removable, self powered
>> [ 3.288539] uhub3: 6 ports with 6 removable, self powered
>> [25.272567] wd0 at atabus0 drive 0
>> [25.273568] wd0:
> There are multiple things with long timeouts happening here, but it
> should be simple to find
On Tue, May 18, 2021 at 03:01:55PM -0400, Mouse wrote:
> [ 3.288539] uhub2: 4 ports with 4 removable, self powered
> [ 3.288539] uhub3: 6 ports with 6 removable, self powered
> [25.272567] wd0 at atabus0 drive 0
> [25.273568] wd0:
There are multiple things with long timeouts
On Tue, 18 May 2021 at 20:02, Mouse wrote:
>
> I'm dealing with a turnkey product running under 9.1/amd64. On certain
> hardware, there is a pause, almost exactly 22 seconds, during autoconf.
> I'm trying to eliminate it. A sufficiently cut-down kernel does the
> job, but another cut-down
40 matches
Mail list logo
