Bug#534978: clock drift in Xen domU with clocksource=xen

[Josip Rodin <joy@debbugs.entuzijast.net>]

On Thu, Feb 25, 2010 at 03:01:41PM +0100, Bastian Blank wrote:
> > > No. The time resolution is not defined and within one step it will
> > > always provide the same value.
> > What? :) The problem here is that a time readout function provides the same
> > value across *two* steps. A monotonic function is one which allows for that.
> > A strictly increasing function is one which does not. Most of the time,
> > just monotonic is okay, but not always.
> 
> No, the time is only monotone, not strictly monotone. (With discreet
> values, it is not possible to make it strictly monotone.)

You mean discrete. It's impossible to make it strictly monotone in the
resolution that is smaller than the smallest unit of time (or one that
converges into zero).

But anyway, the problem isn't just the monotonicity, it's simply that e.g.
with HZ of 250, a jiffie takes 4ms, so if you need to do anything with
something that takes a comparable amount of time, you're shit outta luck.

> > > >                          and it also caused occasional PostgreSQL errors
> > > > with tables that had timestamp columns as keys, since it became possible
> > > > for two independent transactions to come in at the exact same time.
> > > Äh, where is documented, that this supposed to work anyway?
> > The key column has a unique constraint and a default value of current
> > timestamp. Even if two perfectly concurrent writers come in to add a new
> > record, it's still logical to expect for them to be serialized to a minimal
> > extent, because the database itself is explicitly instructed to input all
> > values and maintain their uniqueness. The expectation that all updates take
> > at least one minimal unit of time is perhaps not theoretically valid, but
> > it's certainly like that in the real world (every action takes *some*
> > perceivable time).
> 
> Wrong answer. Where is this documented as working in the postgresql
> documentation?

I have no idea. Why would I need an exact documentation of this use case?
The unique and default key parameters, and the definition of the timestamp
data type are documented. Indeed, I just checked and the resolution of a
timestamp is explicitly documented as 1 microsecond, so if the underlying
system has a resolution of 4000 microseconds, that simply precludes it.
If you're trying to argue that nobody should be using anything using
microseconds because they're not supported by clocksource=jiffies, well,
then we might as well cease this pointless discussion.

-- 
     2. That which causes joy or happiness.