PogoPlug V4 Jumbo Frames issues

[mikiha]

Hi , just bought a v4 and a 4 drive external sata chassis , so far no issues ,
but when connecting to 1GBPS network , i get errors in the arch linux kernel ,
tried both builds of linux kernel (with and without kirkwood ) , and when i set mtu to above 1500 i get alot of tx and rx errors ,

$this->bbcode_second_pass_code('', 'eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1514
inet 10.0.0.66 netmask 255.255.255.0 broadcast 10.0.0.255
ether 00:25:31:05:2a:30 txqueuelen 1000 (Ethernet)
RX packets 754226 bytes 825311275 (787.0 MiB)
RX errors 3 dropped 91 overruns 0 frame 0
TX packets 1206447 bytes 2736801336 (2.5 GiB)
TX errors 14637 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 11
')

also at dmesg
$this->bbcode_second_pass_code('', '[36324.331939] mv643xx_eth_port mv643xx_eth_port.0: eth0: tx error
[36324.332034] mv643xx_eth_port mv643xx_eth_port.0: eth0: tx error')


i tried to replace cable , but no help , when ever i set mtu to 4500 or 9000 i start getting errors
iperf went ok with speeds of up to 900mbps ,

my kernel version right now is :
$this->bbcode_second_pass_code('', 'Linux alarm 3.1.10-29-ARCH #1 PREEMPT Mon Dec 16 16:08:40 MST 2013 armv5tel GNU/Linux
')

also just ran into this issue with the marvel 643xx chipset :
http://us.generation-nt.com/answer/kirkwood-mv643xx-eth-wrong-tcp-checksums-help-170358561.html

any help would be greatly appreciated.
thanks.

[Sergeanter]

They were talking about implementing a patch to handle CRC in software for jumbo frames. Did you look in the code to see if the switch is there?
I would not know where to look for tx rx errors but the speed drops from 17.5 MB/s to 2MB/s when I change MTU to 9000 so yes something is wrong.
On the other hand would we really benefit from the jumbo frames? It feels like transfer rate is limited by CPU speed.
I added 2 eSATA ports to Pogoplug Mobile ( essentially castrated V4) and the max I see is 17.5 MB/s with Samba and RAID5 with 4x3TB WD red drives . If you look at results of "top", smbd looks pretty busy.

[WarheadsSE]

Samba is pretty expensive.

[kmihelich]

Going above ~1600 MTU will cause hardware checksum offloading to be disabled when patched, which means the CPU has to take the hit for making sure every packet is correct. Kirkwoods don't have much CPU to go around.

You also need both endpoints to support jumbo frames, and a switch in between capable of it too.

Your software also has to frame packets correctly to use jumbo frames. For example, iSCSI uses 8192B frames and you will see a noticeable improvement in throughput when using jumbo frames so that the packet isn't fragmented across multiple packets.

[mikiha]

i used the patch to patch the mv6433 driver and rebuilt the kernel tried it with packets larger then 1600 - > 4500 -> 9000
all of which stopped the errors ,but since the tcp checksum is done in software ,cpu started to increase ,
so i still got 36-38mb bandwidth , but at a cost of packets dropped since the cpu isnt up to the load ,
nfs speed was better than samba , but still i need to get around 100MBPS so i ended up buying the hp microserver , which does get me a 120 MB bandwidth. so pogoplug v4 is too slow to handle the load , probably will use it as a wireless camera port .

[Sergeanter]

I have not looked at the code myself, but with my setup
3.1.10-29 did not handle jumbo frames correctly at all ( there was packet loss, and terrible drop in transfer rate)
3.12.8-1 most likely handles jumbo frames properly , but there is no benefit in going from mtu 1500 to jumbo frames.
This is just speculation but most likely that software crc patch was implemented between these versions. Correct me if I am wrong