Time accounting is incorrect on Mac and not accurate on Linux

[harendra-kumar]

Ideally utime + stime = cpuTime. On Linux this holds approximately (though I would like it to be more accurate there as well, I have seen significant aberration) but on Mac it doesn't hold at all. In fact on Mac I observed that stime is always 0. Sometimes even utime is zero even though cpuTime is a significant value, for example:

cpuTime              175.8 ms  
utime                0.0 s     
stime                0.0 s     

@vincenthz I saw some commits from you fixing cycles stuff, while your L1 cache is hot, can you take a look what's going on here. It seems there is still something wrong with measuring time on Mac. I tested at commit 6164dc4 .

On Linux there is some irregularity, I know that we measure cpuTime and utime/stime using different methods and at different points but even then I do not expect an aberration of milliseconds. I am seeing an aberration of upto 2-3 ms which is quite significant:

cpuTime              182.0 ms  
utime                180.0 ms  
stime                4.000 ms  
...
cpuTime              166.6 ms  
utime                156.0 ms  
stime                8.000 ms  
...
cpuTime              52.83 ms  
utime                56.00 ms  
stime                0.0 s     

I also observed that utime and stime never have a non-zero fractional part, maybe the aberration is due to this loss of precision and that may be the reason why it is always up to 2 ms.

[vincenthz]

I don't really have time unfortunately to fix it straight away as I've been preempted, but clearly one thing I notice is that keeping the value in microseconds to renormalize by iterations is going to be problematic in term of precision. I'll look to get this fix, and finding the root cause of the issue of utime/stime.