[Berlin-wireless] fftrace pre-release

Daniel Nitzpon nitzpon
Di Nov 21 00:02:24 CET 2006


hi!
wenn ich das richtig sehe, ist das, was die dort zählen, der 
erwartungswert an paketübertragungsversuchen _im_gesamten_netz_, was 
natürlich von der hopzahl abhängt, aber zur qualitätsbeurteilung im 
gegensatz zum routing weniger spannend ist.
summe stimmt dann aber auch nur, wenn eine übertragung bis ans ende der 
zeit weiter probiert wird und gleichzeitig kein retransmit auf ip-ebene 
ausgelöst wird.
produkt stimmt natürlich auch nicht, wenn man kurz drüber nachdenkt, 
denn die übertragung beginnt ja nicht komplett von vorne, wenn ein hop 
mal kurz nicht durchkommt.

scheint komplizierter zu werden, je länger man darüber nachdenkt, zumal 
ich mich mit den größenordnungen der zeitintervalle etc. nicht auskenne. 
falls der ip-retransmit bei noch laufendem 802.11er-übermittlungsversuch 
zu vernachlässigen ist, wäre vielleicht /sum_i(etx_i - 1) +1 ein gutes maß?!

lg, daniel


Horst Mäder schrieb:
> hallo Daniel,
> aus dem bauch raus seh ich das auch so (etx-produkt),
> aber ich hab mich auf:
> 
> http://www.olsr.org/docs/README-Link-Quality.html
> 
> bezogen.
> 
> 
> Daniel Nitzpon schrieb:
>> dazu noch eine frage/bitte/anregung:
>> "eigentlich", d.h. nach definition 
> hast du da eventuell was?
>> und vom sinn her ist der gesamt-etx 
>> ja ein produkt. jetzt kann man sich in diesem fall über die prioritäten 
>> streiten, aber mir persönlich wäre es hilfreicher, auf einen blick die 
>> echte verbindungsqualität zu sehen, also das produkt der einzel-etxe.
>> das kann natürlich irritierend wirken, wenn fftrace dann was anderes 
>> ausgespuckt als olsr
> wie kriege ich olsr dazu ein gesamt etx  auszuspucken?
>> , aber die summe von olsr ist hier eben nicht 
>> besonders aussagekräftig.
>>
>> lg, daniel
> ich bin offen für einsichten,
> also programmtechnisch ist es kein problem + gegen * auszutauschen, aber
> es soll etwas sinnbehaftetes da stehen.
> 
> so wie ich das verstanden, mir erklären lassen hab, ist es so, das ich
> _nicht_ solange pakete sende bis der endgültige empfänger die ankunft
> bestätigt - und sich damit die verluste multiplizieren, sondern mein
> nachbar kurz jeden paketempfang quittiert, tut er das nicht schicke ich
> solang weiter bis er es tut, theoretisch etx-mal, wenn der es hat
> kümmert er sich um seinen nächsten hop, ich bin aus dem schneider, und
> er schickt jedes paket solang bis sein nachbar sagt "hab ich", u.s.w..
> 
> dieser routen-etx am ende beschreibt dann die vorraussichtliche
> gesamtzahl der sendungen (retransmissions) die für ein paket von
> unterschiedlichen nodes geleistet werden müssen, damit es sein ziel
> erreicht. den hab ich mir nicht ausgedacht.
> 
> soweit zum ETX, bis mich jemand überzeugt das das anders sein muss
> (immer her!), lass ich den so.
> 
> nun könnte die prozentzahl wieder rein und diese dann ein produkt der
> einzel-verbindungs-qualitaten sein, (die ist idR erschreckend!), aber
> wenn das netz anders tickt (ich gar nicht z.B. 99.4% verliere), dann ist
> das doch nur eine hausnummer, oder?
> 
> also vorschläge für einen sinnvollen wert der einsichtig ist und die
> qualität einer route so beschreibt, das ich sie mit jeder anderen route
> vergleichen kann, eine kennzahl, nehm ich gern an und ins programm.
> 
> grüße hørst
> 
> _______________________________________________
> Berlin mailing list
> Berlin at olsrexperiment.de
> https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin
> 


_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin





Mehr Informationen über die Mailingliste Berlin