[DGD] Weird time deltas

[bart at wotf.org]

Iirc the code causing this is probably the 'wait for active connections or
next call_out' in connection.c. select() is called with a timeout set to the
next call_out. If some connection related code comes inbetween, it is handled
immediately (calling the appropriate lpc code), else it waits for this timer
to expire. This can introduce some jitter in call_out timing, especially when
having some lpc code blocking the system for more than a few ms.

Bart.

On Mon, 4 Dec 2017 04:53:08 -0500, Dread Quixadhal wrote
> Since 1/20th of a second, or 50ms, I would guess this is an artifact 
> of either the timer itself, or the method used to initiate call_out’s.
> 
> I don’t know which way DGD uses to handle timed events, but there 
> are a few different options out there.  One way is to just check 
> scheduled event times against the current time on each trip around 
> the main event loop, doing any that are due or overdue.  Another way 
> is to make use of an OS signal mechanism, such as the UNIX signal 
> VTALARM to setup events to be processed.
> 
> Since your “lag” seems to be around 20ms, sometimes less,
>  sometimes more, it’s not unreasonable to think that either the 
> event processing loop rolls around at a regular interval, or 
> there’s a delay involved in propagating the event (likely if an 
> alarm signal is used), or the hardware clock isn’t reporting a 
> high enough resolution time to get anything more accurate.
> 
> Sent from Mail for Windows 10
> 
> From: Raymond Jennings
> Sent: Monday, December 4, 2017 3:35
> To: All about Dworkin's Game Driver
> Subject: Re: [DGD] Weird time deltas
> 
> Of note, the delay actually specified in the call_out() is 0.05
> exactly, with a reciprocal of 20.
> 
> On Mon, Dec 4, 2017 at 12:32 AM, Raymond Jennings 
> <shentino at gmail.com> wrote:
> > I've got a tight thread running.
> >
> > Every 1/20th or so of a second, it uses the kernel library's wiztool
> > to generate a status report, including resources and the status
> > command.
> >
> > As a minor performance metric to track lag, I also keep track of the
> > exact time elapsed since the previous cycle was started, basically
> > motivated to see how "late" the report callout fired.
> >
> > Oddly, instead of a buttery-smooth interval where the elapsed time is
> > reported pretty close to the requested delay, I'm getting mega
> > seriously weird millitime deltas that often appear to end in 5's, and
> > the digits look suspiciously like multiples of a negative power of
> > two.
> >
> > I run gentoo linux on kernel 4.14, is this some sort of artifact of
> > the kernel or am I running some funky timer hardware or what?
> >
> > I noticed that all the actually reported deltas have reciprocals of
> > 16, 32, or 21.333333333
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
> 
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/