Re: Port of bcm43xx from softmac to mac80211 is available for testing
On Wednesday 08 August 2007 22:49:17 you wrote: Richard Jonsson wrote: On Monday 06 August 2007 03:21:11 you wrote: Richard Jonsson wrote: Isn't Desired TX power supposed to adapt so that higher bitrates are possible, with Bit Rate going lower if that is not enough to keep a good connection? Richard, Please grab a new copy of the port_to_mac80211 patch, and try the patch below. It boosts the desired power by up to 5 dBm as signal - noise decreases from 20 to 0. Larry Hard to say if there is a difference. I've noticed that signal quality changes between reboots. When I first tried this patch I couldn't get above 36M even at the AP, so I loaded the version without the patch. Same thing. So I rebooted and then all rates worked, even 11M. Even for the driver version that didn't work a few days ago. That is scary! That may mean that something is not being reset. The real question is whether warm reboots are intrinsically different than cold (power-off) reboots. I've power cycled between reboots, unsure if I would get the same results on a soft reset. New/updated observations: Rate scaling seems to work, but if it gets down to 1M it will not rise again unless I force it to a higher bitrate and run iperf for a few seconds before setting it to auto. This is even when signal is -5dBm and noise is -80dBm. I get a feeling it's a bit to sensitive as it will drop quickly at a few meters away. At this distance forced 54M still works well. Maybe this is due to small dips (0.5sec) in traffic flow?! I'm surprised that you get signal values as high as -5 dBm. My maximum is about -35. I'm usually in the -40 range, even at 2 m from the AP. That -5dBm signal is best case when AP's antenna is a few cm from the computers lid. In this position it often reads between -15 - -20dBm. If I move just a cm further away it drops to -30dBm which gradually decreases with distance. With the patch applied power is reported as 27dB in debugfs. With debug_xmitpower dmesg reports desired power to be 16.5 and actual 16.25. This is max when I manually set power through debugfs. After a while it's down to 10dB, even though only 1M works where I sit. Range seems to be higher for B-rates. Maybe this is just how things are, I lack experience. The CCCK (B) encoding is much different than OFDM (G) transmissions. I would not be surprised to learn that its range were longer. The power setting that comes from mac80211 is 27 dBm, which is completely bogus for what is supposed to be the FCC table. The regulatory limit is 20 dBm EIRP (a fancy acronym that means take the antenna into account). I've sent a fix for comment, but as is the usual case for mac80211, it will take several days or weeks to get a response. The maximum power that a bcm43xx device can use is encoded in the sprom. For most of them that quantity is 18.5 dBm, corresponding to the regulatory limit of 20 minus a safety factor of 1.5. I think that is there to prevent setting the power too high and flunking the certification tests. The output that goes to the radio is thus 18.5 less the gain of the antenna, which is also in the sprom with a usual value of 2 dBm. That is why you see the code setting a Desired power of 16.5 dBm. I see! I expected it to go to 18dBm. Initially, I thought that the performance of my BCM4311 fell off as the power increased; however, that no longer happens. As a result, we can push full power at all times and there seems to be no need to use the kind of algorithm that you were testing. Don't tell the FCC, but we could relax IMHO there should eventually be some power scaling, as I understand wlan takes a fair amount of power. Ideally there should be different modes (powersave, performance) preferrably as an API common to all networking, at least wireless. Getting offtopic, just a thought. that upper power limit as we will never try to get the device certified, but then we would use extra power, and run the risk of burning out the radio. If you decide to do that, please tell me the power setting at which it fried! Heh, I might have tried if it was a usb stick ;) Since it's usable and since I got 54M/36M rate under no/high load in winxp under the same circumstances I believe power output is sufficient. With the patches that were pushed into wireless-dev a few minutes ago, I suggest that you try bcm43xx-mac80211. It is getting at least as good, if not better, performance than the BCM4301 or the softmac port to mac80211 drivers do. We would also appreciate as much testing as possible as it will help getting it merged into mainstream. That driver will require V4 firmware. Thanks for your report, Larry Sure, I'll do that. Where do I get a current source? By git? (I forgot to add the mailinglist in the original mail, sorry) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de
Re: Port of bcm43xx from softmac to mac80211 is available for testing
On Monday 06 August 2007 03:21:11 you wrote: Richard Jonsson wrote: Isn't Desired TX power supposed to adapt so that higher bitrates are possible, with Bit Rate going lower if that is not enough to keep a good connection? Richard, Please grab a new copy of the port_to_mac80211 patch, and try the patch below. It boosts the desired power by up to 5 dBm as signal - noise decreases from 20 to 0. Larry Hard to say if there is a difference. I've noticed that signal quality changes between reboots. When I first tried this patch I couldn't get above 36M even at the AP, so I loaded the version without the patch. Same thing. So I rebooted and then all rates worked, even 11M. Even for the driver version that didn't work a few days ago. New/updated observations: Rate scaling seems to work, but if it gets down to 1M it will not rise again unless I force it to a higher bitrate and run iperf for a few seconds before setting it to auto. This is even when signal is -5dBm and noise is -80dBm. I get a feeling it's a bit to sensitive as it will drop quickly at a few meters away. At this distance forced 54M still works well. Maybe this is due to small dips (0.5sec) in traffic flow?! With the patch applied power is reported as 27dB in debugfs. With debug_xmitpower dmesg reports desired power to be 16.5 and actual 16.25. This is max when I manually set power through debugfs. After a while it's down to 10dB, even though only 1M works where I sit. Range seems to be higher for B-rates. Maybe this is just how things are, I lack experience. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
Richard Jonsson wrote: On Monday 06 August 2007 03:21:11 you wrote: Richard Jonsson wrote: Isn't Desired TX power supposed to adapt so that higher bitrates are possible, with Bit Rate going lower if that is not enough to keep a good connection? Richard, Please grab a new copy of the port_to_mac80211 patch, and try the patch below. It boosts the desired power by up to 5 dBm as signal - noise decreases from 20 to 0. Larry Hard to say if there is a difference. I've noticed that signal quality changes between reboots. When I first tried this patch I couldn't get above 36M even at the AP, so I loaded the version without the patch. Same thing. So I rebooted and then all rates worked, even 11M. Even for the driver version that didn't work a few days ago. That is scary! That may mean that something is not being reset. The real question is whether warm reboots are intrinsically different than cold (power-off) reboots. New/updated observations: Rate scaling seems to work, but if it gets down to 1M it will not rise again unless I force it to a higher bitrate and run iperf for a few seconds before setting it to auto. This is even when signal is -5dBm and noise is -80dBm. I get a feeling it's a bit to sensitive as it will drop quickly at a few meters away. At this distance forced 54M still works well. Maybe this is due to small dips (0.5sec) in traffic flow?! I'm surprised that you get signal values as high as -5 dBm. My maximum is about -35. I'm usually in the -40 range, even at 2 m from the AP. With the patch applied power is reported as 27dB in debugfs. With debug_xmitpower dmesg reports desired power to be 16.5 and actual 16.25. This is max when I manually set power through debugfs. After a while it's down to 10dB, even though only 1M works where I sit. Range seems to be higher for B-rates. Maybe this is just how things are, I lack experience. The CCCK (B) encoding is much different than OFDM (G) transmissions. I would not be surprised to learn that its range were longer. The power setting that comes from mac80211 is 27 dBm, which is completely bogus for what is supposed to be the FCC table. The regulatory limit is 20 dBm EIRP (a fancy acronym that means take the antenna into account). I've sent a fix for comment, but as is the usual case for mac80211, it will take several days or weeks to get a response. The maximum power that a bcm43xx device can use is encoded in the sprom. For most of them that quantity is 18.5 dBm, corresponding to the regulatory limit of 20 minus a safety factor of 1.5. I think that is there to prevent setting the power too high and flunking the certification tests. The output that goes to the radio is thus 18.5 less the gain of the antenna, which is also in the sprom with a usual value of 2 dBm. That is why you see the code setting a Desired power of 16.5 dBm. Initially, I thought that the performance of my BCM4311 fell off as the power increased; however, that no longer happens. As a result, we can push full power at all times and there seems to be no need to use the kind of algorithm that you were testing. Don't tell the FCC, but we could relax that upper power limit as we will never try to get the device certified, but then we would use extra power, and run the risk of burning out the radio. If you decide to do that, please tell me the power setting at which it fried! With the patches that were pushed into wireless-dev a few minutes ago, I suggest that you try bcm43xx-mac80211. It is getting at least as good, if not better, performance than the BCM4301 or the softmac port to mac80211 drivers do. We would also appreciate as much testing as possible as it will help getting it merged into mainstream. That driver will require V4 firmware. Thanks for your report, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
On Sunday 05 August 2007 23:11:33 you wrote: Richard Jonsson wrote: Isn't Desired TX power supposed to adapt so that higher bitrates are possible, with Bit Rate going lower if that is not enough to keep a good connection? It should, but this feature is not yet implemented. I have some test code to do this, but it is not ready. When it is, I'll send you a trial patch. Check if your system has a file names /sys/kernel/debug/bcm43xx/phyX/power_level. If it does, you can write new values for the Desired power into it. Values up to 18 are allowed. I see, and thank you for the tip. I thought power_level was read-only. 11M mode is unusable at all distances, 12M works fine. This probably breaks rate scaling for me. Yes, it certainly would. My 4311 shows a little dip at 11 Mbs, but not as big as yours. Is your AP using b/g mode, or just g mode? What is the make and model of the AP? It's a netgear wgt634u, most recent stable firmware, configured for B/G. rmmod bcm43xx when kde is running hangs rmmod and prevents a clean shutdown. I tried to find which program causes this while using bcm4301 driver, but so far no luck. System shuts down fine if I don't try to rmmod first. rmmod works fine from runlevel 3 aside from this message when inserting module again: net eth1: device_rename: sysfs_create_symlink failed (-17) On my system, I routinely unload the module using 'modprobe -r bcm43xx'. Sometimes, it happens 20 or 30 times between reboots. These are always at runlevel 5. Only once or twice has it not completed. Are you using NetworkManager or using the traditional ifup/ifdown methods? Networkmanager+knetworkmanager. killing these before rmmod doesn't help. Nitpicking: When changing bitrate manually it will not show up with iwconfig before any traffic has occured. This is a mac80211 problem. My original version of the patch that implemented the set rate function loaded the new rate so that it would show up immediately, but that part was nixed. Complain on [EMAIL PROTECTED] Maybe I will. It's not that big of an issue, but still confusing for those unknowing. Sometimes iwconfig link quality shows values in the whole 0-255 range. Do the Signal and Noise levels show -256 dBm at the same time? If so, mac80211 has not received any data. Sometimes signal fluctuates at the same time, noise is pretty much always around -70dBm. I can't recall I've seen it show -256 for this driver. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
On Sunday 05 August 2007 01:26:52 Larry Finger wrote: The port of bcm43xx from softmac to mac80211 is available for testing. There are two patch sets that can be downloaded from ftp://lwfinger.dynalias.org/patches and be applied to kernel 2.6.23-rc1 or -rc2, the mainstream git tree (Linus's), and Linville's wireless-2.6 git tree. The two files are ftp://lwfinger.dynalias.org/patches/SSB_Final, which installs the SSB driver, and ftp://lwfinger.dynalias.org/patches/port_to_mac80211, which has the changes for the bcm43xx driver. The resulting driver will use V3 firmware. These patches are similar to the 4301 test driver that was circulated earlier. The major change is that the earlier version was trying to set the power too low. Once that was fixed, performance has become quite good, as shown below. I'm still working on the power setup, which may help the BCM4306. Transker rates (xmit/recv in Mbs), obtained by using an Iperf server on my LAN Bit Rate BCM4311 BCM4318 BCM4306 set (Mbs) 1 1.17/8.66 1.22/9.39 1.22/3.73 2 1.96/11.2 1.98/12.5 1.90/4.98 5.5 4.15/17.7 4.19/17.7 3.98/5.09 6 4.86/17.3 4.86/19.9 2.66/4.94 9 6.58/17.7 6.56/19.9 3.26/5.01 116.57/14.2 6.54/18.5 6.07/5.20 1810.7/19.6 10.7/20.2 4.74/5.05 2412.6/19.6 12.8/20.0 4.12/5.34 3616.2/20.1 15.9/20.1 4.76/4.90 4817.9/20.0 15.1/19.6 3.70/4.18 5419.0/19.8 15.1/20.0 1.83/2.64 These results look rather good for the later models - my BCM4306 has a PHY rev of 1. On this version, much more is required in the PHY setup, and we clearly have more work for that device. Please let me know of any problems in applying the patches, or any oops's that occur. Larry I have tried these patches on 2.6.23-rc2 and find perceived performance to be about the same as for the bcm4301 mac80211 driver. I use this script to stresstest the connection: iperf -c 192.168.0.1 -t 3600 /dev/null watch --interval .1 dmesg|grep phy[0-9]|tail -n1 \ ifconfig eth1 \ iwconfig eth1 21 iwconfig: eth1 IEEE 802.11g ESSID:NETGEAR Mode:Managed Frequency:2.442 GHz Access Point: 00:0F:B5:3D:4B:E2 Bit Rate=2 Mb/s Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:off Link Quality=65/100 Signal level=-60 dBm Noise level=-70 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 dmesg|grep TX power [ 755.816434] bcm43xx-phy0 debug: Current TX power output: 10.25 dBm, Desired TX power output: 10.0 dBm [ 763.339286] bcm43xx-phy0 debug: Current TX power output: 9.0 dBm, Desired TX power output: 10.0 dBm [ 770.840137] bcm43xx-phy0 debug: Current TX power output: 10.50 dBm, Desired TX power output: 10.0 dBm [ 778.343126] bcm43xx-phy0 debug: Current TX power output: 9.0 dBm, Desired TX power output: 10.0 dBm [ 785.842109] bcm43xx-phy0 debug: Current TX power output: 10.50 dBm, Desired TX power output: 10.0 dBm [ 793.347213] bcm43xx-phy0 debug: Current TX power output: 10.25 dBm, Desired TX power output: 10.0 dBm Isn't Desired TX power supposed to adapt so that higher bitrates are possible, with Bit Rate going lower if that is not enough to keep a good connection? When next to AP I get 54Mbps when connection is idle or has low utilisation, but when running iperf the Bit rate instantly changes to 1Mbps. While running iperf it jumps between 1, 2, 5.5 and 11Mbps. When manually setting it to 54M it will work with good thoughput. I think it fails at 11M and starts over from 1 again. Performance next to AP (iperf -c 192.168.0.1): 1M 721K 2M 1.64M 5.5M3.72M 6M 5.66M 9M 7.62M 11M --- 12M 9.28M 18M 11.9M 24M 14.0M 36M 17.2M 48M 18.5M 54M 18.4M auto451K When 10 meters away from AP anything higher than 5.5 is unusable, often 5.5M too. 11M mode is unusable at all distances, 12M works fine. This probably breaks rate scaling for me. rmmod bcm43xx when kde is running hangs rmmod and prevents a clean shutdown. I tried to find which program causes this while using bcm4301 driver, but so far no luck. System shuts down fine if I don't try to rmmod first. rmmod works fine from runlevel 3 aside from this message when inserting module again: net eth1: device_rename: sysfs_create_symlink failed (-17) Nitpicking: When changing bitrate manually it will not show up with iwconfig before any traffic has occured. Sometimes iwconfig link quality shows values in the whole 0-255 range. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
Richard Jonsson wrote: rmmod bcm43xx when kde is running hangs rmmod and prevents a clean shutdown. I tried to find which program causes this while using bcm4301 driver, but so far no luck. System shuts down fine if I don't try to rmmod first. rmmod works fine from runlevel 3 aside from this message when inserting module again: net eth1: device_rename: sysfs_create_symlink failed (-17) I just got one of these during bootup, which prevented bcm43xx from starting correctly. The logged sequence was: kernel: bcm43xx-phy1: Broadcom 4311 WLAN found kernel: ssb: Switching to IEEE 802.11 core, index 1 kernel: bcm43xx-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8 kernel: bcm43xx-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 kernel: bcm43xx-phy1 debug: Radio turned off kernel: wmaster0: Selected rate control algorithm 'simple' ifup: Service network not started and mode 'auto' - skipping kernel: net eth1: device_rename: sysfs_create_symlink failed (-17) ifup: Network interface is managed from NetworkManager ifup: NetworkManager will be advised to set up eth1 ifup: but it cannot be assured from here. kernel: bcm43xx-phy1 debug: Adding Interface type 2 kernel: ssb: Switching to PCI-E core, index 3 kernel: ssb: Switching to IEEE 802.11 core, index 1 kernel: bcm43xx-phy1: bcm43xx: Microcode bcm43xx_microcode5.fw3.fw loaded The fix for this was to 'modprobe -r bcm43xx' followed by 'modprobe bcm43xx', which got everything started OK. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
Richard Jonsson wrote:
Isn't Desired TX power supposed to adapt so that higher bitrates are possible,
with Bit Rate going lower if that is not enough to keep a good connection?
Richard,
Please grab a new copy of the port_to_mac80211 patch, and try the patch below. It boosts the desired
power by up to 5 dBm as signal - noise decreases from 20 to 0.
Larry
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -622,6 +622,8 @@ struct bcm43xx_wldev {
bool short_preamble;/* TRUE if using short preamble. */
bool short_slot;/* TRUE if using short slot timing. */
bool radio_hw_enable; /* State of radio hardware enable bit. */
+ u8 saved_signal_noise[4];
+ u8 signal_noise_index;
/* PHY/Radio device. */
struct bcm43xx_phy phy;
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2862,6 +2862,8 @@ static void setup_struct_phy_for_init(st
phy-interfmode = BCM43xx_INTERFMODE_NONE;
phy-channel = 0xFF;
phy-power_level = 0;
+
+ dev-signal_noise_index = 0;
}
static void setup_struct_wldev_for_init(struct bcm43xx_wldev *dev)
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
@@ -1771,6 +1771,7 @@ void bcm43xx_phy_xmitpower(struct bcm43x
s16 desired_pwr;
s16 estimated_pwr;
s16 pwr_adjust;
+ s16 snadjust;
s16 radio_att_delta;
s16 baseband_att_delta;
s16 radio_attenuation;
@@ -1824,6 +1825,14 @@ void bcm43xx_phy_xmitpower(struct bcm43x
estimated_pwr = bcm43xx_phy_estimate_power_out(dev, average);
+ /* calculate any power boost from low S/N values */
+ snadjust = (dev-saved_signal_noise[0] + dev-saved_signal_noise[1] +
+ dev-saved_signal_noise[2] + dev-saved_signal_noise[3] +
+ 2) / 4;
+ /* boost from 0 to 5 dBm as S/N decreases from 20 to 0 */
+ snadjust = limit_value(5 - snadjust/4, 0, 5);
+ snadjust *= 4; /* convert to Q5.2 format */
+
max_pwr = dev-dev-bus-sprom.r1.maxpwr_bg;
if ((dev-dev-bus-sprom.r1.boardflags_lo
@@ -1848,7 +1857,7 @@ void bcm43xx_phy_xmitpower(struct bcm43x
- 0x6, max_pwr);
/* find the desired power in Q5.2 - power_level is in dBm */
- desired_pwr = limit_value(phy-power_level 2, 0, max_pwr);
+ desired_pwr = limit_value((phy-power_level 2) + snadjust, 0,
max_pwr);
if (bcm43xx_debug(dev, BCM43xx_DBG_XMITPOWER))
bcmdbg(dev-wl, Current TX power output: Q52_FMT
dBm, Desired TX power output: Q52_FMT
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -526,6 +526,12 @@ void bcm43xx_rx(struct bcm43xx_wldev *de
status.antenna = !!(phystat0 BCM43xx_RX_PHYST0_ANT);
status.mactime = mactime;
+ /* update S/N buffer */
+ dev-saved_signal_noise[dev-signal_noise_index++] =
+ status.ssi - status.noise;
+ if (dev-signal_noise_index = 4)
+ dev-signal_noise_index = 0;
+
chanid = (chanstat BCM43xx_RX_CHAN_ID) BCM43xx_RX_CHAN_ID_SHIFT;
switch (chanstat BCM43xx_RX_CHAN_PHYTYPE) {
case BCM43xx_PHYTYPE_B:
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -622,6 +622,8 @@ struct bcm43xx_wldev {
bool short_preamble;/* TRUE if using short preamble. */
bool short_slot;/* TRUE if using short slot timing. */
bool radio_hw_enable; /* State of radio hardware enable bit. */
+ u8 saved_signal_noise[4];
+ u8 signal_noise_index;
/* PHY/Radio device. */
struct bcm43xx_phy phy;
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2862,6 +2862,8 @@ static void setup_struct_phy_for_init(st
phy-interfmode = BCM43xx_INTERFMODE_NONE;
phy-channel = 0xFF;
