[olsr-dev] Question about implementation internals

[Andreas Tønnesen]

Ok, I'm back indoors :)
I just did some testing on the times(2) call, and to me it seems to
be a possible way of solving the discussed problems with system time
changes.
I created a little program that printf the returnvalue of
(times(2) / sysconf(_SC_CLK_TCK)) and runs "date" every second.
Then I ran this program and changed the system clock a couple of times.
The output shows that the returnvalue of times(2) do not change while
the printout from "date" does:

Uptime(times(2)): 4296731
system("date"):Sun Jan 16 17:08:18 CET 2005
Uptime(times(2)): 4296732
system("date"):Sun Jan 16 17:08:19 CET 2005
Uptime(times(2)): 4296733
system("date"):Sun Jan 16 17:09:18 CET 2005 <- set system time +1 minute
Uptime(times(2)): 4296734
system("date"):Sun Jan 16 17:09:19 CET 2005
Uptime(times(2)): 4296735
system("date"):Sun Jan 16 17:09:20 CET 2005
Uptime(times(2)): 4296736
.......
Uptime(times(2)): 4296746
system("date"):Sun Jan 16 17:09:31 CET 2005
Uptime(times(2)): 4296747
system("date"):Sun Jan 16 17:09:32 CET 2005
Uptime(times(2)): 4296748
system("date"):Sun Jan 16 17:08:31 CET 2005 <- set system time -1 minute
Uptime(times(2)): 4296749
system("date"):Sun Jan 16 17:08:32 CET 2005
Uptime(times(2)): 4296750
system("date"):Sun Jan 16 17:08:33 CET 2005
Uptime(times(2)): 4296751
system("date"):Sun Jan 16 17:08:34 CET 2005

So this gives us a much more reliable timesource. But then there is the
question of resolution. This seems to be system dependent, I checked the
returnvalue of sysconf(_SC_CLK_TCK) on a couple of i386 Linux systems
and as expected they both return 100(the Linux kernel pulls off ticks
at a 10ms rate on i386 systems AFAIK). For olsrd this is way more then
enough, I think a resolution even down to tenths of seconds will actualy
be acceptable in our case(the scheduler by default polls every 0.2
second).

I think I'll change to use times(2) return values for database
timeouts - that is if it seems to work ok on win32 and there are no
obvious reasons not to do this.

- Andreas

-- 
Andreas Tønnesen
http://www.olsr.org