Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
I have the problem, that the read performance of NFS Shares on CH3SNAS with funplug is really poor (just a view bytes per sec and interruptions of several seconds), when mounting the shares with the UDP option. Write performance on the same share is OK! Mounts using the TCP options are working fine in both directions. I need to use the UDP option for my 2 Dbox2 receivers, because other wise I get streaming interruptions due to the restricted network bandwidth (10 Mb HD) and the TCP protocol overhead.
My infrastructure:
- Gigabit Switch (D-Link)
- CH3SNAS (1Gb network link, 1x1TB HD)
-- problem repeatable with firmware versions 1.05b1, 1.05b3, 1.05b4-r160
-- funplug 0.5 on USB Stick using howto on wolf-u.li (all packages are updated)
--- problem repeatable with nfs-utils-1.1.0-4 und unfs3-0.9.22-1
- 2 x Dbox2 (10 Mb HD network link)
- PC (1Gb network link)
NFS exports file:
/mnt/HD_a2/media/mov 192.168.1.15(rw,no_root_squash,no_subtree_check)
/mnt/HD_a2/media/mp3 192.168.1.0/24(ro,no_root_squash,no_subtree_check)
/mnt/HD_a2/media/pic 192.168.1.0/24(ro,no_root_squash,no_subtree_check)
Used mount options:
mount -t nfs -o rw,soft,udp,nolock,async,rsize=32768,wsize=32768 192.168.1.20:/mnt/HD_a2/media/mov /mnt/nas1mov
If I test with TCP, I just replace udp by tcp
NFS shares with my Dbox2 devices are working for years in this infrastructure. I just want to replace an Icy Box IB-NAS2001-B by a CH3SNAS, because the ICY-Box is instable, breaking frequently and not performing as CH3SNAS. The problem is repeatable with the above mentioned firmware versions of CH3SNAS and with both NFS servers out of the actual funplug. Additionally I proved the behavior on my PC with a bootable Linux environment (Knoppix 5.3) and I can access NFS shares on my PC (SFU) from the Dbox2 using UDP mount option with expected read performance. So I assume that there is no infrastructure problem and the reason for the problem has to be related to CH3SNAS and/or funplug. So I am at my wits' end :-(. Is there anybody who can help me to identify the problem?
Offline
I'd be very suspicious of any UDP based NFS network when the server is 1Gbps and the client is 10Mbps. If the server sends out a bunch of data to the client packets will end up possibly getting lost as various buffers overflow. TCP has built in mechanisms to detect and deal with this, UDP does not. I suspect the benefits of TCP here would outweigh the slight overhead in packet size.
Just out of interest, what's the bitrate of the media you're trying to stream?
Offline
Niels,
I'm streaming (or better I read or write on the NFS server) files with bitrates between 4.4 and 8 Mb/s for years. This works with my PC (1 Gb network link as CH3SNAS) and my old NAS (100Mb network link), which I want to replace due to other reasons. A good switch can handle this. As the bitrate is close to the optimum of a 10 Mb HD connection, I need to use UDP as it got less protocol overhead compared to TCP. If a package really got lost, I just get a little flickering on the screen.
rom69
Offline
rom69 wrote:
If a package really got lost, I just get a little flickering on the screen.
I don't think that's true. NFS retransmits lost packets. And the app will block just like with TCP. In my experience with NFS over WLAN, using UDP and large rsize/wsize parameters kills NFS performance if there's packet loss. If packet loss is your problem, I expect NFS over TCP to perform a lot better than NFS over UDP (especially with large rsize/wsize).
Offline
Fonz,
sorry, if I’m explaining things unclear due to my restricted network knowledge. My understanding is, that UDP has less protocol overhead than TCP. That’s why it is recommended for the Dbox2 Neutrino Movieplayer to use the udp mount option, when opening files on NFS serves, because the possible net data rate is higher than with the tcp option. My experiences accessing NFS shares on a PC and on a Box IB-NAS2001-B are confirming these statements. I also can confirm, that this works reliable. Lost packages are not the problem I want to solve. Forget about all the Dbox2 and 10 Mb HD connections I wrote about.
Imagine there is a PC with Knoppix and GB NIC, a GB network switch and a CH3SNAS with funplug. Using the different mount options, I get the following results for read and write speed, varying a little depending on the rsize/wsize settings and the NFS server used (I don’t remember the exact transfer rates, but let’s assume OK means > 10 MB/s. I can post detailed values tonight, if required):
write speed read speed
TCP mount: OK OK
UDP mount: OK < 5% of the ones stated OK
The problem is that the UDP read speed is so much lower than the others. Is there something I can do to improve this situation?
regards
rom69
Offline
rom69 wrote:
My understanding is, that UDP has less protocol overhead than TCP.
Assuming Ethernet with an MTU of 1500 bytes, protocol overhead is small for both TCP and UDP. For UDP it's somewhere around 1.87%, for TCP it's between 2.7% and 3.7% (depending on your options). For a 10Mbit/s network, this limits net throughput to around 9.8Mbit/s for UDP, and 9.65Mbit/s for TCP. Is that difference really important?
I think, Niels actually has a point here. The bandwidth mismatch can lead to packet loss. Packet loss triggers retransmissions and reduces throughput. In my experience, TCP is doing a much better job than NFS in this case.
Offline
Hello together.
After some more testing I found out, that I had the download performance problem also using SMB or FTP. So I started to check step by step the whole infrastructure and ended again at the CH3SNAS as reason. After changing the disc drive the problem for SMB and FTP was gone. So I checked the original disc by installing it in a windows PC and found S.M.A.R.T errors (“Reallocated Sector Count” and “Current Pending Sector Count”). It seems that this caused the problem.
I still have the NFS download issue when using the UDP Mount option. As with a dbox it makes a difference for upload to use UDP or TCP, I’m working with two mounts now. One for uploads using UDP and one for downloads using TCP.
Regards
rom69
Last edited by rom69 (2009-07-10 14:29:19)
Offline