Improvement in SMB Performance found

[2twisty]

My video data is stored on a windows server that I access via SMB from the Pi.

I was able to play back SD videos without any issue, but had problems with stuttering on Hi-Def sources. I added the video sources via the XBMC interface. However, since I wanted access to those shares from a terminal, I also mounted them in fstab. I used a standard mount entry with no options except for the username and password.

Code:

//video/files /media/video cifs username=uid,password=pwd 0 0

In an effort to keep my Pi healthy as long as possible, I had my overclock set to the "XBIAN" preset, figuring that the XBian folks knew what preset was best.

In this configuration, I had stuttering problems with my 1080p sources. That was no good. So, I started looking into it.

I started digging around the internet in linux forums for "slow smb linux" and I found the following thread:

http://ubuntuforums.org/showthread.php?t=1429532

So, I decided to tweak a few things.

I created the file "cifs.conf" in /etc/modprobe.d and added the following to it:

Code:

options cifs CIFSMaxBufSize=130048

I then modified my fstab entries to include the directio and rsize options:

Code:

//video/files /media/video cifs directio,rsize=130048,username=uid,password=pwd 0 0

Then I rebooted the Pi to clean everything out and redo the mounts. My testing showed VAST improvement. Now, the HD movie was actually watchable, although it would have the occasional hiccup in playback. It was just often enough to be "unacceptable." So, since I had maxed out the rsize options (according to the mount.cifs manpage) I decided to look elsewhere for a performance enhancement.

So, I bumped my overclock up to "High" and rebooted.

Got smooth playback now.

[Koenkk]

If you want to, you can open an issue on our git https://github.com/xbianonpi/xbian/issues/new about this.

[CurlyMo]

Samba (default)

Code:

dd if=/dev/zero of=/media/smb/test bs=1024 count=102400  
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 12.3411 s, 8.5 MB/s

NFS

Code:

dd if=/dev/zero of=/media/nfs/test bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 13.3851 s, 7.8 MB/s

Samba (rsize)

Code:

dd if=/dev/zero of=/media/smb/test bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 81.1456 s, 1.3 MB/s

It made my samba connection about 7 times slower.

[2twisty]

strange. Maybe I'm just hitting the limits of the Pi.

When I have my library attached to a windows box using xbmc, it can scan the entire library in seconds and the movies are all there.

The same process with the drives attached to the pi takes about 20 minutes.

is xbian's NTFS code really inefficient? What can account for this discrepancy?

[CurlyMo]

The fuse-ntfs drivers...

[2twisty]

Are they really THAT bad? since my video library is on external USB disk, I'd like to maintain them in a transportable format. Unfortunately, due to file size, FAT32 is not an option. The only other FS that seems to have universal read access (at least, many have RW) is NTFS.

---

Im going to try tweaking the options in fstab. Maybe I'll get something reasonable. Seems like I just keep striking out.

[BartOtten]

NTFS is CPU intensive. On my Mac fuse is not really a problem but the Pi just does not have that kind of power.

Whatever you do, don't switch to JFS as it is really unstable in combo with the Pi

[zilexa]

@2twistyy, you could switch to eXFAT, both Windows and Mac support it.
or create 2 partitions, 1 small eXFAT and one EXT4 for all your data. If you need anything to be available when directly connected to pc or mac, simply use XBMC File Manager to copy it from EXT4 to the eXFAT partition.

[namtih]

Regarding NTFS:
Try the mount option "big_writes". For me it drops the CPU usage of the NTFS-3G driver from ~35% -> ~5%. So much more CPU left for the Pi and XBMC.
http://www.tuxera.com/community/ntfs-3g-faq/#highcpu

Fstab example:

Code:

UUID=DA20B   /mnt/hdd   ntfs-3g   defaults,noatime,nodiratime,async,big_writes  0   0

Another option would be to get this alternative NTFS driver up and running:
http://forum.xbian.org/thread-186.html

[Alastaire]

Well it is a good found and NTFS has great working but give over power to it so that it could work properly and every device should remain balance in every aspect.