<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: What time 18446744073709550.000 means</title>
	<atom:link href="http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/</link>
	<description>Everything about MySQL Performance</description>
	<lastBuildDate>Sat, 21 Nov 2009 05:23:57 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: peter</title>
		<link>http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/comment-page-1/#comment-564153</link>
		<dc:creator>peter</dc:creator>
		<pubDate>Wed, 20 May 2009 16:45:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=690#comment-564153</guid>
		<description>Vadmin - do you know why Google patches do not use monotonic clock in their patches for wall clock timing ?</description>
		<content:encoded><![CDATA[<p>Vadmin &#8211; do you know why Google patches do not use monotonic clock in their patches for wall clock timing ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: peter</title>
		<link>http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/comment-page-1/#comment-564152</link>
		<dc:creator>peter</dc:creator>
		<pubDate>Wed, 20 May 2009 16:45:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=690#comment-564152</guid>
		<description>Tim,

I think math wise you&#039;re right. However on the practical measures dealing with the huge values (not small negative values) is quite inconvenient.  We also mainly use this for things like query execution time etc where the gain of accuracy by using negative values is not worth loss of convenience.</description>
		<content:encoded><![CDATA[<p>Tim,</p>
<p>I think math wise you&#8217;re right. However on the practical measures dealing with the huge values (not small negative values) is quite inconvenient.  We also mainly use this for things like query execution time etc where the gain of accuracy by using negative values is not worth loss of convenience.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: foo</title>
		<link>http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/comment-page-1/#comment-563723</link>
		<dc:creator>foo</dc:creator>
		<pubDate>Tue, 19 May 2009 22:02:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=690#comment-563723</guid>
		<description>peter,

a monotonic clock won&#039;t go backwards and it probably provides equal or better performance when compared to the other clocks supported by clock_gettime.</description>
		<content:encoded><![CDATA[<p>peter,</p>
<p>a monotonic clock won&#8217;t go backwards and it probably provides equal or better performance when compared to the other clocks supported by clock_gettime.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: http://blog.timbunce.org/</title>
		<link>http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/comment-page-1/#comment-563663</link>
		<dc:creator>http://blog.timbunce.org/</dc:creator>
		<pubDate>Tue, 19 May 2009 21:23:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=690#comment-563663</guid>
		<description>Vadim. I believe the clocks are synchronized, just not as frequently as we&#039;d like so they drift slightly. I had a link that, as I recall, explained that, but it doesn&#039;t work now (http://webnews.giga.net.tw/article/mailing.freebsd.performance/710).

Re your analogy, imagine you have two watches (2 cpus) and each time you measure an interval you pick a watch at random (thread switched to different cpu). Over thousands of measurements you&#039;ll get a more accurate total if you don&#039;t discard negative durations.</description>
		<content:encoded><![CDATA[<p>Vadim. I believe the clocks are synchronized, just not as frequently as we&#8217;d like so they drift slightly. I had a link that, as I recall, explained that, but it doesn&#8217;t work now (<a href="http://webnews.giga.net.tw/article/mailing.freebsd.performance/710)" rel="nofollow">http://webnews.giga.net.tw/article/mailing.freebsd.performance/710)</a>.</p>
<p>Re your analogy, imagine you have two watches (2 cpus) and each time you measure an interval you pick a watch at random (thread switched to different cpu). Over thousands of measurements you&#8217;ll get a more accurate total if you don&#8217;t discard negative durations.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vadim</title>
		<link>http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/comment-page-1/#comment-563625</link>
		<dc:creator>Vadim</dc:creator>
		<pubDate>Tue, 19 May 2009 17:28:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=690#comment-563625</guid>
		<description>TimBunce,

It is two different timers. They are not synchronized. If we get negative time from two different clocks I do not see why we should add this time to total time, it has no good information.
It&#039;s like you measure time for runner and measure start time by your watches and measure finish time by your friend&#039;s watches, and difference between both watches is unknown.
It may happen your  friend&#039;s watches is slower by XYZ sec. And by your watches runner started at 10:54 and by your friend&#039;s watches he finished at 10:37.
By subtracting you get -0:17, but does it really have any sense ?</description>
		<content:encoded><![CDATA[<p>TimBunce,</p>
<p>It is two different timers. They are not synchronized. If we get negative time from two different clocks I do not see why we should add this time to total time, it has no good information.<br />
It&#8217;s like you measure time for runner and measure start time by your watches and measure finish time by your friend&#8217;s watches, and difference between both watches is unknown.<br />
It may happen your  friend&#8217;s watches is slower by XYZ sec. And by your watches runner started at 10:54 and by your friend&#8217;s watches he finished at 10:37.<br />
By subtracting you get -0:17, but does it really have any sense ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shlomi Noach</title>
		<link>http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/comment-page-1/#comment-563623</link>
		<dc:creator>Shlomi Noach</dc:creator>
		<pubDate>Tue, 19 May 2009 17:24:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=690#comment-563623</guid>
		<description>@Guillaume - thanks!</description>
		<content:encoded><![CDATA[<p>@Guillaume &#8211; thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: http://blog.timbunce.org/</title>
		<link>http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/comment-page-1/#comment-563621</link>
		<dc:creator>http://blog.timbunce.org/</dc:creator>
		<pubDate>Tue, 19 May 2009 16:51:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=690#comment-563621</guid>
		<description>Barron, I was referring to the underlying negative values that could arise from the clock_gettime() calls in the original article. The fact they&#039;re presented as a huge positive my mysqld is obviously a bug.</description>
		<content:encoded><![CDATA[<p>Barron, I was referring to the underlying negative values that could arise from the clock_gettime() calls in the original article. The fact they&#8217;re presented as a huge positive my mysqld is obviously a bug.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Guillaume Lefranc</title>
		<link>http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/comment-page-1/#comment-563561</link>
		<dc:creator>Guillaume Lefranc</dc:creator>
		<pubDate>Tue, 19 May 2009 12:58:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=690#comment-563561</guid>
		<description>@Shlomi, regarding negative times in slow query logs I filed this bug http://bugs.mysql.com/bug.php?id=35396, a patch was committed and should solve the problem. Nevertheless the problem was more about the NTP source that was not synchronizing correctly (ask your sysadmin not to run NTP in a virtual machine, quite a bad idea) and my servers having from -10/+10 sec. time readjust.</description>
		<content:encoded><![CDATA[<p>@Shlomi, regarding negative times in slow query logs I filed this bug <a href="http://bugs.mysql.com/bug.php?id=35396" rel="nofollow">http://bugs.mysql.com/bug.php?id=35396</a>, a patch was committed and should solve the problem. Nevertheless the problem was more about the NTP source that was not synchronizing correctly (ask your sysadmin not to run NTP in a virtual machine, quite a bad idea) and my servers having from -10/+10 sec. time readjust.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Baron Schwartz</title>
		<link>http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/comment-page-1/#comment-563558</link>
		<dc:creator>Baron Schwartz</dc:creator>
		<pubDate>Tue, 19 May 2009 12:55:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=690#comment-563558</guid>
		<description>If we allow negative times to accumulate naturally, it will skew things horribly.  These times go negative because they&#039;re very small to begin with; it would take many of them to add up enough to cancel out a single negative-gone-huge-positive.

Maatkit has handled these for a long time in mk-query-digest by setting them to zero during log aggregation.  I think this is reasonable because if it goes negative, it means it wasn&#039;t measurable anyway.</description>
		<content:encoded><![CDATA[<p>If we allow negative times to accumulate naturally, it will skew things horribly.  These times go negative because they&#8217;re very small to begin with; it would take many of them to add up enough to cancel out a single negative-gone-huge-positive.</p>
<p>Maatkit has handled these for a long time in mk-query-digest by setting them to zero during log aggregation.  I think this is reasonable because if it goes negative, it means it wasn&#8217;t measurable anyway.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: http://blog.timbunce.org/</title>
		<link>http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/comment-page-1/#comment-563496</link>
		<dc:creator>http://blog.timbunce.org/</dc:creator>
		<pubDate>Tue, 19 May 2009 09:09:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=690#comment-563496</guid>
		<description>In general you should allow negative times to be accumulated naturally as they&#039;ll tend to balance out over the longer term. Treating them as zero at the time they&#039;re measured would be wrong. Treating them as zero in reports, after accumulation, is less wrong but it&#039;s still better to educate the users to the harsh realities of clocks on SMP/virtual systems.

I&#039;d strongly suggest you allow the clock id passed to clock_gettime() to be configurable. Then the user can make their own choice about the accuracy vs performance trade-off that suits their needs best.

See also:
http://groups.google.com/group/comp.os.linux.development.apps/tree/browse_frm/thread/dc29071f2417f75f/ac44671fdb35f6db
http://sean.chittenden.org/news/2008/06/01/

It seems to be difficult to find good detailed information about the semantics of the various CLOCK_*&#039;s that clock_gettime() supports on various systems. If anyone has better links I&#039;d be grateful for them.</description>
		<content:encoded><![CDATA[<p>In general you should allow negative times to be accumulated naturally as they&#8217;ll tend to balance out over the longer term. Treating them as zero at the time they&#8217;re measured would be wrong. Treating them as zero in reports, after accumulation, is less wrong but it&#8217;s still better to educate the users to the harsh realities of clocks on SMP/virtual systems.</p>
<p>I&#8217;d strongly suggest you allow the clock id passed to clock_gettime() to be configurable. Then the user can make their own choice about the accuracy vs performance trade-off that suits their needs best.</p>
<p>See also:<br />
<a href="http://groups.google.com/group/comp.os.linux.development.apps/tree/browse_frm/thread/dc29071f2417f75f/ac44671fdb35f6db" rel="nofollow">http://groups.google.com/group/comp.os.linux.development.apps/tree/browse_frm/thread/dc29071f2417f75f/ac44671fdb35f6db</a><br />
<a href="http://sean.chittenden.org/news/2008/06/01/" rel="nofollow">http://sean.chittenden.org/news/2008/06/01/</a></p>
<p>It seems to be difficult to find good detailed information about the semantics of the various CLOCK_*&#8217;s that clock_gettime() supports on various systems. If anyone has better links I&#8217;d be grateful for them.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
