Date: Mon, 25 Jul 2005 22:05:34 -0500 From: Sam Pierson <samuel.pierson@gmail.com> To: David Malone <dwmalone@maths.tcd.ie> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Atheros, hardware access layer, collisions Message-ID: <d9204e4c05072520052082b27@mail.gmail.com> In-Reply-To: <200507211647.aa79456@salmon.maths.tcd.ie> References: <d9204e4c050721062174d08e97@mail.gmail.com> <200507211647.aa79456@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
> OK - you can probably achieve that by setting the retry limit to > be 1, setting CWmin to be very small. However, you'll need to make > sure that both machines transmissions are synchronised to better > than 20us (which is no mean feat), otherwise carrier sense will > foil your plan! I just had a lengthy discussion with a couple of guys about the 802.11 protocol. One had said that the random delays inserted before=20 transmission was one of the *IFS delays (can't remember which now), and that it was a standard 802.11 number, not a random=20 delay. We all came to the same conclusion as this list, that we=20 have to set the transmission attempts to 1 and that CWmin must be very small (like 1). =20 The thing he said was that if carrier sensing "sensed" that the channel was busy, it would not decrement the CW, effectively NOT transmitting this packet until the channel is clear. =20 Is the carrier sensing something done in the HAL, or is it embedded in the hardware itself?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d9204e4c05072520052082b27>