[olsr-dev] Question about implementation internals

[Andreas Tønnesen]

Hi,

Your question is an interesting one, and I'll have to look more
into the issue before deciding if it is something that should
be changed.
Quick answer to your bottom line question: yes and no. Message
generation is fired off by the scheduler which is just a endless loop
that sleeps for a certain pollrate at the end of every run. However, to
make the sleeptime more accurate a timestamp is fetched at the start and
stop of every scheduler poll and the (stop - start) interval is
subtraced from the pollinterval before calling nanosleep. So if the
system time was changed while the scheduler was polling this could have
a certain effect, but I guess what decides if this could have any real
effect is wheter the timestamp values are signed or not. But still -
fixing this should be a minor issue.
But when it comes to timeouts of registered entries there can be
problems. The entries in the various tables(linkset, topology etc.)
need to be very dynamic ie. they have to be polled for timeouts
very rapidly. Therefore, to avoid CPU hogging they use timestamps
that are compared to current time to decide validity. A change in
system time could AFAIK cause real trouble here.
One could ofcause consider using kernel uptime counters like
polling /proc/uptime or checking the return value of times etc. on
Linux - but then again that would break cross platform design.
I'll have do some poking around in the POSIX system calls... anyway,
I'll put it on my to-check-out list :)

- Andreas

Ignacio García Pérez wrote:
> Hi,
> 
> While setting up to diagnose a problem I'm experiencing in my network, a
> question arised:
> 
> How are the different timeouts implemented in OLSRD and how would a system
> time change affect?
> 
> I mean, for example in HELLOs. If timeout is implemented as a counter in
> each HELLO which is decremented periodically, and HELLOs are removed when
> this counter reach zero, no problem.
> 
> However, if, say, HELLOs are assigned a timeout time in the future, and this
> time is compared periodically to see if has been reached, and I move the
> system time back one day, I guess HELLOs will take a little more than one
> day to expire.
> 
> I faced this problem in another project. Just curious.
> 
> Nacho.
> 
> 
> 

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