[En-Nut-Discussion] NutGetTickClock rounding (again)

Henrik Maier hmlists at focus-sw.com
Wed Jul 16 08:23:19 CEST 2008


> NO - i disagree.  I would call this *WRONG*  You are doing 'traditional
> rounding' at the 0.5 point. While mathematically that seems correct (ie:
> rounding money). Most developers Timeouts will be wrong 50% of the time.

Duane,

You are right it is more accurate for timing purposes not to use traditional
arithmetic rounding. Also my code broke when Nut/OS changed the
NutTimerMillisToTicks implementation from 4.2.1 to 4.4.1 because time-outs
were suddenly too short not because they were too long. 

Thank you for the very good explanation and constructive contribution. I had
another close look at the Linux kernel code and they are also using the
'rounding-up' method: 

   (m * HZ + MSEC_PER_SEC - 1) / MSEC_PER_SEC. 

In our case HZ is NutGetTickClock and MSEC_PER_SEC is 1000.

So the rounding should then be done this way I suppose:

---------------------------------------------------
 u_long NutTimerMillisToTicks(u_long ms)
 {
    if (ms >= 0x3E8000UL)
       return (ms / 1000UL) * NutGetTickClock();
    else
       return (ms * NutGetTickClock() + (1000UL - 1UL)) / 1000UL;
 }
-----------------------------------------------------

Henrik





More information about the En-Nut-Discussion mailing list