[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: Atheros, hardware access layer, collisions
From:       Sam Pierson <samuel.pierson () gmail ! com>
Date:       2005-07-27 22:45:26
Message-ID: d9204e4c05072715452b4d9d9d () mail ! gmail ! com
[Download RAW message or body]

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
	HAL_TX_QUEUE_BEACON	= 2,		/* beacon xmit q */
	HAL_TX_QUEUE_CAB	= 3,		/* "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 
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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

[prev in list] [next in list] [prev in thread] [next in thread]