[net2-wg] Collection

[Kyle Jamieson]

I think this is a sound debugging plan.  I'm working on points (1) and 
(3) right now, and also on including parent and metric information in 
the TestNetwork data packets that travel up the tree to the root.

The only other suggestion I have is to test collection independently of 
dissemination, just in case there's an unforeseen interaction between 
the two.  We might fall back on this if (1)-(3) below fail us...

Kyle

Philip Levis wrote:
> I see four major places that might be the cause of the problem. There 
> are two simple ways to start the diagnosis. The first is packet 
> sniffing: use a base station to see who is sending what (if at all). The 
> second is to use the LEDs in three specific circumstances.
> 
> 1) Queueing/buffer management: ForwardingEngineP is corrupting packets, 
> dropping packets, or otherwise preventing traffic from getting through.
>   - Instrument ForwardingEngineP to turn on Led0 when its message pool 
> is empty or its send queue is full and send an error message to the UART.
> 
> 2) Route selection/link estimation: The link estimation table is 
> oscillating wildly, leading to an unstable tree or there appear to be no 
> routes.
>   - Instrument TreeRoutingEngineP to turn on led1 when it has no route 
> and send a periodic message containing the parent ID to the UART. Send a 
> UART message whenever the parent changes.
> 
> 3) Loops in the routing tree are causing the network to saturate with 
> packets, false negatives acks are causing the number of packets in the 
> tree to increase greatly.
>   - Instrument ForwardingEngineP to count the number of retransmissions 
> it makes; if it goes beyond a small number (e.g., 4), send an error 
> message to the UART
> 
> Does anyone have additional hypotheses/tests?
> 
> Phil
> _______________________________________________
> net2-wg mailing list
> net2-wg at millennium.berkeley.edu
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/net2-wg