<br><div class="gmail_quote">On Tue, Feb 10, 2009 at 4:23 PM, Henning Rogge <span dir="ltr"><<a href="mailto:rogge@fgan.de">rogge@fgan.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
><br>
> but unicast loss behaves for sure not linear to broadcast_loss or<br>
> netto_bandwidth!!<br>
> of course having the number of failed retransmission would be the best, and<br>
> i think this values is available from maclayer,..<br>
> this would imho be the only perfect solution, ...<br>
<br>
Just divide the througput from the ratecontrol algorithm by the unicast<br>
transmission rate. If you get 1.0 there is no unicast retransmissions, if you<br>
have 0.5 you have one retransmission for each packet. This could be a<br>
measurement for delay (because waiting times for retransmissions).</blockquote><div>is it really that easy? </div><div></div><div>what is the influence of noise on netto-rate?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<div class="Ih2E3d"><br>
><br>
> there will always be interfaces where you will not be able to detect it,..<br>
> but one way out of this dilemma is just to detect unicast loss with test<br>
> packets, at least when we can`t detect it from maclayer<br>
</div>See above. No need to guess this parameter.</blockquote><div>im not sure, </div><div></div><div>cause if we don`t want to measure, where we can`t get it from maclayer, we may wanna guess it,.. *g<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The only interesting additional<br>
value might be the total number of failed transmissions (failed for layer 3,</blockquote><div>ACK this value is interesting if we can get it,<br>but if we wanna use it (i WANT *g), we may need substitute whre we can`t get it from maclayer,..<br>
</div><div></div><div>Markus</div></div>