Re: Wallclock jumps with/in/and libev

[Marc Lehmann]

On Thu, Dec 19, 2019 at 01:59:23AM +0100, Bernd Petrovitsch  
wrote:
> Can this be handled with libev (and - if yes - how) somewhat
> clean?

Since you inadvertently forced me to give this some though, I have
implemented the method using timerfd that I outlined in my last reply.

The latest CVS version at http://software.schmorp.de/pkg/libev.html
has support for this, but I plan to release libev 4.31 using this in a few
hours.

Basically, when the first ev_periodic watcher is started, libev tries
to create a timerfd and then rearms it on every timejump, rescheduling
periodics instantly.

If you want to give it a try, feel free, but also feel free to not to if
you are busy :) Feedback, of course, welcome.

Thanbks for nudging me, I planned to do this for a long time.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev

Re: Wallclock jumps with/in/and libev

[Marc Lehmann]

On Thu, Dec 19, 2019 at 01:59:23AM +0100, Bernd Petrovitsch  
wrote:
> Can this be handled with libev (and - if yes - how) somewhat
> clean?

Well, define "somewhat clean"? :)

libev should handle all forms of timejumps correctly, although a delay can
be introduced. You can study the gory details in ev.c:time_update () if
you have very technical questions :) (You can assume have_monotonic to be
true in your case).

> I'm aware of timerfd_create(2) and TFD_TIMER_CANCEL_ON_SET on
> somewhat recent Linux kernels.

Me too, but libev doesn't use this at the moment (and would have to work
without it in either case).

Note that you can relatively easily make use of this yourself by adding such
a timerfd as a wakeup source to your libev loop.

Simply having an io watcher will do - libev currently checks for time
jumps every second (see MIN_TIMEJUMP in the code, but reducing it to much
lower than 1s probably won't improve things much).

You should even be able to improve things by trying to call
ev_suspend()/ev_resume() in your timerfd callback, as that reschedules
periodics unconditionally. The drawback is that the time between
ev_suspend and ev_resume is lost to any ev_timers.

BTW., now that I think about how easy it might be, I will consider
including TFD_TIMER_CANCEL_ON_SET more strongly - I hadn't given it much
though till now because I thought integrating it would be a headache
w.r.t. to the exiting code, but mybe it is as easy as rescheduling the
periodics on each timejump... Thanks for forcing me to think about it :)

> I want to avoid a workarounds like "use a monotonic timer
> for the wallclock timeout and check the wallclock afterwards"
> to not wait too long if the wallclock jumps back or to check
> for wallclock changes in some very short timer.

That's effectively what libev does for you, for some value of "short
timer" that is probably around one second or one minute, depending on how
you would implement it.

Lastly, there is very little operational experience with all this - if you
try some of these things out and have some feedback, I'd be happy to hear
it.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev

Wallclock jumps with/in/and libev

[Bernd Petrovitsch]

Hi all!

I have an application which has monotonic and wallclock timers.
The local clock is basically NTP- and/or GPS-synchronized.
Nevertheless for reasons (beyond my power to change and
too strange to describe), the wallclock can jump forward
and/or backward.

Can this be handled with libev (and - if yes - how) somewhat
clean?

I'm aware of timerfd_create(2) and TFD_TIMER_CANCEL_ON_SET on
somewhat recent Linux kernels.

I want to avoid a workarounds like "use a monotonic timer
for the wallclock timeout and check the wallclock afterwards"
to not wait too long if the wallclock jumps back or to check
for wallclock changes in some very short timer.

MfG,
Bernd
-- 
Bernd Petrovitsch   Email : be...@tuxoid.at
 LUGA : http://www.luga.at



pEpkey.asc
Description: application/pgp-keys
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev