[Swan-dev] hi resolution time in log file

[Andrew Cagney]

On 28 October 2017 at 04:52, Paul Wouters <paul at nohats.ca> wrote:

> On Fri, 27 Oct 2017, Andrew Cagney wrote:
>
> I noticed that the timestamp added to log files has only a 1 second
>> resolution; this isn't much help when multiple
>> events get processed per second.  The reason is a combination time() (1
>> second resolution) and strftime() (doesn't
>> do sub-second resolution anyway).  I suspect all this pre-dates git
>> history.
>>
>
> Yes.
>
> Anyway, I'm looking at an alternative.  My thought is a combination of
>> gettimeofday() or
>> event_base_gettimeofday_cached() (the latter would peg our times to when
>> the event fired I believe which may not
>> be such a good idea, otoh it is cheap) and strftime() + printf().  Any
>> thoughts.
>>
>
> No specific advise from me here. Antony might know more about libevent
> and using it for timers?
>
>
I've pushed the first change.

struct timeval's getimeofday(2) claims that POSIX recommends struct
timespec's clock_gettime(2).  However, libevent uses struct timeval and
struct timespec lacks anything like timeradd(3) et.al. so I went with the
former.

I think, because event_base_gettimeofday_cached() doesn't change, it would
make for confusing logs.


PS: I'm also left wondering why delta time isn't a double, would make
>> specifying sub-second timers a lot easier
>> (i.e., 0.5)
>>
>
> I'm mostly left with a feeling time is overengineered and overly complex
> in our code - even if it is theorectically the most correct :P
>
>>
>>
Once some code was cleaned up, changing realtime_t's implementation was
straight forward so that does seem to work.

However, deltatime_t seems to be another story.  I'm going to up its
precision but note that a lot of code just flips it to time_t and uses that.
As for monotime_t I don't know what it is trying to do so I'll ignore it;
perhaps clock_gettime(CLOCK_MONOTONIC)?

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20171030/68d4175d/attachment.html>