<div class="moz-cite-prefix">On 21/05/14 01:42, Tom Lane wrote:<br /></div><blockquote
cite="mid:24480.1400593335@sss.pgh.pa.us"type="cite"><pre wrap="">Andrew Dunstan <a class="moz-txt-link-rfc2396E"
href="mailto:andrew@dunslane.net"><andrew@dunslane.net></a>writes:
</pre><blockquote type="cite"><pre wrap="">On 05/20/2014 07:09 AM, Tom Lane wrote:
</pre><blockquote type="cite"><pre wrap="">Robert's got a point here. In my usage, the annoying thing is not animals
that take a long time to report in; it's the ones that lie about the
snapshot time (which is how you get "512abc4 in the middle of a bunch of
ef9ab5f's"). That is an issue of incorrect system clock, not of how long
it takes to do the run. I wonder if the buildfarm script could be taught
to get the timestamp from an NTP server somewhere? Or at least
sanity-check the system clock reading by comparing it to the newest commit
timestamp in the git repo.
</pre></blockquote></blockquote><pre wrap="">
</pre><blockquote type="cite"><pre wrap="">Regarding clock skew, I think we can do better then what you suggest.
The web transaction code in the client adds its own timestamp just
before running the web transaction. It would be quite reasonable to
reject reports from machines with skewed clocks based on this value. I'm
not sure what a reasonable skew might be. Somewhere in the range of 5 to
15 minutes seems reasonable.
</pre></blockquote><pre wrap="">
Rather than reject, why not take the result and adjust the claimed start
timestamp by the difference between the web transaction timestamp and the
buildfarm server's time?
regards, tom lane
</pre></blockquote> I think, that if possible, any such adjustment should be noted along with the original time, so
that:<br/><ol><li>the timing issue can be remedied<li>it is possible to link the output to any messages in the machines
logetc.<br /></ol><br /> Cheers,<br /> Gavin<br />
