On Die, 2008-09-02 at 22:42 +0200, Hannes Gredler wrote:
> On Tue, Sep 02, 2008 at 11:30:57AM -0400, Eric Malkowski wrote:
[...]
> | I like the sane_times() snippet.
> 
> looks like we need to extend the timer infra to work internally using
> 64-bit timers plus a frontend olsr_times() that takes care of all sort of
> overflow issues.

Risking to over-engineer the issue:
The key question is IMHO:
What are the largest timeouts/time differences to be handled (in the
foreseeable future)?
If they fit easily in 32bit, we should keep them in 32bit (read: use
"unsigned int") to avoid costly 53bit operations on 32bit hardware (as
all the small WLAN routers are where 64bit ints hurts much more than on
quad-core-4-GHz).
The price to pay: Look over the source and make sure to not simply
compare two timestamps as in "a < b" but compare as "a - b < 1<<31" (or
so). Overflow is then a non-issue.
If timeouts/... need 64bit values, we can simply switch everything to
64bit (as there is no choice).

And that's the background of the question of requirements - especially
the needed precision. If "second" is enough, 32bit are much longer than
"clock-tick" - which can be ATM "1000" in the Linux world (and I assume
that others will be there too sooner or later).

BTW I purposely ignore the "clock-tick" is - at least on Linux - a value
which can't be compiled in but need to be taken from
sysconf(_SC_CLK_TCK) at run-time - simply because that's irrelevant for
the above question/decision even if we decide to always scale timestamps
to "1/100 seconds" (or whatever) to make the life easier.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services



