Re: Time resolution in Emacs

[Eli Zaretskii]

> Date: Sat, 23 Apr 2022 17:56:01 -0700
> Cc: corwin@bru.st, manikulin@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 4/22/22 23:27, Eli Zaretskii wrote:
> 
> > There's no reason to expect Emacs to be
> > able to support such applications on all platforms.
> 
> Quite right. Many people don't synchronize their clocks at all, and on 
> their systems Emacs can't generate accurate timestamps.
> 
> However, that doesn't mean Emacs should be sloppy about timestamps. If 
> an OS has two low-level time primitives A and B, and A's resolution is 
> 100 ms while B's is 1 ms, surely Emacs should prefer B. Using B helps 
> apps that can use 1-ms timestamps in a well-synchronized environment, 
> and it doesn't hurt apps that don't care about timestamp resolution.

Everything else being equal, yes.  But if using A requires complex
code that will require a lot of maintenance, and if using the results
of A will affect most or all of the Emacs applications that use
timestamps, then we might as well conclude that using A does "hurt" is
enough to reject it, and make do with a lower time accuracy.

And it's not like the current situation is unbearable: Emacs does work
with millisecond time intervals, and works reasonably well.  We are
nowhere near the 1-sec resolution of your argument above, we are waaay
better than that.  You are actually arguing for moving from
millisecond resolution to nanosecond resolution, and I'm asking where
are the Emacs applications that will benefit from such a high
resolution.  So far the examples you provided are marginal at best,
perhaps even irrelevant to what we do or want to do in Emacs.

> >  Not to mention
> > that synchronizing clocks to millisecond accuracy on non-RT systems is
> > in most cases futile, because the OS doesn't provide reliable timings
> > to that accuracy anyway.
> 
> Even if one limits one's attention to NTP on non-realtime systems it's 
> not hard to get agreement on a LAN to better than 10 ms, counting OS 
> jitter. And better-than-10-ms accuracy is growing in popularity, due to 
> applications that need good clocks and get them via PTP or other means. 
> I regularly use networks that are synchronized better than 10 ms, and I 
> wouldn't pooh-pooh the need for this sort of thing in apps that 
> coordinate with others.

That misses the point.  The point is that on a non-RT system there's
precious little one can reliably do with time intervals shorter than
10 ms.

> > We don't _insist_ on providing low-accuracy timestamps, but we should
> > definitely be certainly concerned about adding such non-trivial
> > complexity to Emacs
> 
> It sounds like we have miscommunicated, as this comment seems to 
> disagree with your email of a couple of days ago that said "There's no 
> problem whatsoever to provide high-resolution time stamps on MS-Windows".

You are again focused on low-level details of MS-Windows
implementation of the relevant primitives, whereas I'm talking about
much more general issues that affect all of Emacs on any platform.

My point is that your current plan, such as it is, for providing the
time accuracy for every source of time information we care about means
adding non-trivial complexity to Emacs, on all platforms, and I have
yet to see any evidence that what you propose is capable of solving
any large part of the problems we could face wrt comparing timestamps
from different sources using reasonably practical techniques.  So my
current conclusion is that, if anything, we should look for much
simpler solutions, which might move us closer to the goal at much
lower costs.  For example:

  . provide optional arguments to time-comparison APIs that allow to
    pass the comparison accuracy, leaving the specification of that
    accuracy to the caller;
  . provide some simple functions that return estimated accuracy of a
    time source, using a static database of known timestamp accuracies

I see no reason to go any further, and I definitely don't see any
justification for making the time accuracy be a mandatory part of any
time specification.  The needs for such accurate methods in the Emacs
world are very rare, not to say nonexistent, so we should not force on
everyone something that will only be needed by a very few.

> If the question is whether to use a less-accurate method A or 
> more-accurate method B to obtain timestamps, where Emacs continues its 
> current practice of converting the timestamps to 1-nanosecond resolution 
> internally before the user sees the timestamps, then I don't see why 
> Emacs should prefer A to B.

I do see why: the costs involved in implementing B.  Costs in coding,
testing, documenting, and maintaining that for years to come.  I tried
to explain that above and in my previous messages here.