[DGD] Weird time deltas

[Raymond Jennings]

Eww...how precise is select()?

I did notice that a tight millitime() loop accurately tracked the time

On Mon, Dec 4, 2017 at 2:43 AM,  <bart at wotf.org> wrote:
> 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/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd