High load average with rt73

Live forum: http://rt2x00.serialmonkey.com/viewtopic.php?t=3071

zwenna

02-02-2007 15:13:03

I have a D-Link DWL-G122 Rev. C1 adapter. The legacy rt73 driver works quite okay (in managed mode with wpa2psk), but the system load is rather high, "uptime" reports a load average of ~ 2.00 on an otherwise idle system. Strangely enough, "top" tells me that the sytem is 99% idle, though the fans are quite noticeable.

I'm using rt73-cvs-2007012408 with vanilla kernel 2.6.19.2.

idamlaj

03-02-2007 09:57:00

Could you please post some debug information? You can do this by
[codecgll0hpe]insmod rt73.ko debug=2 [/codecgll0hpe]

and then getting the relevant content from /var/log/messages .

zwenna

03-02-2007 11:29:42

Attached is the contents of /var/log/messages between 'ifup rausb0' and 'ifdown rausb0'. I forgot to tell that the system load only is high when the
interface is up, merely loading the driver has no impact.

wjl

14-04-2007 13:16:46

Hi zwenna & idamlaj,

I have the exact same issue with a MSI US54SE II card which I bought yesterday. It works fine using the RT73 driver, but as soon as the device is up, it's producing a load average of ~ 2 on my otherwise idle Athlon X2 3800+

I think these devices produce a lot of interrupts. Mine is using ehci, and a simple 'grep ehci /proc/interrupts' show it all - I'm speaking of about half a million interrupts per hour.

This backs up what the German c't magazine said about the usage of USB WLAN cards in their issue 4/2005 - they reported a CPU usage of 50 to 60% in Windows XP, and recommended to use PCI devices instead.

I just posted my success story yesterday on http//blog.thedebianuser.org/, but after seeing that unnecessary load, I might reconsider hte usage of USB WLAN devices and go back to good old cable...

Kind regards,
wjl aka Wolfgang Lonien
http//wolfgang.lonien.de/
http//blog.thedebianuser.org/

monkphunk

07-05-2007 18:35:12

I'm having the same problem- lots and lots of interrupts resulting in high load average- with an asus wl-167g on an arm platform. Pardon my ignorance, but is this a driver issue or a problem with the dongle itself? I can't upgrade my kernel right now, but in the future would the non-legacy driver help with this problem?

Zi7

07-05-2007 19:32:12

There are two main reasons for what you guys observed
  1. [*1z0ffbuq]Radio medium imply quite a lot of beacon exchanges between the STA and its AP even when there is no IP traffic, thus as you guessed, that's as many IRQs to process (nothing we can do about this)[/*m1z0ffbuq]
    [*1z0ffbuq]IRQ handling and some other legacy driver tasks are badly designed, resulting in much more resource consumption (and worse performance) than what would otherwise be required (this we can do something about, and you can expect rt2x00 to help with that)[/*m1z0ffbuq][/listo1z0ffbuq]As an example, i tuned the rt61 IRQ handler and it consumes 0% of my 1.4GHz Celeron M when connection is idle.

monkphunk

13-05-2007 16:15:55

ok, i think i figured out what is going on here. the interrupts are a red herring when it comes to the load. the rt73 processes are spending most of their time sitting in the uninterruptible sleep state, which linux includes in the load average. but they're not really using much cpu time

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 4554 0.0 0.0 0 0 ? D 0132 013 [rt73]
root 4555 0.0 0.0 0 0 ? D 0132 000 [rt73]

I don't think it's IO delays either
Cpu(s) 1.7%us, 0.3%sy, 0.0%ni, 97.0%id, 0.0%wa, 0.3%hi, 0.7%si, 0.0%st

I tried to see where in the driver source this uninterruptible sleep is coming from, but I don't have any experience with such things and I couldn't figure it out. I think it might to do with the difference between down() and down_interruptible() in rtmp_main.c, but I'm not sure. It seems that whatever loop the driver sits in waiting for things to happen relies on some sort of uninterruptible delay. Is there a reason for this?

I don't think this really has an adverse impact on performance; the box responds fine. But it would be nice (if mostly aesthetic) to fix this. Are there any reasons why it might be bad to have the driver sitting in uninterruptible sleep much of the time?

jago25_98

16-05-2007 20:51:47

I have a bigger problem like this. As soon as I try to scan for networks or generally use the card a process called `rt73` eats up all the CPU cycles to the point of crashing.

The process also can't be killed.

I will now try to insmod with debug.

Should I start a new thread?
I also have a Intel 2200bg PCI card. Would I be better off concentrating on making sure injection support works on that first?

Spy84464

16-05-2007 21:07:54

Hell,
Yes, you should start a new thread. Give us more information there, like what are your distribution, kernel version and driver version.

Regards,
Romain

jago25_98

20-05-2007 16:24:41

To anyone reading this, I left it a few days and upgraded. Now doesn't seem to happen.

mac

17-10-2007 16:23:13

I have a levelone wnc-0301usb V.3

I am having the high load issue with rt73-cvs-2007101708 and with the RT73_Linux_STA_Drv1.0.4.0 (ralinktech) drivers.

root@box/home/mac# uname -a
Linux box 2.6.18 #1 Wed Jun 27 135216 HKT 2007 i686 GNU/Linux

load
121445 up 1 day, 1632, 1 user, load average 2.28, 2.13, 2.01

symptoms are same as above, the load does not jump until I configure the interface.

Is there a fix?

gar2500

20-11-2007 16:23:29

Hi there!

I have the same problem with a D-Link DWL-G122 rev C1 adaptor. My load increase up to 2 as soon as I activate the interface (using WPA). Amazingly, I did not have this problem when I was using rt2500 driver (also using WPA) on a rt2500 PCMCIA card. No more beacon (same AP), same encryption type.

Is there any huge difference between PCMCIA and USB that would explain such a load average increase? If not, it should be depending on driver implementation, isn't it ?

Best regards,

Georges

PS I am using a 2.6.19-gentoo-r5 kernel compiled with SMP (that I supposed to be expected for a dual core proc.)

Spy84464

25-11-2007 20:06:54

Hello,
Which version of the driver are you using? Try the very latest CVS version.
I know USB introduces some overhead, but I don't think that's noticeable, so it could be a problem in the driver.

Regards,
Romain