Date: Wed, 27 Jul 2005 17:45:26 -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: <d9204e4c05072715452b4d9d9d@mail.gmail.com> In-Reply-To: <200507261513.aa10533@salmon.maths.tcd.ie> References: <d9204e4c05072520052082b27@mail.gmail.com> <200507261513.aa10533@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/26/05, David Malone <dwmalone@maths.tcd.ie> wrote: > That's correct, but it probably takes a few microseconds for the > carries sense to kick in (if there wasn't a delay there would > be almost no need for the random backoff). That's why you'll > also have to have your transmissions synchronised very closely. > David. Since my project is running in adhoc mode, I noticed that there is a LOT of noise being generated by the two machines I want to use in order to generate a collision. The noise is the adhoc beacon being broadcast. Clearly they need to talk to each other, but I'd really like to quiet down the channel so I can attempt this collision. I found this in if_ath: /* NB: the beacon interval is kept internally in TU's */ and this in /sys/contrib/dev/ath/ah_desc.h =09HAL_TX_QUEUE_BEACON=09=3D 2,=09=09/* beacon xmit q */ =09HAL_TX_QUEUE_CAB=09=3D 3,=09=09/* "crap after beacon" xmit q */ and... # cat ah.h | grep interval * beacon interval (given in TU's) can also include flags u_int32_t bs_intval; /* beacon interval+flags */ #define HAL_BEACON_PERIOD 0x0000ffff /* beacon interval period *= / I think the carrier sensing is kicking in because the channel is not quiet due to the beacons. Do the tx q things matter? seems like the=20 hal_beacon_period would be the most important line, but I don't see how that flag (if it is one) can be used. -Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d9204e4c05072715452b4d9d9d>