On Wed, 7 May 2014, Alan Somers wrote:
On Tue, May 6, 2014 at 9:47 PM, Bruce Evans b...@optusnet.com.au 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))
+
On Wed, 7 May 2014, Alan Somers wrote:
On Tue, May 6, 2014 at 9:47 PM, Bruce Evans b...@optusnet.com.au 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))
+
On Wed, May 7, 2014 at 9:39 PM, Bruce Evans b...@optusnet.com.au 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 b...@optusnet.com.au wrote:
On Tue, 6 May 2014, Alan Somers wrote:
On Thu, 8 May 2014, Alan Somers wrote:
On Wed, May 7, 2014 at 9:39 PM, Bruce Evans b...@optusnet.com.au 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 b...@optusnet.com.au 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 for other programs that use
gettimeofday to measure durations. I
On Thu, May 8, 2014 at 4:55 PM, Dmitry Morozovsky ma...@rinet.ru 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
On Tue, May 6, 2014 at 9:47 PM, Bruce Evans b...@optusnet.com.au 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
On Wed, May 07, 2014 at 12:10:31PM -0600, Alan Somers wrote:
On Tue, May 6, 2014 at 9:47 PM, Bruce Evans b...@optusnet.com.au 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
On Wed, May 7, 2014 at 2:26 PM, Jilles Tjoelker jil...@stack.nl 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 b...@optusnet.com.au wrote:
On Tue, 6 May 2014, Alan Somers wrote:
Log:
dd(1) uses gettimeofday(2) to compute
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 b...@optusnet.com.au wrote:
On Tue, 6 May 2014, Alan Somers wrote:
...
The solution is to use clock_gettime(2) with CLOCK_MONOTONIC_PRECISE as
On Wed, 7 May 2014, Alan Somers wrote:
On Wed, May 7, 2014 at 2:26 PM, Jilles Tjoelker jil...@stack.nl 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
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,
12 matches
Mail list logo
