[Olsr-dev] Poor routing performance

[Octav Chipara]

Hi,

A few questions/suggestions.

1) I understand the difficulties with managing routes. It seems to me that a
good engineering approach would be to define a range of IP addressed for
which OLSR will be doing the routing. This method will give you an
opportunity to have multiple routing algorithms managing different routes.

2) Does OLSR implementation cache routes within its own code? If not I
guess, it really is an issue to have writing to the routing table fail
because it could potentially impact the entire network as opposed to just
the local host. If it does do caching, can we simply keep a bool indicating
if the route update was performed correctly or not. Using this extra info,
you could actually reapply the change upon other route update or in the main
OLSR loop. This seems fairly os agnostic ...

If I enable a higher level of debugging, will I get the error codes for
writing to the socket? I guess one potentially issue is that I have VMWare
installed on my mac. It did add other interfaces, however, OLSR is
configured to ignore them.

Thanks,
-- Octav

On Wed, Nov 10, 2010 at 9:30 AM, Mitar <(spam-protected)> wrote:

> Hi!
>
> On Wed, Nov 10, 2010 at 5:54 PM, Markus Kittenberger
> <(spam-protected)> wrote:
> > i just pointet out, that the os-specific parts of olsrd`s routing code
> (that
> > lives inside the olsr_ioctl_add_route() ), can not use any infrastructure
> of
> > the os-unspecific olsrd-core at the moment to try it later,.. (it can
> only
> > try again immediately, but not later)
>
> I am not saying that it should be in os-unspecific part of the code.
> No, there is no need for that. It can be in os-specific part and just
> try again immediately.
>
> > but before thinking about this i would like to see a EAGAIN error,..
>
> Yes, EAGAIN is not so often and it depends on current configuration of
> file descriptor. EINTR is much more often (common?) if you use
> signals.
>
> > especially as there are no ioctl functions involved!
>
> But there is write function which at least in my page has:
>
> EAGAIN The file descriptor fd has been marked non-blocking
> (O_NONBLOCK) and the write would block.
>
> EINTR  The call was interrupted by a signal before any data was
> written; see signal(7).
>
> So, wrapping write calls to netlink socket in os-specific (Linux) part
> of code would not be so hard to add. But I agree, when there will be
> reason for that.
>
>
> Mitar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20101110/b5448607/attachment.html>