[net2-wg] 6/22/06 Meeting Transcript

[Kyle Jamieson]

Present: Rodrigo, Om, Kyle, Arslan, Martin, Sukun

R: we're fighting performance bugs; testing the collection code.  One 
main issue is low performance with infinite retxmit policy 
wo/backpressure was resulting in congestion.  Introduced max retxmits.

K: did retxmits switch parents before?

R: yes, but dropping after retxmits resulted in fewer packets in the net.

O: would make sense if we were sending a lot of packets, but we're 
sending at 0.1 Hz.

R: test was 1 node sending at 1 Hz, infinite retxmits.

K: and so the node is effectively transmitting at retxmit rate rather 
than 1 Hz.

R: path creates interference.  By bounding number of transmits, 
performance increased substantially.  Plus lack of backpressure.

O: we're seeing this problem even at 1 Hz.  Leads me to think maybe our 
beaconing rates are too high.  Else, why problems when we are sending at 
1 pps?

R: tested using MintRoute and Straw (Sukun), in same topology, MintRoute 
got @ 30 pps, 99% of packets at the base station, MicaZ platform.  Might 
be that link estimation is not so good.

O: MintRoute has e2e congestion control?

R: QueuedSend sends quite fast (immediately).  One thing Phil said was 
that maybe the timer to send a new packet was too long.  Other might be 
that beaconing rate is too high (once every 10 sec).  Noticed that 
success rate was 80%, but 30% of pkts received at the base station were 
duplicates.  So implemented dup suppression in FE, so you won't send the 
same packet twice.  So far the number of repeated packets was reduced to 6%.

K: why 6%?

R: race conditions, possibly.

K: count duplicates towards the success rate of 80%?

R: no.  In-network duplicates are like retxmits.  60% with duplicate 
suppression.  That's the status.

O: seeing 100% for nodes nearby, 2-5% for nodes far away.

R: decreasing steadily as number of hops decreased.

O: I think timer is causing bottleneck; shouldn't be losing so many 
packets when there is [inaudible].

R: cause of losses is when a node txmits 4x to its parent and doesn't 
get through.

R: rate at which MintRoute sends beacons?

S: 1 minute in our tests

R: 6x slower than us right now.

O: let's make it every 30 sec.

R: could even do a test in which we get MintRoute and hardcode the tree 
in our test and see what happens.  Tree in testbed -- each node has a 
set of 2-3 parents that it picks, generally constant.

O: Cache not compiling for other platforms.

R: we should probably create a cache that uses uint32_t.

O: Pin/unpin: problem earlier in the week was that we were evicting root 
or parent from nbr tbl, because node doesn't knw it's routing through 
them.  So would no longer have a parent.  So we added interfaces to link 
est. so you can pin a node and unpin.  So Router will immediately pin 
all routes and any parent.  When you switch to a new parent, router 
unpins previous parent and pins new parent.  So you have estimate for 
new parent always.  Whenever the link estimator evicts a node, it sends 
evicted signal to the router, and router was immediately inserting it back.

R: Foreful insert if you hear from a root.  If not in LE table, ask to 
forefully insert that node.

K: stable?

R: think more stable, but haven't measured it.

O: error messages for routing?

K: EBUSY bug from AM send.

R: let's look at MintRoute trees and see what we're doing differently.

O: one source test