From owner-svn-src-all@FreeBSD.ORG Wed May 7 20:46:54 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA43088E; Wed, 7 May 2014 20:46:54 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAB51C84; Wed, 7 May 2014 20:46:53 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hm4so2035403wib.17 for ; Wed, 07 May 2014 13:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7pmjOV7mkF2yOOEM4ANDnq0Zfa1Q0hzxRlBYWYosoFY=; b=hF5RPQsHx/HKL4PQPIgN93ZrHmQx1MyKvNMQendU83sFnDZoS+BC9XeqdSOS4MUifx HIH7mnkqzrPvvEMoTnY/cgACjgwT3RBPvmCXbSNfCk/VdyOludHME7fs0hsb0v2BJusR ECpBA6Ws1OHLZDMajRyMhVRUn472nzJBDHu/GFfyYVCBRePAwrbWX8mXKshgoiYPZoik ZcTnT/opLY0I9XD2R1ebAJ5epv0ktCyHm/QnB1fRRufxp//MdDOoi61WZS+3jdhtczsu TCSgXiICUwr4c7gHdf2al3pqJN+qxIrzP6VMP17y1GJChXSnI6ixU3dS3uo88JlqslnB iiVA== MIME-Version: 1.0 X-Received: by 10.194.91.175 with SMTP id cf15mr40870196wjb.5.1399495612048; Wed, 07 May 2014 13:46:52 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.168.130 with HTTP; Wed, 7 May 2014 13:46:51 -0700 (PDT) In-Reply-To: <20140507202623.GA14233@stack.nl> References: <201405062206.s46M6dxW060155@svn.freebsd.org> <20140507113345.B923@besplex.bde.org> <20140507202623.GA14233@stack.nl> Date: Wed, 7 May 2014 14:46:51 -0600 X-Google-Sender-Auth: MYxe_hf6OBZluJpRbQwylGOvQUc Message-ID: Subject: Re: svn commit: r265472 - head/bin/dd From: Alan Somers To: Jilles Tjoelker Content-Type: text/plain; charset=UTF-8 Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Bruce Evans , Alan Somers X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 20:46:54 -0000 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 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, round it up to 1usec, and print an absurdly fast >> >> transfer rate. >> >> >> >> The solution is to use clock_gettime(2) with CLOCK_MONOTONIC_PRECISE as >> >> the >> >> clock_id. That clock advances steadily, regardless of changes to the >> >> system >> >> clock. >> >> >> >> Reviewed by: delphij >> >> MFC after: 3 days >> >> Sponsored by: Spectra Logic >> >> ... >> >> >> >> Modified: head/bin/dd/dd.c >> >> >> >> ============================================================================== >> >> --- head/bin/dd/dd.c Tue May 6 22:04:50 2014 (r265471) >> >> +++ head/bin/dd/dd.c Tue May 6 22:06:39 2014 (r265472) >> >> @@ -50,7 +50,6 @@ __FBSDID("$FreeBSD$"); >> >> #include >> >> #include >> >> #include >> >> -#include >> >> >> >> #include >> >> #include >> >> @@ -61,6 +60,8 @@ __FBSDID("$FreeBSD$"); >> >> #include >> >> #include >> >> #include >> >> +#include > >> > Use of is a style bug. It is not used in BSD or KNF code >> > like dd used to be. > >> sysexits.h is recommended by the err(3) man page. Is that >> recommendation meant to apply selectively, or is it obsolete, or is >> some sort of edit war being waged by man page authors? > > The recommendation for was incompletely removed, yes. > >> [snip] >> >> - st.start = tv.tv_sec + tv.tv_usec * 1e-6; >> >> + if (clock_gettime(CLOCK_MONOTONIC_PRECISE, &tv)) >> >> + err(EX_OSERR, "clock_gettime"); >> [snip] >> >> + st.start = tv.tv_sec + tv.tv_nsec * 1.0e-9; >> >> } > > 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. > > With microseconds, the precision of a double is sufficient for 272 > years, so that calculation is probably acceptable. Good point. I'll fix it. BTW, FreeBSD does not have a timespecsub, but I notice that NetBSD does. This seems like a good candidate to import. http://netbsd.gw.com/cgi-bin/man-cgi?timespecsub++NetBSD-current > > I think I agree with Bruce that using CLOCK_MONOTONIC_PRECISE is not > necessary here; the standard CLOCK_MONOTONIC should suffice. > >> [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 haven't finished, but I've >> already found a lot, including xz, ping, hastd, fetch, systat, powerd, >> and others. I don't have time to fix them, though. Would you be >> interested, or do you know anyone else who would? > > I have a local patch for time(1). > > Whether the monotonic clock is right also depends on how long the > durations typically are. For very long durations, users might refer to > wall clocks and CLOCK_REALTIME may be more appropriate. I would say that gettimeofday() or CLOCK_REALTIME() should be used whenever the absolute value of the result matters. For example, if it's written to disk, displayed to the user, or used as an absolute wakeup time for something like at(1). But if only the relative value of 2 or more calls matter, then I think that a monotonic clock should always be used. A corollary is that durations that cross a reboot cycle, or when the start and end times are measured by different machines, must use the realtime clock. -Alan > > -- > Jilles Tjoelker