On Thu, May 8, 2014 at 4:55 PM, Dmitry Morozovsky wrote:
> On Wed, 7 May 2014, Alan Somers wrote:
>
> [snip]
>
>> Even if nanosecond resolution isn't useful, monotonicity is. Nobody
>> should be using a nonmonotonic clock just to measure durations. I
>> started an audit of all of FreeBSD to look
On Wed, 7 May 2014, Alan Somers wrote:
[snip]
> Even if nanosecond resolution isn't useful, monotonicity is. Nobody
> should be using a nonmonotonic clock just to measure durations. I
> started an audit of all of FreeBSD to look for other programs that use
> gettimeofday to measure durations.
On Thu, 8 May 2014, Alan Somers wrote:
On Wed, May 7, 2014 at 9:39 PM, Bruce Evans wrote:
On Wed, 7 May 2014, Jilles Tjoelker wrote:
On Wed, May 07, 2014 at 12:10:31PM -0600, Alan Somers wrote:
On Tue, May 6, 2014 at 9:47 PM, Bruce Evans wrote:
On Tue, 6 May 2014, Alan Somers wrote:
[s
On Wed, May 7, 2014 at 9:39 PM, Bruce Evans wrote:
> On Wed, 7 May 2014, Jilles Tjoelker wrote:
>
>> On Wed, May 07, 2014 at 12:10:31PM -0600, Alan Somers wrote:
>>>
>>> On Tue, May 6, 2014 at 9:47 PM, Bruce Evans wrote:
On Tue, 6 May 2014, Alan Somers wrote:
>
> ...
>
>
On Wed, 7 May 2014, Alan Somers wrote:
On Tue, May 6, 2014 at 9:47 PM, Bruce Evans wrote:
On Tue, 6 May 2014, Alan Somers wrote:
This is about some minor details that I didn't reply to for later followups.
+ if (clock_gettime(CLOCK_MONOTONIC_PRECISE, &tv))
+ err(EX_OSER
On Wed, 7 May 2014, Alan Somers wrote:
On Tue, May 6, 2014 at 9:47 PM, Bruce Evans wrote:
On Tue, 6 May 2014, Alan Somers wrote:
This is about some minor details that I didn't reply to for later followups.
+ if (clock_gettime(CLOCK_MONOTONIC_PRECISE, &tv))
+ err(EX_OSER
On Wed, 7 May 2014, Alan Somers wrote:
On Wed, May 7, 2014 at 2:26 PM, Jilles Tjoelker wrote:
The floating point addition starts losing precision after 8388608
seconds (slightly more than 97 days, a plausible uptime for a server).
It is better to subtract the timespecs to avoid this issue.
Wi
On Wed, 7 May 2014, Jilles Tjoelker wrote:
On Wed, May 07, 2014 at 12:10:31PM -0600, Alan Somers wrote:
On Tue, May 6, 2014 at 9:47 PM, Bruce Evans wrote:
On Tue, 6 May 2014, Alan Somers wrote:
...
The solution is to use clock_gettime(2) with CLOCK_MONOTONIC_PRECISE as
the
clock_id. That
On Wed, May 7, 2014 at 2:26 PM, Jilles Tjoelker wrote:
> On Wed, May 07, 2014 at 12:10:31PM -0600, Alan Somers wrote:
>> On Tue, May 6, 2014 at 9:47 PM, Bruce Evans wrote:
>> > On Tue, 6 May 2014, Alan Somers wrote:
>> >
>> >> Log:
>> >> dd(1) uses gettimeofday(2) to compute the throughput stati
On Wed, May 07, 2014 at 12:10:31PM -0600, Alan Somers wrote:
> On Tue, May 6, 2014 at 9:47 PM, Bruce Evans wrote:
> > On Tue, 6 May 2014, Alan Somers wrote:
> >
> >> Log:
> >> dd(1) uses gettimeofday(2) to compute the throughput statistics.
> >> However,
> >> gettimeofday returns the system cloc
On Tue, May 6, 2014 at 9:47 PM, Bruce Evans wrote:
> On Tue, 6 May 2014, Alan Somers wrote:
>
>> Log:
>> dd(1) uses gettimeofday(2) to compute the throughput statistics.
>> However,
>> gettimeofday returns the system clock, which may jump forward or back,
>> especially if NTP is in use. If the
On Tue, 6 May 2014, Alan Somers wrote:
Log:
dd(1) uses gettimeofday(2) to compute the throughput statistics. However,
gettimeofday returns the system clock, which may jump forward or back,
especially if NTP is in use. If the time jumps backwards, then dd will see
negative elapsed time, rou
Author: asomers
Date: Tue May 6 22:06:39 2014
New Revision: 265472
URL: http://svnweb.freebsd.org/changeset/base/265472
Log:
dd(1) uses gettimeofday(2) to compute the throughput statistics. However,
gettimeofday returns the system clock, which may jump forward or back,
especially if NTP is
13 matches
Mail list logo
