[Olsr-dev] OLSRd 0.5.4 and 0.5.5 with ETT available
Thu Feb 21 13:22:11 CET 2008
> Jens Nachtigall wrote:
> > Hence, best way to do it is PacketPair atm, at least for a generic
> > routing daemon like olsrd that should be working independent of what's
> > below the IP layer.
> if your target OS does not support what *should* be around,
> then we could fallback to packet/pairing.
> or let me ask the question in a different way:
> if one OS in the wireless mesh does not support wireless APIs
> and cannot compute 'good' metrics, why should we squash the
> rest of the network to that lower limit.
With 'that lower limit' you mean 'use PacketPair'? And with 'squash'
you mean 'force'?
> actually i am more in favor of a reflection of this in the metric.
> if the target OS can do good airtime estimation (by means of
> reading out wireless stats) its offered links should be more
> attractive than a link offered by a system that needs to do
IMHO, PacketPair is just as much heuristics as ARF.
OLSR is designed as a pure layer 3 protocol. If we rely on
layer-2 information we might as well remove the complete HELLO
Is it ok to conclude that we *need* a PacketPair link metric
estimation (purely layer 3), and that we *would like* to use
any (other) information we can read out the radio layer, if
More information about the Olsr-dev