[SOLVED] Rx frames low on embedded system

Hi,
I made a little Linux OS (that should be based on ancient RedHat 9), recompiled my kernel for it and included all in a neat TFTP boot image. The embedded device (actually meant to be a gateway*)has a Tolapai CPU.
Everything works, all three NICs eth0, eth1, eth2 can even go to Internet.

Only when our test team tests the device with Smartbit (network test infrastructure) they constantly complain Rx frames would be too few.

I am using a 2.6.18.8 kernel and the LAN driver is a proprietary one made by the device maker (actually it is a modified Intel Embedded 0.8.0 driver).

Any ideas? I am out of ideas right now.

* not using it as a gateway, just configured it as a normal Linux workstation

Cheers,
Ludigel

A little update on this. I can now kind of reproduce the error by myself without the test team and SmartBit.

When I am using an OS image made by the device manufacturer (which I have for comparison), then I always see Rx being more packets than Tx (I am sending a lot to the system via ping).

When I use my image Rx packet No. is always smaller than TX.

Well, enabling RX_POLLING in the kernel configuration (in the network drivers section) has improved the result; yet probably not to a satisfying extend.

[Edit: Tricky part here: I only get the RX polling option I need when enabling the Intel IEGBE driver in kernel, but I am not actually using this driver but a properitary one. Makes it easy to overlook this option ;-]

What's your NIC speed, 1G or 100M? What's your CPU? How many core?

1G LAN. The Intel Tolapai is a system-on-chip CPU, 600MHz Pentium-M derived. Have Single-core, one thread CPU. More info here: http://home.mit.bme.hu/~feher/MSC_RA/Intel_FPGA/SP08_QATS002_100r_eng.pdf . Or more clear here: http://ark.intel.com/products/34316/...cessor-600-MHz
Just noticed my current kernel does not have the SMP option (had space problems and kicked a lot out), but does not seem as if it could help.

Edit: After consulting with customer etc. the performance of my test image is sufficient after the RX-POLLING option was chosen. I have 40% of the manufacturer image performance and that is fine for our initial test. Later we get the customer's image anyway (which has a better rootfs with less busybox). Performance diff depends on rootfs and not on hardware, so it's fine.

EDIT: Out of sheer sportsmanship I re-configured the kernel to reach 100% network throughput with my image, just like the customer. A minimal kernel sometimes just doesn't do it ;-)