<font><font face="arial,helvetica,sans-serif">Ok, I think the same that Minimum Delay is not so good metric to measure link delay</font></font><div><font><font face="arial,helvetica,sans-serif">because you need to overhead the environment with probe packets.</font></font></div>
<div><font><font face="arial,helvetica,sans-serif">Moreover, I think such approach cause "damage" to layer-2 based</font></font></div><div><font><font face="arial,helvetica,sans-serif">on CSMA/CA adding more delay, and consequently, data packets</font></font></div>
<div><font><font face="arial,helvetica,sans-serif">are affected.<br clear="all"></font></font><br>And I think the manner how was implemented in ns-2 is not good</div><div>in my opinion, because it change the OLSR packet header</div>
<div>and the number of neighbor in HELLO packet is limited</div><div>or fixed to 4 neighbors always (that's I remember, if I not wrong). </div><div>Moreover, it hasn't any problem with float point in ns-2 environment</div>
<div>(without serialization), in other words, the clock time is "perfect"</div><div>in whole network. I think that problems will appear exactly in this point</div><div>in real environment, with clock.</div><div>
<br></div><div>Well, thank you very much for answers </div><div>and good work with OLSRv2. The modulated implementation</div><div>with plugins will help any research community to deploy new metric</div><div>easily.<br><br>
<div class="gmail_quote">On Mon, Jul 30, 2012 at 12:45 AM, Henning Rogge <span dir="ltr"><<a href="mailto:hrogge@googlemail.com" target="_blank">hrogge@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OLSRv2 defines no type of metric, it transports the metric as<br>
directional integer values in a compressed format (~ 1 - 2^24). You<br>
can implement any kind of metric you want with these values.<br>
<br>
I plan to put the metric generation completely into plugins, which<br>
will make it easy to deploy different kind of metrics.<br>
<br>
I would also like to have both an ETX and ETT metric, which will be<br>
compatible with each other (by allowing to set a fixed link speed for<br>
the ETX) and use the same range of numbers.<br>
<br>
Minimum delay is a bad metric in my opinion, because you cannot<br>
measure it well, it depends a lot on the number of packets in the<br>
outgoing queue.<br>
<br>
But if you can measure it, it should be very easy to use it.<br>
<span class="HOEnZb"><font color="#888888"><br>
Henning<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Sun, Jul 29, 2012 at 5:55 PM, scolfield <<a href="mailto:kscolfield@gmail.com">kscolfield@gmail.com</a>> wrote:<br>
> Thank you for answers.<br>
><br>
> It's truth that current OLSR version was prepared to use ETX<br>
> in the past and some modification on link quality calculation will<br>
> break the compatibility... and I'm bit curious about OLSRv2.<br>
><br>
> I think that link quality metrics based on ETX, at the implementation<br>
> level view, we "don't have much problems". I mean, in example,<br>
> the metric ML calculation method is very similar to ETX, in other<br>
> words, we can use the same HELLO and TC packets implemented<br>
> currently to provide ML metric.<br>
><br>
> I imagine that it is not possible to metrics based on link bandwidth<br>
> calculation like MD or ETT, where they use packet-pair probe to<br>
> measure the link quality.<br>
><br>
> The future OLSR version 2 will be able to "add" these metrics?<br>
> In other words, if the research community decide to implement<br>
> a new metric that use packet-pair probing technique, OLSRv2<br>
> will be prepared/modulated to add it? There is a preview<br>
> when it will be released?<br>
><br>
> And to finish, I would like know if you intend to provide<br>
> MD (minimum delay) metric as a standard metric or<br>
> as a optional metric (available to use).<br>
><br>
><br>
> On Sun, Jul 29, 2012 at 6:34 PM, Henning Rogge <<a href="mailto:hrogge@googlemail.com">hrogge@googlemail.com</a>><br>
> wrote:<br>
>><br>
>> Not completely right.<br>
>><br>
>> The main reason at the moment is that the packet encoding of Olsrd was<br>
>> designed specifically for ETX in the past, so we have to break<br>
>> compatibility for new metrics.<br>
>><br>
>> Thats why (at least from my side) we plan to introduce them with<br>
>> OLSRv2 (which I am working on at the moment) where we have to break<br>
>> compatibility anyway.<br>
>><br>
>> Breaking it twice in a row is bad.<br>
>><br>
>> Henning<br>
>><br>
>> On Sun, Jul 29, 2012 at 11:21 AM, ZioPRoTo (Saverio Proto)<br>
>> <<a href="mailto:zioproto@gmail.com">zioproto@gmail.com</a>> wrote:<br>
>> > I think the main reason why we don't use them is that the core<br>
>> > developers are all volunteers, and there is not enogh spare time to<br>
>> > implement everything.<br>
>> ><br>
>> > ciao,<br>
>> ><br>
>> > Saverio<br>
>> ><br>
>> ><br>
>> > 2012/7/29 scolfield <<a href="mailto:kscolfield@gmail.com">kscolfield@gmail.com</a>>:<br>
>> >> Hi everyone,<br>
>> >><br>
>> >> Maybe ETX link metric is the most known technique used to calculate<br>
>> >> or estimate link quality between to points. However, in the literature<br>
>> >> we can see any kind of link quality metric has proposed, such as<br>
>> >> ETT, ML, MD and other variation of ETX.<br>
>> >><br>
>> >> Such metrics has proposed and tested at the simulation level like ns-2<br>
>> >> and those works show us that such new metrics were better than ETX<br>
>> >> in multimedia environments.<br>
>> >><br>
>> >> So, I would like your opinions about these metrics. What do you think<br>
>> >> about it? Why don't use in the OLSR protocol?<br>
>> >><br>
>> >> My best thanks,<br>
>> >><br>
>> >> --<br>
>> >> Olsr-dev mailing list<br>
>> >> <a href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a><br>
>> >> <a href="https://lists.olsr.org/mailman/listinfo/olsr-dev" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-dev</a><br>
>> ><br>
>> > --<br>
>> > Olsr-dev mailing list<br>
>> > <a href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a><br>
>> > <a href="https://lists.olsr.org/mailman/listinfo/olsr-dev" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-dev</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Steven Hawkings about cosmic inflation: "An increase of billions of<br>
>> billions of percent in a tiny fraction of a second. Of course, that<br>
>> was before the present government."<br>
><br>
><br>
<br>
<br>
<br>
--<br>
Steven Hawkings about cosmic inflation: "An increase of billions of<br>
billions of percent in a tiny fraction of a second. Of course, that<br>
was before the present government."<br>
</div></div></blockquote></div><br></div>