On Wed, Feb 22, 2012 at 6:53 AM, Greg Smith wrote:
> A look back on this now that I'm done with it does raise one large question
> though. I added some examples of how to measure timing overhead using psql.
> While I like the broken down timing data that this utility provides, I'm
> not sure whe
On Wed, Feb 22, 2012 at 19:36, Greg Smith wrote:
> From the patch:
>
> Newer operating systems may check for the known TSC problems and
> switch to a slower, more stable clock source when they are seen.
> If your system supports TSC time but doesn't default to that, it
> may be disabled for a good
On 02/22/2012 12:25 PM, Marti Raudsepp wrote:
On Wed, Feb 22, 2012 at 18:44, Greg Smith wrote:
As far as I've been able to tell, there aren't any issues unique to Windows
there. Multiple cores can have their TSC results get out of sync on Windows
for the same reason they do on Linux systems, a
On Wed, Feb 22, 2012 at 18:44, Greg Smith wrote:
> As far as I've been able to tell, there aren't any issues unique to Windows
> there. Multiple cores can have their TSC results get out of sync on Windows
> for the same reason they do on Linux systems, and there's also the same
> frequency/temper
On 02/22/2012 11:10 AM, Jay Levitt wrote:
N.B.: Windows has at least two clock APIs, timeGetTime and
QueryPerformanceCounters (and probably more, these days). They rely on
different hardware clocks, and can get out of sync with each other;
meanwhile, QueryPerformanceCounters can get out of sync w
Greg Smith wrote:
Anyway, the patch does now includes several examples and a short primer on
PC clock hardware, to help guide what good results look like and why they've
been impossible to obtain in the past. That's a bit Linux-centric, but the
hardware described covers almost all systems using
