Re: Atheros, hardware access layer, collisions
On 7/26/05, David Malone [EMAIL PROTECTED] 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 0x /* 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 [EMAIL PROTECTED]
Re: Atheros, hardware access layer, collisions
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 transmission was one of the *IFS delays (can't remember which now), and that it was a standard 802.11 number, not a random delay. Yep - in 802.11b CWmin is fixed at 32 and the random number is chosen between 0 and CWmin-1 (unless you have a collision). The recent Atheros cards support adjusting CWmin as part of their WME/802.11e support. 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. 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. Is the carrier sensing something done in the HAL, or is it embedded in the hardware itself? I'm afraid I don't know - Sam might. David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros, hardware access layer, collisions
David Malone wrote: 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 transmission was one of the *IFS delays (can't remember which now), and that it was a standard 802.11 number, not a random delay. Yep - in 802.11b CWmin is fixed at 32 and the random number is chosen between 0 and CWmin-1 (unless you have a collision). The recent Atheros cards support adjusting CWmin as part of their WME/802.11e support. Well recent is any 5212 or 5211 card so you're talking about any Atheros card except the 5210--which is not so recent. It may also be possible to program the 5210 but given how few of them are in use it's hardly worth the effort (and they'll never support WME). 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. 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. Is the carrier sensing something done in the HAL, or is it embedded in the hardware itself? I'm afraid I don't know - Sam might. Hardware. Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros, hardware access layer, collisions
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 transmission was one of the *IFS delays (can't remember which now), and that it was a standard 802.11 number, not a random delay. We all came to the same conclusion as this list, that we have to set the transmission attempts to 1 and that CWmin must be very small (like 1). 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. Is the carrier sensing something done in the HAL, or is it embedded in the hardware itself? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros, hardware access layer, collisions
You need to set cwmin on the tx q as David describes. Be sure to set the parameters you set into the hardware; check the wme update code for the correct logic. For the other thing just set the tx descriptor to do 1 try. Sam Thanks guys. I'm still playing with these files so I'll let you know how it goes, your answers have been very helpful. Is there a way to sniff control frames and/or detect collisions? This would help me out a lot and eliminate the guesswork that I've been doing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros, hardware access layer, collisions
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? David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros, hardware access layer, collisions
On 7/21/05, David Malone [EMAIL PROTECTED] 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. -Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros, hardware access layer, collisions
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. 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! David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros, hardware access layer, collisions
OK - you can probably achieve that by setting the retry limit to be 1, setting CWmin to be very small. I was looking for this in the ah.h and the ah_desc.h files. Are they someplace else, or maybe this is a system call? I can't find anything about the retry limit (-- CWmin = retry?) Thanks, Sam 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! David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros, hardware access layer, collisions
I was looking for this in the ah.h and the ah_desc.h files. Are they someplace else, or maybe this is a system call? I can't find anything about the retry limit (-- CWmin = retry?) Thanks, CWmin is a setting that controls the random delay before packets are transmitted. Search for tqi_cwmin in the driver. The retry limit says how many times the MAC should retry if it gets a collision while trying to transmit - I think it is controled by the tqi_shretry and tqi_lgretry values. In the driver in 6.X you can (in principle) set these values at the time the transmit queues are configured. David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros, hardware access layer, collisions
David Malone wrote: I was looking for this in the ah.h and the ah_desc.h files. Are they someplace else, or maybe this is a system call? I can't find anything about the retry limit (-- CWmin = retry?) Thanks, CWmin is a setting that controls the random delay before packets are transmitted. Search for tqi_cwmin in the driver. The retry limit says how many times the MAC should retry if it gets a collision while trying to transmit - I think it is controled by the tqi_shretry and tqi_lgretry values. In the driver in 6.X you can (in principle) set these values at the time the transmit queues are configured. You need to set cwmin on the tx q as David describes. Be sure to set the parameters you set into the hardware; check the wme update code for the correct logic. For the other thing just set the tx descriptor to do 1 try. Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Atheros, hardware access layer, collisions
Hey all,
I'm working on a project that requires creating a single packet
collision between hosts, so I've been digging around in
/sys/contrib/dev/ath for awhile now. I successfully disabled the
CTS and RTS control frames from being transmitted, which
was the first step. I believe now the application is sending
packets, creating a collision.
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. Can anyone help me
determine what I should zero out from the drivers? I'm not sure,
but these look like the important ones:
From ah.h (/contrib/dev/ath/)
#define CHANNEL_BUSY0x0004 /* Busy, occupied or overlap with adjoin chan */
(earlier in the file...)
typedef enum {
TXQ_FLAG_TXOKINT_ENABLE = 0x0001,/* enable TXOK interrupt */
TXQ_FLAG_TXERRINT_ENABLE= 0x0001,/* enable TXERR interrupt */
TXQ_FLAG_TXDESCINT_ENABLE = 0x0002,/* enable TXDESC interrupt */
TXQ_FLAG_TXEOLINT_ENABLE= 0x0004,/* enable TXEOL interrupt */
TXQ_FLAG_TXURNINT_ENABLE= 0x0008,/* enable TXURN interrupt */
TXQ_FLAG_BACKOFF_DISABLE= 0x0010,/* disable Post Backoff */
TXQ_FLAG_COMPRESSION_ENABLE = 0x0020,/* compression enabled */
TXQ_FLAG_RDYTIME_EXP_POLICY_ENABLE = 0x0040, /* enable ready time
expiry policy */
TXQ_FLAG_FRAG_BURST_BACKOFF_ENABLE = 0x0080, /* enable backoff while
sending fragment burst*/
} HAL_TX_QUEUE_FLAGS;
Does zeroing out frag_burst_backoff_enable do anything for me? I'm still
trying many configurations and recompiling this to my kernel is very time
consuming.
Thanks,
Sam
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
