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
