# Unison performance with different Atheros wifi drivers

## Havin_it

Hi,

This is a very odd one. For ages I've used madwifi with both my Atheros wifi cards (AR5007EG and AR5001X+) but I recently tried out wicd and thought I'd try ath5k at the same time. ath5k actually seems to get better signal range in both cases, but I discovered one bizarre quirk.

With the older card (AR5001X+, which is a Netgear WPN511 MIMO CardBus card), when using ath5k, it's absolutely impossible to use unison for a ~2GB sync job (lots of small files) that works fine on the other machine with either driver, and on the same machine with madwifi. The checking phase is fine, but when it comes to syncing, about 12 items read "Starting", 1 or 2 get fully or partially synced, and then it stalls indefinitely.

No other network transfer ops seem slower with this combo, so what is it that's unusual about unison specifically with this card and ath5k?

Thanks for any hints.

----------

## erik258

How old is your kernel?  The in-kernel ath5k modules are still actively developed, from what I can tell in the changelogs from the last few years (I use ath9k as well as ath5k, so I watch the atheros drivers with some interest).  

I recommend 2.6.35.7 or perhaps newer for improved atheros support (mine's improved over the last year).  But you might get the same atheros drivers from 2.6.3[45].x for all I know, so if you don't want to be too far out onto the bleeding edge, take a look at the changelogs. 

-- DF

----------

## MotivatedTea

During the "checking" phase, not much data is transfered, and the transfers that do happen tend to be in small bursts. During "syncing", large sustained transfers happen. A bug I've seen crop up with various different wireless chipsets is that large transfers cause drop-outs. (I had this problem with an Intel wireless chipset about 10 years ago, and an Atheros chipset using ath5k about a year ago. In both those cases, upgrading to a newer kernel eventually fixed the problem.) As erik258 says, the ath5k drivers are still actively under development, so a kernel that works for one model of the chipset may not work (yet) for another.

Check your dmesg or /var/log/messages while unison is trying to transfer. Watch for wireless-related error messages. Googling those may help you find other people with the same problem. (Hopefully some of them will have a fix.) For instance, here's an Ubuntu bug that sounds similar to your symptoms:

http://bugs.launchpad.net/ubuntu/+source/linux/+bug/369005

The bug identified in that Ubuntu bug report has been patched upstream in newer kernels (see comment #20), and also suggests that disabling CONFIG_PCIEASPM in your kernel config might be a workaround.

Also see here:

http://linuxwireless.org/en/users/Drivers/ath5k#PCI-E:_Eliminating_.60ath5k:_unsupported_jumbo.60_bug

That may or may not be the same problem you have. Hopefully your error logs will give you more info.

----------

## Havin_it

Hi, thanks both for the replies.

My kernel is gentoo-sources-2.6.36 on the affected system, and I don't have any PCIe options enabled in the kernel as it's a pre-PCIe (2003) laptop. The bugs mentioned seem to centre on AR5007EG cards, but my one of those seems to work fine with ath5k, in fact now better than with madwifi (which was not the case for a very long time).

I'll have a look at the logs, and see what I can see.

----------

## Havin_it

Not much progress with this. I rebuilt my kernel with all Atheros and general 80211 debugging options I could find turned on, but still no significant output in /var/log/messages to give any useful hints. All I see is the occasional switch into or out of promiscuous mode, which doesn't seem to be specific to the transfer period.

I also tried running strace on unison on both sides of the connection, but all I got from this was waiting on the server-side and a flood of "Resource temporarily unavailable" on the client.

Also, I tried disabling wicd and just using net.wlan0, this made no difference.

Going back to the point about large transfers, I tried running rsync on the same directory (usually all that's transferred is the modified files in my Firefox profile after a run) and, while a bit slower than usual, it was still within normal expectations. My understanding was that unison uses rsync internally for transfer, so this ought to be as similar as it gets - but something's different about unison.

----------

## erik258

 *Quote:*   

>  My understanding was that unison uses rsync internally for transfer, so this ought to be as similar as it gets - but something's different about unison.

 

Interesting... have you tried looking at the output of something like `ps -aefww` while unison is running to see what the full command line used for rsync is?  Perhaps it has some silly setting like infinite timeout or something.

----------

## Havin_it

Sorry, I mis-phrased that a bit. Unison doesn't use the rsync binary (at least not by default), rather it implements the rsync algorithm internally.

However, looking at the manual in greater depth, it can be made to call rsync externally or use another copy program, though I'm not sure what other would apply.  There's also an option to make it do whole-file transfers instead of rsync, so that may be worth a try.

I'll muck about with these (as well as Unison's own debug output options, which I'd overlooked) tomorrow and see if I can learn more.

PS - I think ssh is a factor in this, as I tried the rsync comparison again, this time using "rsync -e ssh" instead of connecting directly to the rsyncd on the other machine, and this also ground to a halt. On the other hand, copying a handful of files using the fish:// kioslave went at a reasonable pace ... very odd.

----------

## Havin_it

Debug info wasn't all that helpful, other than showing that at times when nothing seems to be happening, it really isn't (output just shows a progress ticker, same as when waiting for input between analysis and transfer phases).

Using "-rsync=false" was a bit better, insofar as the transfer phase would sit doing nothing for quite a long time, then burst into life and complete a big spurt of transfers. It took only 2-3 of these cycles to complete, and the wait interval progressively shrank.

However, my gf was trying to print some OOo docs on the same machine and found that transferring the print jobs (to the same server I'd been unison'ing to/from) took huge lengths of time, so the problem is not unique to unison it seems.

Whatever the cause, I've had enough - it was not worth the ear-bashing I got over the printing issues   :Embarassed:  so I'm going back to madwifi. It has its own problems (sometimes it just rolls over and dies) but at least they can usually be remedied by popping the card out for a minute.

It's a shame, as it looks like ath5k has matured a lot in recent kernels, and it's now my driver of choice for my newer machine, but these issues are a complete showstopper.  Guess I'll look in again in a few kernels' time...

----------

