Re: [TCLCORE] To the best of my recollection regarding TIP#302

[Dipl. I. S. G. B. <se...@us...>]

 

Few minutes is not really a long way for "normal" wall clock (and
validation of certs is mostly redundant here, because nobody really
waiting to the last minutes to prolong the certs)... But it may be the
long way for internal stuff like timeouts, lock-attempts or whatever
acting normally in few milli-, micro-, or even nano-second ranges, let
alone real-time near infrastructure.

As for the scenarios - I saw it verifiably in our (tcl-based)
application server on the VMs of customers sometimes, where the time
running faster for some reason (so NTP adjusted the time backwards)...
Sure it is probably not regular case and goes to some issues with the
host system's clock or VMs time-sync settings and could be "solved" or
workarounded at least by increased NTP periodicity... But in enterprise
world one must firstly prove the issue and justify such change and even
then, it may takes longer as one could assume to get in production.
But even smaller jumps are "bad", especially if some handling of some
facilities freezes abrupt (due to "longer" lock-attempt or whatever
taking few milliseconds in regular case) - timing issues are the worse
thing ever, especially because sometimes it behaves like a snowball (for
instance the longer it takes, the more clicks impatient users doing, the
more requests the service get in the queue, ..., the longer it'd take
till everything would calm down till it becomes normalized).

Regarding "modern operating systems" - exactly therefore many of them
are moving to use monotonic time instead of "wall" time, even because it
is not really worthy of trust and may jump. This is basically the reason
why monotonic time exists. 

>From my point of view, everything (like `after`) expecting interval and
not the end-time, has to use monotonic time.
Everything else (like cron with fixed end-time) is rather an exception,
and people used `after` only because there was noting else to achieve
this.

But, especially following your arguments, one can then say - lets switch
`after` to mono-time by default (and provide `after -at` or `after
-wall` or whatever for wall time)... Just because related to your
assumptions, it wouldn't affect anything anyway (because "no long way
jumps" is equal to "mono-time runs almost synchronous with wall-time"). 

Hope this helps,
Serg. 

06.05.2025 18:16, Donal Fellows wrote: 

> What are the scenarios in which the clock jumps backwards a long way, except via manual manipulation? That matters because many modern operating systems are moving to not giving users the ability to manipulate the clock in that way as the clock is essential for the proper operation of some of their security measures (such as validation of certificates). If this is all a huge fight over an edge case, I'm going to suggest we don't get excited about it. 
> 
> Forward jumps are different (because they can happen because the machine was hibernated) as are small jumps back (an NTP update fixing a clock that's a bit fast). But there shouldn't be any large reverse clock changes from normal user operations. (Changing the timezone shouldn't affect the clock we care about. Despite Windows being Windows.) 
> 
> Donal. 
> 
> -------------------------
> 
> FROM: Dipl. Ing. Sergey G. Brester via Tcl-Core
> SENT: Tuesday, May 06, 2025 12:53
> TO: Harald Oehlmann
> CC: tcl...@li...
> SUBJECT: Re: [TCLCORE] To the best of my recollection regarding TIP#302 
> 
> Comments inlined... 
> 
> 06.05.2025 10:34, Harald Oehlmann wrote: 
> 
>> Christian, Sergey, thank you for your valuable contributions. We need that!
>> It is an absolute requirement for an integration system to work.
>> 
>> Yesterday, in the meeting, there was a strong objection to:
>> - change current after in using the wall clock
> 
> And they are?
> The thing is: 
> 
> * one can consider the change of current `after` to monotonic time as a bug-fix, because otherwise it can unexpectedly take too long by possible time jumps backwards (or too short by forwards jumps), e. g. abrupt the timer `after 100 ...` will be triggered in 1 hour instead of few milliseconds. With other words it is not a feature (only), but rather a bugfix in my opinion.
> * mostly (probably 99%) `after` will be used for short intervals, so the monotonic time is not only better suitable in this case, but absolute necessary; In event-driven application it is mandatory to handle any kind of timeout properly. For instance, before switch the implementation to mono-base we observed sporadic large "hangs" of whole system (distributed computing).
> 
> * 
> even for the case where `after` is used for long playing timers (like cron tasks, etc), it is not a big issue, because in this case it'd be only affected (and the difference becomes visible) by the time adjustments, and by such long timers it is not so flashy as by the short timers, because would only take a small fraction compared to whole interval.
> Just compare: 
> 
> after-base 
> timer 
> time jumps back for 5 min 
> deviation 
> 
> wall clock 
> after 100ms (timeout) 
> execution delayed for 5 minutes 
> 300000% 
> 
> after 1day (cron-time) 
> execution happens as "expected" 
> - 
> 
> monotonic 
> after 100ms (timeout) 
> execution happens as expected 
> - 
> 
> after 1day (cron-time) 
> execution happens 5 minutes earlier 
> 0.3% 
> 
> The issue is obvious, isn't it?
> Let alone if the "expected" behaviour of cron-time really to be as precise as possible (by wall time),
> it could be relative fast rewritten using new handler (after -at or whatever);
> Sure not well backwards compatible, but considering the deviation factor surely justified and only correct in this way. * the change of after is not enough at all, to handle everything properly we need to replace several timeouts with monotonic time (otherwise same issue as mentioned above with the hangs are unavoidable and especially evil by locks, up to absolute "no go" by conditional cross-process locks).
> 
>> - not use a command switch, but a new command for the new monolitic after, as this is seen as the future.
>> 
>> The way is not so important. Important is to get it. But sematics is always good for discussions ;-).
> 
> Sure. However in my case it is important, since already used dozen years. 
> But it is indeed a matter of discussion, however I am sure the implementation of both (mono-time and `after -at`) needs to be done simultaneously (and released together). 
> 
>> Christian, I am probably blind. Where is your "after -at" patch ?
> 
>> Sergey, would it possible to extract the monolitic clock part of your big code contributions ?
> 
> Well, it is a bit complex - some changes (timers rewrite, event handling, etc) are strict necessary, another (vwait, options for vwait/after for event masks, higher resolution, etc) are pure features fewer related to the monotonic clock, but depend on it... 
> We have already discussed the subject several times in tclchat. For example with Kevin Kenny, and IIRC the last conclusion was: 
> 
> - either to write several TIPs to discuss the RFE in parts (but let the code as is and adjust it later if expected);
> - or to split the code in few parts from scratch; 
> 
> Since the latter would also expect the same TIPs as in the former, possibly the right way is to start with the former. 
> 
> Regards,
> Serg. 
> 
> P.S. @Christian: your rude t-online provider rejected my mail on you yesterday with following error:
> 554 IP=... - None/bad reputation. Ask your postmaster for help or to contact to...@rx... for reset. (NOWL)
> Just to inform you, that they censor the customer's emails without their knowledge (I guess you were not notified about the mail or its reject). That "none" lets assume that they reject any mail from relays without reputation... I must admit, I never saw such a stupid block reason before.