Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration

Στις Thursday 24 March 2011 13:39:19 ο/η Marti Raudsepp έγραψε:
> On Thu, Mar 24, 2011 at 11:11, Achilleas Mantzios
> <achill(at)matrix(dot)gatewaynet(dot)com> wrote:
> > My problem had to do with the speed of gettimeofday. You might want to do some special setting regarding
> > your box's way of reading time for the hw clock.
>
> Just for extra info, on x86, TSC is usually the "fast" timeofday
> implementation. On recent CPUs in single-socket configurations, TSC
> should always be available, regardless of any power management. I
> don't know about multi-socket. If you want to know whether your kernel
> is using tsc, run:
>

That's what i am experiencing as well, in two of my FreeBSD boxes (work/home) i get:

phenom ii X4 :
==========
% sysctl -a | grep -i timecounter
kern.timecounter.tick: 1
kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000)
kern.timecounter.hardware: TSC
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.i8254.counter: 1960
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.ACPI-fast.mask: 4294967295
kern.timecounter.tc.ACPI-fast.counter: 3642319843
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.quality: 1000
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.HPET.counter: 1160619197
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.quality: 900
kern.timecounter.tc.TSC.mask: 4294967295
kern.timecounter.tc.TSC.counter: 2788277817
kern.timecounter.tc.TSC.frequency: 3400155810
kern.timecounter.tc.TSC.quality: -100
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 1

Pentium 4
======
% sysctl -a | grep -i timecounter
kern.timecounter.tick: 1
kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-1000000)
kern.timecounter.hardware: ACPI-fast
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.i8254.counter: 13682
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.ACPI-fast.counter: 6708142
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.quality: 1000
kern.timecounter.tc.TSC.mask: 4294967295
kern.timecounter.tc.TSC.counter: 3109326068
kern.timecounter.tc.TSC.frequency: 2663194296
kern.timecounter.tc.TSC.quality: 800
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 0

TSC, it seems, outperform the rest of clocks in terms of frequency.

> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> On older CPUs, you often had to disable some sort of power management
> in order to get a stable TSC -- the "ondemand" scaling governor is the
> top suspect. Disabling this is distro-specific. You have to reboot to
> get the kernel to re-test TSC. Unfortunately disabling power
> management later at boot doesn't help you, you have to prevent it from
> activating at all.
>
> For debugging, grepping dmesg for tsc or clocksource is often helpful.
> On machines with unstable TSC you'll see output like this:
>
> [ 0.000000] Fast TSC calibration using PIT
> [ 0.164068] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
> [ 0.196730] Switching to clocksource tsc
> [ 0.261347] Marking TSC unstable due to TSC halts in idle
> [ 0.261536] Switching to clocksource acpi_pm
>
> If you just want to get repeatable timings, you can force both
> machines to use the hpet clocksource:
> echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> Marti
>

--
Achilleas Mantzios