[ath5k-devel] Coverage Class troubles?
I'm trying to replace an existing 900MHz 11000 meter link w/ two Alix boxes with Ubiquiti XR9's. These are Atheros Communications Inc. AR5413 802.11abg NIC (rev 01) radios that down convert to the 900MHz ISM band. I'm using a 5MHz channel. The units run flawlessly at short distances, but repeatedly connect and drop out at 11000 meters. As the current link's signal is 6dB over noise, I've discounted signal strength as the problem. My spec analyzer says the part of the band I'm using is fairly quiet and that the bandwidth of the radios is 5MHz. So, that leaves coverage class. Without the knowledge to verify the coverage class logic, I compared the values of the IFS_SIFS, IFS_SLOT, IFS_EIFS, IFS_MISC and TIME_OUT registers for various values of coverage class with the closed hal madwifi r3314. I used a 20MHz channel. The comparisons are attached. Given the same coverage class, the values are quite different between the two drivers. I also collected the register values for various coverage classes for ath5k using a 5MHz channel. The madwifi driver doesn't do 5MHz channels. The value computed for SIFS_DUR_USEC is 0x40 which is larger than the mask for that field (0x3f) in IFS_MISC. So that computation is suspect. Also, the ack/cts timeout values don't get changed from the default values to the 5MHz values unless a set coverage class command is issued. I've attached that collection as well. I'm not sure where to go from here. Steve compat-wireless-2011-03-11 ath5k As loaded (20MHz bandwidth) ath5k_hw_set_ifs_intervals SIFS:352(0x160) SLOT:396(0x18c) EIFS:14960(0x3a70) SIFS_DUR_USEC:8(0x8) AR5K_DCU_GBL_IFS_SIFS (0x1030) 0x0160 AR5K_DCU_GBL_IFS_SLOT (0x1070) 0x018c AR5K_DCU_GBL_IFS_EIFS (0x10b0) 0x3a70 AR5K_DCU_GBL_IFS_MISC (0x10f0) 0xb080 AR5K_TIME_OUT (0x8014) 0x08400840 iw phy0 set coverage 0 ath5k_hw_set_ifs_intervals SIFS:352(0x160) SLOT:396(0x18c) EIFS:14960(0x3a70) SIFS_DUR_USEC:8(0x8) ath5k_hw_set_ack_timeout ACK:748(0x2ec) ath5k_hw_set_cts_timeout CTS:748(0x2ec) AR5K_DCU_GBL_IFS_SIFS (0x1030) 0x0160 AR5K_DCU_GBL_IFS_SLOT (0x1070) 0x018c AR5K_DCU_GBL_IFS_EIFS (0x10b0) 0x3a70 AR5K_DCU_GBL_IFS_MISC (0x10f0) 0xb080 AR5K_TIME_OUT (0x8014) 0x02ec02ec iw phy0 set coverage 1 ath5k_hw_set_ifs_intervals SIFS:352(0x160) SLOT:528(0x210) EIFS:15224(0x3b78) SIFS_DUR_USEC:8(0x8) ath5k_hw_set_ack_timeout ACK:880(0x370) ath5k_hw_set_cts_timeout CTS:880(0x370) AR5K_DCU_GBL_IFS_SIFS (0x1030) 0x0160 AR5K_DCU_GBL_IFS_SLOT (0x1070) 0x0210 AR5K_DCU_GBL_IFS_EIFS (0x10b0) 0x3b78 AR5K_DCU_GBL_IFS_MISC (0x10f0) 0xb080 AR5K_TIME_OUT (0x8014) 0x03700370 iw phy0 set coverage 0 ath5k_hw_set_ifs_intervals SIFS:352(0x160) SLOT:396(0x18c) EIFS:14960(0x3a70) SIFS_DUR_USEC:8(0x8) ath5k_hw_set_ack_timeout ACK:748(0x2ec) ath5k_hw_set_cts_timeout CTS:748(0x2ec) AR5K_DCU_GBL_IFS_SIFS (0x1030) 0x0160 AR5K_DCU_GBL_IFS_SLOT (0x1070) 0x018c AR5K_DCU_GBL_IFS_EIFS (0x10b0) 0x3a70 AR5K_DCU_GBL_IFS_MISC (0x10f0) 0xb080 AR5K_TIME_OUT (0x8014) 0x02ec02ec And after a few minutes, ack/cts timeouts revert to: Note that there are no calls to set_ack_timeout or set_cts_timeout. Maybe a call to hw_reset? AR5K_DCU_GBL_IFS_SIFS (0x1030) 0x0160 AR5K_DCU_GBL_IFS_SLOT (0x1070) 0x018c AR5K_DCU_GBL_IFS_EIFS (0x10b0) 0x3a70 AR5K_DCU_GBL_IFS_MISC (0x10f0) 0xb080 AR5K_TIME_OUT (0x8014) 0x08400840 iw phy0 set coverage 1 ath5k_hw_set_ifs_intervals SIFS:352(0x160) SLOT:528(0x210) EIFS:15224(0x3b78) SIFS_DUR_USEC:8(0x8) ath5k_hw_set_ack_timeout ACK:880(0x370) ath5k_hw_set_cts_timeout CTS:880(0x370) AR5K_DCU_GBL_IFS_SIFS (0x1030) 0x0160 AR5K_DCU_GBL_IFS_SLOT
Re: [ath5k-devel] Coverage Class troubles?
On Mon, Mar 21, 2011 at 1:45 PM, Steve Brown sbr...@cortland.com wrote: I'm trying to replace an existing 900MHz 11000 meter link w/ two Alix boxes with Ubiquiti XR9's. These are Atheros Communications Inc. AR5413 802.11abg NIC (rev 01) radios that down convert to the 900MHz ISM band. I'm using a 5MHz channel. The units run flawlessly at short distances, but repeatedly connect and drop out at 11000 meters. As the current link's signal is 6dB over noise, I've discounted signal strength as the problem. My spec analyzer says the part of the band I'm using is fairly quiet and that the bandwidth of the radios is 5MHz. So, that leaves coverage class. Without the knowledge to verify the coverage class logic, I compared the values of the IFS_SIFS, IFS_SLOT, IFS_EIFS, IFS_MISC and TIME_OUT registers for various values of coverage class with the closed hal madwifi r3314. I used a 20MHz channel. The comparisons are attached. Given the same coverage class, the values are quite different between the two drivers. I also collected the register values for various coverage classes for ath5k using a 5MHz channel. The madwifi driver doesn't do 5MHz channels. The value computed for SIFS_DUR_USEC is 0x40 which is larger than the mask for that field (0x3f) in IFS_MISC. So that computation is suspect. Also, the ack/cts timeout values don't get changed from the default values to the 5MHz values unless a set coverage class command is issued. I've attached that collection as well. I'm not sure where to go from here. Steve That sounds to me like signal strength could indeed be your problem. At 5MHz channel width, you should be restricted to OFDM, and the drivers typically want to give up on OFDM once signal strength dips below 7dB. -Brian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Coverage Class troubles?
This is just my off-the-morning-coffee calculation without (yet) having any experience with the coverage class parameters, but: * light travels roughly 300m/microsecond sec; * means you're going to travel 36.6 microseconds for 11,000 metres, so call it 37 microseconds. * the AR_D_GBL_IFS_MISC_SIFS_DURATION_USEC field is yes, mask 0x3f which gives it a total value of 63 microseconds. Turbo mode fiddles with the clocks-per-usec parameters, but the SIFS duration above is in microseconds, not core clocks. Not changing the ACK/CTS timeout values (which -are- in core clocks) when turbo or XR mode is engaged is also likely a bug; would the person who recently committed the speed changes please stand up and review these, like I suggested when the patch first came out? :) Thanks for reminding me that I should fix this in my own tree, btw. :) Adrian On 22 March 2011 01:45, Steve Brown sbr...@cortland.com wrote: I'm trying to replace an existing 900MHz 11000 meter link w/ two Alix boxes with Ubiquiti XR9's. These are Atheros Communications Inc. AR5413 802.11abg NIC (rev 01) radios that down convert to the 900MHz ISM band. I'm using a 5MHz channel. The units run flawlessly at short distances, but repeatedly connect and drop out at 11000 meters. As the current link's signal is 6dB over noise, I've discounted signal strength as the problem. My spec analyzer says the part of the band I'm using is fairly quiet and that the bandwidth of the radios is 5MHz. So, that leaves coverage class. Without the knowledge to verify the coverage class logic, I compared the values of the IFS_SIFS, IFS_SLOT, IFS_EIFS, IFS_MISC and TIME_OUT registers for various values of coverage class with the closed hal madwifi r3314. I used a 20MHz channel. The comparisons are attached. Given the same coverage class, the values are quite different between the two drivers. I also collected the register values for various coverage classes for ath5k using a 5MHz channel. The madwifi driver doesn't do 5MHz channels. The value computed for SIFS_DUR_USEC is 0x40 which is larger than the mask for that field (0x3f) in IFS_MISC. So that computation is suspect. Also, the ack/cts timeout values don't get changed from the default values to the 5MHz values unless a set coverage class command is issued. I've attached that collection as well. I'm not sure where to go from here. Steve ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
