From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Time resolution in Emacs Date: Sun, 24 Apr 2022 09:10:34 +0300 Message-ID: <83fsm3nh9h.fsf@gnu.org> References: <5ed963b2-3fa8-48d8-627e-bc0571d15b43@gmail.com> <2dd15844-01b3-0144-740c-185ec8488a81@cs.ucla.edu> <4a23f3a4-fe8f-d396-49d8-10034803be63@gmail.com> <52fb10fb-892a-f273-3be8-28793f27e204@cs.ucla.edu> <5cd820d4-ae67-43d4-9e63-c284d51ff1e4@gmail.com> <83tuapvcxs.fsf@gnu.org> <6efc5d24-34a2-fd30-cd20-fe4ac3e48310@cs.ucla.edu> <83fsm8tdzl.fsf@gnu.org> <9e4781b2-2ffa-b1ce-09b4-ead82cad9038@cs.ucla.edu> <83ilr3siku.fsf@gnu.org> <4e41671c-fae8-61c4-845c-4c7ba4317e88@cs.ucla.edu> <83fsm7sh2s.fsf@gnu.org> <83czhbsgc2.fsf@gnu.org> <33fb24fb-282b-cc13-a597-e7b63f19982d@cs.ucla.edu> <83y1zzq6kd.fsf@gnu.org> <837d7hr8s3.fsf@gnu.org> <83czh8pb54.fsf@gnu.org> <55cea2fb-958a-7ca8-a26c-90b0e70e5ada@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35186"; mail-complaints-to="usenet@ciao.gmane.io" Cc: manikulin@gmail.com, corwin@bru.st, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 24 08:12:17 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1niVTk-0008xA-VR for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Apr 2022 08:12:17 +0200 Original-Received: from localhost ([::1]:52768 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1niVTj-00065z-BX for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Apr 2022 02:12:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60938) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1niVSR-0005Jh-UF for emacs-devel@gnu.org; Sun, 24 Apr 2022 02:10:55 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42210) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1niVSQ-0001i2-I6; Sun, 24 Apr 2022 02:10:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=V7o/pthqTGa6IVRXa1cSPDC+SfgNf6wPo42dFRj1hU0=; b=eGLkVkME4RlF dRD30mHlmqZm5I6ujs3jK4Qcp3v1B/1cP75KwSyjDjrkDe4gINe64qZREeQucYd9jhzMe3s6a/W+3 pbX3ldt3h6/dUirZdRBTvSW5AkAvUvTjj2xuTdFC5LPSkuk/Fx7imMQOrqu/+vFtR7+mwfzfS6HMh kzmbZPFuPAymd2finfsNDjunxCZRJIiKCqZJPBKWVJH6IvsR9iPbAH0VG6CvGVTnkW1YNTH6ml5u6 shO0CWzjcde7bfXmo74kq0Keqb+AdWVaGRIPDrX0M2AGty4DoOaYvIeg5K10CkCV6mNbGuTlnu/lR dReuz8fvmlPixjQAgGlHmA==; Original-Received: from [87.69.77.57] (port=2799 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1niVSP-00061z-Ut; Sun, 24 Apr 2022 02:10:54 -0400 In-Reply-To: <55cea2fb-958a-7ca8-a26c-90b0e70e5ada@cs.ucla.edu> (message from Paul Eggert on Sat, 23 Apr 2022 17:56:01 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:288827 Archived-At: > Date: Sat, 23 Apr 2022 17:56:01 -0700 > Cc: corwin@bru.st, manikulin@gmail.com, emacs-devel@gnu.org > From: Paul Eggert > > 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.