<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 30 October 2017 at 15:11, D. Hugh Redelmeier <span dir="ltr"><<a href="mailto:hugh@mimosa.com" target="_blank">hugh@mimosa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">| From: Andrew Cagney <<a href="mailto:andrew.cagney@gmail.com">andrew.cagney@gmail.com</a>><br>
<span class=""><br>
| I noticed that the timestamp added to log files has only a 1 second<br>
| resolution; this isn't much help when multiple events get processed per<br>
| second.<br>
<br>
</span>I haven't read logs much in a long time.  So my opinions should be<br>
taken with a grain of salt.<br>
<br>
Most of Pluto is a single thread.  The relationship between log lines<br>
is mostly sequential.  So fine-grained timing isn't important.<br>
<span class=""><br></span></blockquote><div><br></div><div>Our log time resolution needs to be more fine-grained than our smallest timeout and that is sub-second (1_000_000 was chosen because it was easy).  Without this it isn't possible to tell if adjacent log events for the same state are for the same or different events.</div><div><br></div><div>For instance, with xauth, pluto sends out back-to-back packets separated by a small delay; since we can't see the delay in the logs we can't confirm this is working.</div><div>(we've also got multiple threads and forks so we need to be able to reliably log that interaction to a fine level)<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
| PS: I'm also left wondering why delta time isn't a double, would make<br>
| specifying sub-second timers a lot easier (i.e., 0.5)<br>
<br>
</span>In the past, there was some advantage in never using floating point.<br>
That may be true on systems that use static linking and on some<br>
embedded systems.<br>
<br>
FP object code is generally fatter and slower than integer code, but<br>
perhaps not when the representation is wider than the integer ALU.<br>
<br>
Floating point is very hard to reason about.  It has all sorts of<br>
surprises.  God invented the integers.<br>
<br>
Many months ago I coded a change to represent in a higher precision,<br>
with an opaque type.  Before I got it checked in, the tree changed<br>
(event handling rewrite?) and I never got around to merging.<br></blockquote><div><br></div><div>I look at it as separate issues:<br></div><div><br></div><div>- deltatime_t's internal representation; since it needs to at least have the same resolution as the event loop, it might as well use the event-loops type</div><div><br></div><div>- where we specify a sub-second timeout constant, 0.5 is far easier than ((deltatime_t) { { 0, 500000 } }); presumably deltatime() can deal with this<br></div><div><br></div><div>However, we've still got lots of code forced to bypass all this - the interface for scheduling timers either takes seconds, milli-seconds, or struct timeval.<br></div><div><br></div><div>Andrew</div><div><br></div><div>PS: we're spending our time grinding through NSS crypto, everything else is in the noise (well almost, on very very loaded systems, the old linked list version of serialno_t->struct state and the locking version of logging both turn up in profiles)<br></div></div></div></div>