> >>> Is this box just too slow to keep time and compile software?
> >>
> >> No, it's nearly a bug, a major caveat of NetBSD kernel these days.
> >> Kernel sits in timer interrupt masked off condition longer than used
> >> to be, and looses ticks when it runs busy.
> >
> > I notice in the sample kernels:
> >
> >  options         "HZ=256"        # RTC rate required
> >
> > Is it possible to use a different value for this?
> > Or is it the way the hardware is wired?
> 
> The time slice value should be adjustable, though I'm reluctant a bit to
> change such the basic parameter of NetBSD/pmax.  It's possibel to re-program
> RTC clock source inside arch/mips/mips/mips_mcclock.c;
> 
>      ...
> #else
>      clk[MC_REGA].datum = MC_BASE_32_KHz | MC_RATE_256_Hz;
>      clk[MC_REGB].datum = MC_REGB_BINARY|MC_REGB_24HR|MC_REGB_PIE| MC_REGB_SQWE;
> #endif
>      /* count loop iterations between ticks */
>      iters = (*tickpollfn)(mcclock_addr, clockmask);
> 
>      /* Restore mcclock registers */
>      clk[MC_REGA].datum = saved_rega;    <-----------------
>      clk[MC_REGB].datum = saved_regb;
> 
> Ok to adjust there and options HZ= line, I guess.
> 
> The 256Hz time slice value is one of smallest tick cycles across
> NetBSD ports (next to Alpha which has 1024Hz).

I agree and only wish to experiment with what effect such a change
might have on the current situation.  I don't see such a change as
anything close to a "fix."  The fix is to track down and reduce the
masked clock tick issue instead - I was just curious about the time
HZ setting.

Thank you!

(I am still waiting for the 133 and now a 150 to build -current so I
might experiment and also try and do some kernel profiling as recommended
some time ago on this list, I think.)

-- Ken