You are not logged in.
I've got some differences between the way my wireless pcmcia card runs on Wolvix when compared to Arch and I'd appreciate any advice on getting it to run better.
Basically on Arch it sometimes cuts out or stalls for short periods when downloading, but mostly it just does not reach the same speeds as I get when running Wolvix on the very same machine (or windows for that matter). It's fine for browsing in firefox, but for any sizable download the difference really shows. Both installations use Wifi-Radar to connect to the internet and madwifi for the drivers.
Ath5k is disabled in Arch, and does not even try to start-up in Wolvix - so it's a non-issue. I no longer have the network module loading at start-up in Arch (I'd been going through the guides for ages going over my config files and then decided to stop using as many of them as possible - and instead just let wifi-radar connect for me using pretty much the same settings as Wolvix, so that as much as possible was the same as in the Wolvix install)
The main difference seems to be that madwifi and wifiradar are both about a year out of date in Wolvix, but are the latest ones in Arch. The output of iwconfig for both installs is shown below. I've highlighted a couple of differences I spotted.
On wolvix:-
root@wolvix ~ # iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wifi0 no wireless extensions.
ath0 IEEE 802.11g ESSID:"FinniX" Nickname:"FinniX"
Mode:Managed Frequency:2.447 GHz Access Point: 00:0D:88:ED:45:25
Bit Rate:24 Mb/s Tx-Power:16 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:AB46-DF38-CDEB-89CA-23FB-67DE-47 Security mode:open
Power Management:off
Link Quality=24/94 Signal level=-70 dBm Noise level=-94 dBm
Rx invalid nwid:215 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
and on Arch:-
[root@FinniX ~]# iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wifi0 no wireless extensions.
ath0 IEEE 802.11g ESSID:"FinniX" Nickname:"FinniX"
Mode:Managed Frequency:2.447 GHz Access Point: 00:0D:88:ED:45:25
Bit Rate:5 Mb/s Tx-Power:16 dBm Sensitivity=1/1
Retry:off RTS thr:off Fragment thr:off
Encryption key:AB46-DF38-CDEB-89CA-23FB-67DE-47 Security mode:open
Power Management:off
Link Quality=20/70 Signal level=-74 dBm Noise level=-94 dBm
Rx invalid nwid:40 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
There are pretty much no differences between the outputs when I give the ifconfig command or for lsmod | grep ath. inet6 is not up as default on Arch and is on Wolvix (I followed some advice I found on a post and blacklisted it on Arch to see if it helped), but running with inet6 either up or down on arch makes no difference to the speeds, I've tried both.
I'm unable to change the Sensitivity of the wireless card (says I cannot change it on this card when I try) and have no idea how to go about changing the max link quality from 70 to 94. Yet these are the only two unchanging values that are different between the wireless set-up of the two installations.
I think the next move is to replace my current version of madwifi on Arch with an older version that matches the one installed in Wolvix, so that both installations use the same drivers for the card to see if it helps. But I'd really appreciate any input on why the same card functions so much worse in Arch than it does in the slackware based Wolvix.
Offline
You didn't mention the atheros chipset... I have a PCMCIA Atheros AR 5416 (5007 or 5008) and I had to use ndiswrapper and blacklist the ath5k- and ath-pci-modules IIRC.
The up and coming new atheros driver ath9k will be merged into the linux kernel around v2.6.27.
I'm using netcfg to connect to my WPA2-PSK-network and I must say that my connection is always rather 'low' (now 40/100 f.e. - and I'm only a few meters away from my AP), but I have never seen any problems when downloading or browsing.
I have never compared with another distro though...
Zl.
Offline
Thanks for the reply Zenlord I've used ndiswrapper before on another PC for a wireless USB dongle, but I never thought it'd be needed for this card since it's proven to work with madwifi in the past. But it might be worth a try anyway.
As for the card, it's a Kcorp KLG-520 pcmcia card. This is the sites spec page for it:-
http://www.kcorplifestyle.com/products/ … LG-520.htm
Under chipset they give these two results:-
RF: AR2112
BB/MAC: AR5212
and in Arch I get this:-
[root@FinniX ~]# lspci | grep Atheros
06:00.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01)
I'll have a look to see if the other distro gives the same output later.
Edit:-
Wolvix output:-
root@wolvix ~ # lspci | grep Atheros
06:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
Last edited by Nixie (2008-09-30 10:26:31)
Offline
I tried downgrading madwifi and madwifi-utils to an earlier version which briefly seemed to work, before the old speeds, stalls and slowdowns were resumed. Got my hopes up for about two minutes
Could it be down to the newer version of hal that Arch uses? Maybe that's what's making the difference. If the newer version of hal identifies the pcmcia card differently from the older version of hal it could perhaps be why madwifi seems to be assigning different drivers on the two different distros?
Or is there a way to manually select the driver that madwifi uses? Could I stop using AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01) as the ethernet controller and switch to AR5212 802.11abg NIC (rev 01)
I'd know how to do that quite easily on windows to see which worked best, but I have no idea how to try it on Arch/linux.
Offline
Try reverting to the kernel and madwifi packages that came on the 2008.06 disc. That's working well for me. You can hold them using the IgnorePkg line in pacman.conf
Offline
Thanks for the tip mfsal I may well do that if I have to.
But it's not my first choice. I don't mind holding madwifi to an earlier version on it's own, but I don't want to put a hold on the kernels updates too. It would kinda detract from the main reason I decided to try Arch - the rolling updates. I'd rather find a way to change the single driver in question via the command line, or else try the ndiswrapper option instead.
Offline
You can also try building the latest svn madwifi code... You can check it out with
svn checkout http://svn.madwifi.org/madwifi/trunk madwifi
and then use ABS to build madwifi-utils and madwifi packages using that version of the source.
The latest revision seems to work a bit better than the version that was used to build official packages from the repos.
Offline
I found something that seems to help the connection improve on Arch so that it's comparable to Wolvix:-
"madwifi release 0.9.4 adds a sysctl "intmit" to turn ANI on and off. ANI is enabled by default and can be disabled in cases where this yields better performance."
example: sysctl -w dev.wifi0.intmit=0
I ran that command last night and downloads have been significantly better since then, perhaps it was not enabled by default in earlier versions of madwifi? Hopefully this is a longterm fix to the performance issue.
Offline
Let us know, will you? If things keep working well for you, I can let my kernel update again.
Offline
So far so good, the speed still fluctuates a bit. But I get consistently better high speeds. Before it used to stay at lower speeds, stall on downloads quite often, with speeds between 20-40kb/s at best being normal (with very occasional jumps to better speeds).
Now I'm often getting 150-450+kb/s depending on where I'm downloading from & what else I'm doing. All good for my connection and in line with windows and wolvix installs on the same laptop and using the same wireless card.
It does still dip down to lower speeds in the 20-90kb/s range when downloading very big files from rapidshare, but only for a matter of moments, then it heads straight back up again into the higher speeds. Is overall very much better.
Last edited by Nixie (2008-10-01 20:12:12)
Offline
That's excellent news, thanks. I'll have to give it a try one of these days, but right now I'm content trailing behind a kernel version or two.
Offline