don't force the graph to be called "batadv"

[nonchip]

you shouldn't name arbitrary graph data after a protocol you assume it could have been generated from

[tcatm]

The idea was to have multiple layers of graph data (i.e. batadv graph, wifi neighbours graph).

[nonchip]

ok, one sec

[nonchip]

better?

[tcatm]

I don't think routed mesh would be specific enough. batadv implies the tq to be present on links. What would routedmesh imply?

[nonchip]

well, there's an LQ in olsrd, which you could use similarly (but having a different value range).

[tcatm]

Maybe we should normalize the linkquality somehow and replace tq so it doesn't depend on the protocol anymore.

[nonchip]

then i'd actually suggest olsr's range: [0..1] (means "chance that a packet gets delivered", or 1-packetloss from a ping point of view)

[tcatm]

That might actually work. So someone needs to convert the existing batadv format first.

[nonchip]

shouldn't that just be clamp(0,1-(x/5),1)? according to gui.js you assume TQ to be 1(good) to 5(bad)

(with a hypothetical clamp function defined as:)

function clamp(min,val,max){
  if(val<min) return min;
  if(val>max) return max;
  return val;
}

don't know if JS already defines this, and too lazy to look it up :P

[tcatm]

Well, 5 doesn't mean "zero chance for packets to pass through". It just means that the packet would likely need to be sent 5 times on average.

[nonchip]

ok, so, having to send a packet ~5 times to get through means there's a 1:5 chance for it to get through, so then it should be even easier: LQ=1/TQ, right?

[tcatm]

Yes, that would work.