<div dir="ltr">Hi Karolis,<div><br></div><div>I'm glad you've found the right path. :)</div><div><br></div><div>The benchmark you came up with might be interesting to the temporally</div><div>obsessed on this list (such as myself) if you think it is worth posting. </div><div><br></div><div>You may have stumbled onto something unexpected or surprising that would</div><div>be worth analysing further. However, micro-benchmarking can often result</div><div>in learning as much or more about micro-benchmarking than the target</div><div>under the microscope.</div><div><br></div><div>Cheers,</div><div><br></div><div>Darach.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 13, 2015 at 8:43 PM, Karolis Petrauskas <span dir="ltr"><<a href="mailto:k.petrauskas@gmail.com" target="_blank">k.petrauskas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Mar 13, 2015 at 9:41 PM, Darach Ennis <<a href="mailto:darach@gmail.com">darach@gmail.com</a>> wrote:<br>
> Hi Karolis,<br>
><br>
> Out of curiosity, why are you comparing os:timestamp() to erlang:now()?<br>
<br>
</span>I found a bug in my software, related to the system time. Then I<br>
noticed mismatch of time values in the log messages and log<br>
timestamps. I expected that erlang:now() >= os:timestamp() at any<br>
point in time, but that rendered to be false. That's why I decided to<br>
ask this question here. My bugfix ended up by not using system time in<br>
that place at all.<br>
<span class=""><br>
> There is a possibility that frequent calls to erlang:now() runs ahead of the<br>
> clock as it must deliver unique values (guaranteed) whereas os:timestamp()<br>
> does not have this property. This alone may produce the behaviour you are<br>
> seeing independent of other variables (eg: +c).<br>
<br>
</span>Yes, but I observe the opposite.<br>
<span class=""><br>
> I wouldn't have considered either to be reasonably or easily comparable<br>
> against<br>
> each other. However, comparing one fun to precedent values returned by the<br>
> same fun should exhibit the relative behaviour you desire and correlate as<br>
> you<br>
> expect. But comparing os:timestamp to erlang:now doesn't seem supportable<br>
> as they behave differently by design.<br>
<br>
</span>Yes, that was the cause for the bug. I was taking system time<br>
(erlang:now()), truncating milliseconds from it and therefore got<br>
rounding errors increased to unexpected level. The following<br>
investigation is just because of curiosity.<br>
<div class="HOEnZb"><div class="h5"><br>
> Hence, curious as to your use case and why you are comparing these two<br>
> distinct functions.<br>
><br>
> Cheers,<br>
><br>
> Darach.<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">Karolis<br>
</font></span></blockquote></div><br></div>