Re: 9.1: boot-time delay?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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 that reduce the boot time?

The former is "no", in the sense that it will not be suitable for
production use on the turnkey system in question.  See below.

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.

> Also,while I don't entirely understand all the timing mechanisms
> inside NetBSD, it seems if you do need a higher frequency clock, I'd
> suggest HZ=10000, since it's a factor of 100 times the default,
> rather than an odd 80 times the default.

Unfortunately a value that is not a multiple of 8000 is not suitable.
(Why would 100 be better than 80, by the way?  I see no reason other
than a human-layer bias towards powers of 10, so I'm wondering if
that's all it is or if there's something I'm missing.)

In this application, userland computes values and pushes them, via a
parallel port, to external D->A hardware.  (Among other things.
Userland does quite a lot else, too; I am outlining just the stuff
relevant to HZ=8000.)  They need to be pushed at fairly precisely 8KHz
to get the desired result out of the D->A, but they are produced
burstily (IIRC, 4KHz bursts of two values each are most common).

The cleanest solution would probably be an external FIFO with an
external 8KHz clock.  But, for reasons such as installed hardware base,
addressing it in software is preferred if it works.  (Getting customers
to just install new software is much cheaper for the company than
forklift upgrades would be.)  I added code to the lp driver to buffer
values in the kernel and push them out based on clock ticks.  This
works relatively well; the only downside we have uncovered is the
boot-time delay, and even that surprises me.  Doing it in software
isn't perfect.  There is still the occasional glitch in timing when the
relevant interrupts are locked out.  But, so far, those glitches have
been a lower price than the external hardware.

I was rather grasping at straws when I tried changing HZ to see if it
fixed it; I was in somewhat of a "when you've eliminated the
impossible..." place after removing all three video drivers
(i915drmkms/intelfb, radeon/radeondrmkmsfb, and nouveau/nouveaufb) and
finding the delay still present.  I tried HZ next because there were
very few changes between the two kernels, and HZ looked like the most
likely of the ones remaining after the video drivers didn't fix it.  I
then tried the HZ change with all the video drivers present and it
still was fast with no HZ option but slow with HZ=8000.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B