Re: Timing overhead and Linux clock sources

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Greg Smith <greg(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Timing overhead and Linux clock sources
Date: 2012-08-28 03:16:28
Message-ID: 20120828031628.GA16116@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 27, 2012 at 11:13:00PM -0400, Greg Smith wrote:
> On 08/27/2012 06:20 PM, Bruce Momjian wrote:
> >On Mon, Aug 27, 2012 at 04:42:34PM -0400, Robert Haas wrote:
> >>I don't see why it's better for the first line to have a big number
> >>than the last line. What difference does it make?
> >
> >When you are looking at that output, the<1 usec is where you want to
> >see most of the percentage, and it trails off after that.
>
> After staring at all the examples I generated again, I think Bruce
> is right that the newer format he's suggesting is better. I know I
> never thought about whether reordering for easier interpretation
> made sense before, and I'd also guess "it was less coding" for the
> existing order was the only reason Ants did it that way.
>
> Where I think this is a most useful improvement is when comparing
> two systems with different results that don't end at the same
> boundary. The proposed formatting would show the good vs. bad
> examples I put in the docs like this:
>
> < usec: count percent
> 1: 27694571 90.23734%
> 2: 2993204 9.75277%
> 4: 3010 0.00981%
> 8: 22 0.00007%
> 16: 1 0.00000%
> 32: 1 0.00000%
>
> < usec: count percent
> 1: 1155682 27.84870%
> 2: 2990371 72.05956%
> 4: 3241 0.07810%
> 8: 563 0.01357%
> 16: 3 0.00007%
>
> And I think it's easier to compare those two in that order. The
> docs do specifically suggest staring at the <1 usec numbers first,
> and having just mocked up both orders I do prefer this one for that
> job. The way this was originally written, it's easier to come to an
> initially misleading conclusion. The fact that the first system
> sometimes spikes to the 32 usec range is the first thing that jumps
> out at you in the originally committed ordering, and that's not
> where people should focus first.

Yes, I was totally confused how you would explain how to analyze this.
Once the patch is applied you might find it easier to clearly state
that in the docs.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2012-08-28 03:21:38 Minor comment fixups
Previous Message Greg Smith 2012-08-28 03:13:00 Re: Timing overhead and Linux clock sources