On Thu, Mar 24, 2011 at 11:11, Achilleas Mantzios <achill@xxxxxxxxxxxxxxxxxxxxx> 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: 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
