Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?

From: Alexander Motin <mav_at_FreeBSD.org>
Date: Wed, 15 Aug 2012 17:49:55 +0300
On 15.08.2012 14:23, Lev Serebryakov wrote:
> Hello, Alexander.
> You wrote 15 августа 2012 г., 15:19:32:
>
> AM> I've meant `kern.timecounter`.
> kern.timecounter.tick: 1
> kern.timecounter.choice: TSC(800) i8254(0) dummy(-1000000)
> kern.timecounter.hardware: TSC
> kern.timecounter.stepwarnings: 0
> kern.timecounter.tc.i8254.mask: 65535
> kern.timecounter.tc.i8254.counter: 63995
> kern.timecounter.tc.i8254.frequency: 1193182
> kern.timecounter.tc.i8254.quality: 0
> kern.timecounter.tc.TSC.mask: 4294967295
> kern.timecounter.tc.TSC.counter: 276768292
> kern.timecounter.tc.TSC.frequency: 499912330
> kern.timecounter.tc.TSC.quality: 800
> kern.timecounter.invariant_tsc: 0

So since you have TSC timecounter, the trick with one-shot i8254 mode 
should work for you. Unluckily I was wrong. It should give you more 
correct global CPU usage percents statistics, but neither per-thread CPU 
usage (at least with ULE) nor load averages, as they both still depend 
on hardclock.

> AM> There is python GUI tool /usr/src/tools/sched/schedgraph.py for it.
> AM> Short manual is inside.
>   uh-oh, Python+Tk!  I wonder, will it work on Windows, as I don't have
>   ``headed'' FreeBSD or Linux machines :)
>
>   Will it work with ALQ output from KTR, not with output of ktrdump?

Have no idea what ALQ output looks like. ktrdump output is just a text 
file that script parses.

-- 
Alexander Motin
Received on Wed Aug 15 2012 - 12:50:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:29 UTC