What kind of ethernet performance should I expect from the AT91SAM9263-EK board? I'm trying to mount my rootfs over NFS and the speed is painfully slow.

I've booted off a jffs2 filesystem and the system is quite fast. I then mounted a directory with NFS and tried to copy a file over and again, the speed was terrible. Using wget to download a large file over HTTP is also very slow.

Basically, I'm blaming slow ethernet speeds.

Does anyone know if I can get more speed out of this thing? I'm using Linux 2.6.24. Could the default kernel config from linux4sam.org be missing any useful TCP/IP settings?

Thanks.

What speed is your network?
How slow is a ping to another host?
Should be less than a millisec for 1 hop at 100 mbps.

I've got an AT91SAM9G20-based board that's running Timesys' spin of 2.6.25. I have my root filesystem mounted via NFS on a Fedora 8 box, and just built netperf for both x86 and ARM so I could find out what kind of performance I'm getting through the macb driver.

Running the server on the ARM and the client on the x86, the TCP stream test shows 70-75Mbps on a 100Mbps direct connection. Running the server on the x86 and the client on the ARM, the same TCP stream test shows 30-40Mbps on the same link. The TX side of the macb driver seems to be a little lame compared to the RX side.

Back in 2.6.22, there was a kernel option called MACB_TX_SRAM that would put the transmit blocks in SRAM, instead of letting the kernel allocate SDRAM space for them. That option has disappeared in 2.6.24, but might need to make a comeback. If I can find time to work on it, I'll see if I can get the MACB_TX_SRAM patch to work again.

We still seem to be having TX problems as well. Can you let us know if you manage to patch the 2.6.24 kernel for the SRAM buffer ? Thanks

Gertjan

I apologize... I'm not receiving notices from the forum when people reply to my messages, so I didn't know you had asked about the TX_SRAM option. I've had so many other details to work out on my g20 board that I never got back to looking at the MACB driver.

But I did see over on the Linux board that you've already done the patch yourself, without much benefit. I guess the new (non-SRAM) driver code is just more efficient than the old code, so you get the same performance without having to dedicate the SRAM to the network driver. That's probably a good thing.