> do you suspect the interrupt load is a problem, or
> are you just bothered by stats?
The latter, I replaced the workstation hardware bacause of a power
supply fan failure and the most noticeable difference was stats'
behaviour.
In passing, has anyone looked at fixing the uneven width of the las
> > looks like you just have HZ set to 1000.
> > stats isn't counting on that.
> >
> How does one change that?
i wouldn't suspect that one would want to.
the higher clock rate allows more precise
scheduling. the extra overhead should be
unnoticable on a 2.6ghz processor, except via
stats.
> >
> my machine has been up for 90+ days.
>
That sure makes a difference :-)
> looks like you just have HZ set to 1000.
> stats isn't counting on that.
>
How does one change that?
> also, 113 ethernet interrupts/sec is a pretty
> good clip.
Yes, that's also a bit steep. Intel chip, maybe I shou
On Mon Mar 1 12:53:59 EST 2010, lu...@proxima.alt.za wrote:
> > workstation only? I.e. it is not running venti?
>
> Thanks for the chance to follow up. I implemented quanstro's
> enhancement to /proc, and this is what I get right now, some
> twenty-four hours after starting up:
>
> 50
> workstation only? I.e. it is not running venti?
Thanks for the chance to follow up. I implemented quanstro's
enhancement to /proc, and this is what I get right now, some
twenty-four hours after starting up:
3 00 debugpt
7 0
On Sun, Feb 28, 2010 at 1:55 AM, wrote:
> The workstation I'm using presently seems to trigger as many
> interrupts as stats(1) can display, while the syscall graph is also
> extremely busy.
workstation only? I.e. it is not running venti?
ron
On Sun Feb 28 04:57:09 EST 2010, lu...@proxima.alt.za wrote:
> The workstation I'm using presently seems to trigger as many
> interrupts as stats(1) can display, while the syscall graph is also
> extremely busy.
>
> I presume this is anomalous. Killing the single instance of
> timesync(1) does no
