[erlang-questions] : now/0 resolution

[Serge Aleynikov]

Raimo Niskanen wrote:
>> So far I've been using successive now/0 calls in selected parts of 
>> function to measure execution times.  Doesn't the call trace slow down 
>> execution?
> 
> So does calls to now/0. If the number of call trace messages is the same
> as the number of calls to now/0, I do not know which is more expensive.
> I was thinking to measure the time for a call you could set
> trace flags [call,arity,timestamp] on the process and trace pattern
> [{'_',[],[{return_trace}]}] on the function to time to conveniently
> get the entry and exit time.  This could be combined with trace
> flag cpu_timestamp on 'all' processes.

This seems like a good way to profile function calls, however, I just 
need to record processing time together with incoming data packets 
coming at a very high rate (20-60k msgs/s).  I looked at implementation 
of now/0 and it indeed calls the HR timer, but the call is protected by 
a mutex, which adds some overhead to the call.  I guess this is done so 
that now/0 can safely return incrementing values on consecutive calls 
with SMP (this perhaps could be optimized using atomic increment).  It 
still seems to me that for packet latency analysis it would be helpful 
if HR timer was directly exposed as a BIF.

>> If I wanted to take advantage of the hr timer in a linked-in driver 
>> which function would you recommend to call?
> 
> I do not know. We use gethrvtime() on Solaris but can not find what
> we use on Linux. If erlang:trace(all, true, [cpu_timestamp]) does
> not badarg, the emulator has found a high resolution timer.

I examined the sources and using your hint found that HR timer is 
utilized on Linux via clock_gettime() OS call.

Serge