[erlang-questions] writing a delay loop without now()

[Per Hedeland]

tsuraan <tsuraan@REDACTED> wrote:
>
>I'm running 2.6.28 (vanilla) and glibc 2.6.1.  Ntp is running in the
>background, but I don't think it's constantly messing with the system
>clock, at least not so much that it would cause these sorts of
>results.

No, it's very careful to just (effectively) reduce or increase the clock
frequency, won't step the time unless it's way off (i.e. 128 millisec:-).

>It's a gentoo system; everything is compiled with arch=i686 and O2.  I
>imagine that fedora uses at least O2 for everything, but are they
>still supporting pentium1 (arch=i586)?  I think that could slow things
>down a little, maybe.

Perhaps - most likely is probably some manual optimization in the
relevant kernel code.

>Just doing time2 (no wall_clock) reliably gives me {4999999,5000000}.
>If I do wall_clock, I pretty reliably get 4200 elapsed ms.

OK, that agrees well with a now() that completes in some 0.84
microseconds on average - "bumping" will occur every ~ 7th call to
fulfill the "increasing values" promise.

>> If you do get just about 5000000 (it can never be more), maybe you could
>> try the "twiddle" version (time3/1 below) too?
>
>That works really well, even with c(test, native):

Great, thanks for your perseverance.:-) So, you've confirmed what I said
way back: As long as the underlying OS returns sane results from
gettimeofday() or the equivalent, doing a tight-loop with microsecond-
level accuracy using now/1 works fine. The only problem is if your
system completes the call in less than 1 microsecond on average - in
which case you simply need to make sure that you don't call it so often,
do something else in between the calls to make sure they're at least a
microsecond apart.

Maybe you can even find something more useful to do than multiplying
bignums and throwing away the result.:-) And if you're really ambitious,
you could make this thing auto-adapting to OS/CPU speed - increase the
"twiddle time" until you start getting increments of 2 (or more) from
now/1, then you know that some "real" time has elapsed between calls.

--Per