public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Tina Ruchandani <ruchandani.tina@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Pete Zaitcev <zaitcev@redhat.com>
Subject: Re: [PATCH] USB: usbmon: Remove timeval usage for timestamp
Date: Tue, 05 May 2015 17:33:03 +0200	[thread overview]
Message-ID: <4657648.5HP9obPUcU@wuerfel> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1505051053060.1639-100000@iolanthe.rowland.org>

On Tuesday 05 May 2015 10:59:32 Alan Stern wrote:
> On Tue, 5 May 2015, Arnd Bergmann wrote:
> 
> > Your conversion looks entirely correct, but the original code is a bit
> > odd here as it does not use the entire range of the 32-bit microsecond
> > value, and counts from 0 to 4096000000us instead of the more intuitive
> > 0 to 4294967296 us range before wrapping around.
> > 
> > If we change the code to 
> > 
> > static inline unsigned int mon_get_timestamp(void)
> > {
> > 	return ktime_to_us(ktime_get_real());
> > }
> > 
> > it might be more obvious what is going on, but it would slightly change
> > the output in the debugfs file to use the full range. Do we know what
> > behavior is expected by normal user space here? Pete Zaitcev submitted
> > a patch for this behavior in 2010, he might remember something about it.
> 
> I don't know of any programs that use the timestamp value, but if some 
> do exist then the way overflow works should not be changed.
> 
> In my experience, the timestamps are used by humans reading the usbmon
> output.  Overflow is rare, but when it does occur, a human finds it
> much easier to wrap from 4095.999999 seconds to 0.000000 than to wrap
> from 4294.967295 to 0.000000.
> 
> (Also, in the rare cases where usbmon timestamps have to be matched up
> with printk timestamps, it's easier to figure the relative offset when
> overflow affects only the seconds, not the fractions of a second.)

Ok, got it.

> > I also wonder if we should make the output use monotonic time instead
> > of real time (so change it to ktime_get_ts64() or ktime_get()). The effect
> > of that would be to keep the time ticking monotonically across a concurrent
> > settimeofday() call.
> 
> That seems reasonable to me.  The absolute values of the timestamps are 
> practically meaningless; only the differences are important.

Right, although it would also mean you could no longer match up the
microseconds with the printk timestamps.

	Arnd

  reply	other threads:[~2015-05-05 16:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-05  6:14 [PATCH] USB: usbmon: Remove timeval usage for timestamp Tina Ruchandani
2015-05-05  9:24 ` Arnd Bergmann
2015-05-05 14:59   ` Alan Stern
2015-05-05 15:33     ` Arnd Bergmann [this message]
2015-05-05 15:19   ` Pete Zaitcev
2015-05-05 15:40     ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4657648.5HP9obPUcU@wuerfel \
    --to=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=ruchandani.tina@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=zaitcev@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox