> > I'm doing all my testing with ping -s to set the size of the packets. When > > I set packet sizes significantly higher than the MTU size I start getting > > lost packets. I was hoping that defragmentin the packets on node B will > > cause less collisions because all of the fragments will be received before > > transmission begins. > > Even if you could 'solve' this problem, I think ping is a rather artificial > way to test the setup if you're normally going to be using TCP for real > communications (which I assume will be the case).
Yeah, that's probably true. The network performance is acceptable as I guess TCP backs off the packet rate until fairly reliable communications occours. However, occasionaly I am getting long periods of no connectivity (sometime up to a couple of minutes or so). I'm not sure weather this is related to the collisions though. > TCP will overlap the packets, so A will send packet 1, then packet 2, then > packet 3, etc... whilst waiting for the acknowledgement of packet 1. It > won't send, wait for ack, send, wait for ack..... Therefore I think you'll > still run into the same problems as you're seeing now, which I also think are > due to collisions on the wireless network (because only one out of A, B and C > can transmit at any one time). > > How far apart are A, B and C - specifically A and C ? Can they pick up each > other's radio signals, or is it possible that A is talking to B, C can't tell > because it can't hear A, so C starts talking to B as well, and B loses > everything ? The nodes are actually quite far apart (I'm using high gain antennas and am actually getting around 50% signal strength). A is 1.2km from B and C is another 200m from B. B is at the top of a hill. A and C cannot reach each other directly (at least not with enough signal strength for a packet to pass through without error). A and C are also on different subnetworks. B routes packets between the two networks. Thanks for your comments, Russell
