Atheros, hardware access layer, collisions
samuel.pierson at gmail.com
Thu Jul 21 13:22:25 GMT 2005
On 7/21/05, David Malone <dwmalone at maths.tcd.ie> wrote:
> On Wed, Jul 20, 2005 at 10:03:49PM -0500, Sam Pierson wrote:
> > I think there is still collision detection happening on the hardware
> > level. I think I have to disable the retransmission of frames
> > which are lost due to collisions. Here's my reasoning: In the lab, two
> > hosts are sending packets to the middle guy at the same time.
> > After examining the traffic on the middle guy, one packet will
> > arrive before the other one (sometimes in different order) and
> > the second packet comes 500-1200us after the first. From this,
> > I think some retransmission is happening because of collision,
> > since the results are seemingly random.
> Since introducing random delays before transmission and using carrier
> sensing are basic features of the 802.11 MAC, I'd be suprised if
> you can stop the hardware doing it. To reduce the effects as much
> as possible, you could try trying to reduce the number of retransmission
> attempts and changing the cwmin parameter to be small. Even if you
> do this, you'll still need to transmit the packets quite close to
> one another (probably within 20us) to avoid the carrier sense stuff
> kicking in.
> What effect are you trying to achieve?
I've got two computers synchronized to send one packet each to this
machine sitting between them. This machine responds with a packet
to each that it receives (on the application level, not in the control frame
space), so if there is a collision, I don't want the middle machine to
respond and I don't want the senders to retransmit when they don't
receive an ACK control frame after they send their data packet (again,
this packet is up on the transport layer, so more control frames might
be sent). Normal operation (regular connectivity) is not needed on the
two senders, so screwing up their retransmission scheme isn't a problem.
More information about the freebsd-hackers