Tuning Samba

Black Hole

May contain traces of nut
After a long slog (which I will write up in my Trail Guide blog before long), I eventually had my HDR's drive contents decrypted and an SMB link between the HD and the HDR, and lo and behold I could navigate the HDR internal and external drives as if they were attached directly to the HD by USB. Almost.

The purpose of doing this (in case anybody hasn't been keeping up) is to circumvent the 4GB bug in the Humax DLNA client code, which cuts off streaming playback at the 4GB point in any file that is at least 4GB in size (due no doubt to somebody making a schoolboy error and using a 32-bit variable to index the file).

The problem with my SMB link is that the HiDef playback (which the native DLNA plays fine - up to 4GB) is jerky and the sound breaks up. The same is true when played using Splash Player Lite on a PC (via a windows file share), which I had at first attributed to WiFi or the processing power of my PC. The common link in these two configurations is the network itself (which includes a HomePlug AV200 link, but the network is also common to the DLNA playback which works fine) and the SMB service on the HDR.

So, the question is: is the samba package fundamentally slow, or are there some tuning configuation settings that can be tweaked? Answers on a postcard...

Anyone wishing to follow in my footsteps start HERE (click).
 
Yeah, we can joke... but experience shows people just dip in - and although I'm boring the pants off everyone else I think it necessary to "set the scene".

(I'm not having a go at you for having banter with me - please carry on!)
 
Samba should be upto doing the job in theory. Obviously there is a lot of overheads required to translate the file into SMB packages, transmit them accross the network, and then convert them back into a usable format. I'm not sure the processor in the box is going to be upto this as its not going to have been designed with this in mind. That said the newer versions especially of Samba (in the last 10 years or so) have been very quick indeed, and in many places have replaced what was the UNIX standard of using NFS.

I'm sure there are some tweaks that can be used - the most notable one is adjusting the block size so that more data is sent per package, however this will prevent legacy Windows machines (i.e. preior to XP SP3 I think) from being able to read the data. I'm a good 200 miles away from my box at the moment so Im not goig to be able to look into this for a while, but hopefully somebody else will be able to sooner.
 
I have my Humax HD mounting my HDR now using cifs/samba and I'm watching a decrypted hi-def recording of Frozen Planet from BBC One HD with no problems. It isn't even using a vast amount of bandwidth:

Code:
  5 minute input rate 4981000 bits/sec, 451 packets/sec
  5 minute output rate 183000 bits/sec, 274 packets/sec

well within the capability of my home plugs which I think are running at about 120Mb/s - I don't often check!
 
I tried stressing the HDR by decrypting a couple of recordings while recording two channels and playing something back on the HDR at the same time as watching the programme on the HD and it coped fine (the fan came on!) - no drop-outs nor any jerks, sorry.
 
Oh bum. So where do I go from here? I can lash a direct connection to eliminate the network, but that does not explain perfect playback by DLNA.

Re Windows legacy - not a problem here. I'm only likely to use Win7.
 
but that does not explain perfect playback by DLNA.

Yes it may do - How are you connecting the boxes together? I was assuming that like me you have ripped up all your floors and laid down loads of cat6 cable around your house :)

SMB file transfer has loads more header data in it than DLAN does so to transmit x amount of data you actually use more bandwidth up than x, and the extra amount is more with SMB than DLAN, as SMB has lots of extra stuff for users auth etc in it etc.

Hence if your almost at the limit of your network with DLAN, you may have just gone beyond what you connection can take.

If your on wifi/power cable addapters try an ethernet cable!
 
Given my results, I think you have to try a wired connection to eliminate everything else. I tend to agree with James, it could just be that DLNA just works and Samba tips it over the edge. My experiments seem to indicate that the HDR box is not approaching a limit. Do you have a way of seeing what your powerline adapters are up to?

I have Cat6 cable to most places but with solid concrete floors downstairs I've resorted to powerline adapters in a couple of instances and don't have any problems. My connectivity is HumaxHDR-Cisco switch-powerline adapter pair-Netgear switch-patch panel-wall port-HumaxHD, so at least we know that Samba sharing works with a non-direct connection..
 
Oh bum. So where do I go from here? I can lash a direct connection to eliminate the network, but that does not explain perfect playback by DLNA.
Bit of a long shot. Have you tried running 'top' recently to make sure that nothing is 'hogging' one of the CPUs?
 
I've not tried any scientific tests, but file transfers felt a lot quicker for me when I switched from samba to nfs. This was with a mac though, so the bottleneck could have potentially been with Samba in Snow leopard. In Osx Lion,

We could maybe get some better performance if we could get the latest version of Samba (3.6) built, which supports smb2. I'm fairly sure we are currently running with old protocols, as when Samba was dropped from OSx lion in favour of apple's own "SMBX "implication (which only works with winXP SP3 or later), it stopped working with Samba on the Humax. The reason they won't talk seems to be that SMBX only supports newer faster smb protocols, and samba on the hummy doesn't. I did have a stab at compiling Samba 3.6 some time ago, but got stuck rather quickly - I'm not too familiar with the processes of configuring and compiling these cross platform packages...
 
I did have a stab at compiling Samba 3.6 some time ago, but got stuck rather quickly - I'm not too familiar with the processes of configuring and compiling these cross platform packages...
I tried to cross-compile it probably around the same time as you. My attempt also failed due to some problems with the build script. I didn't try compiling it natively on-the-box though. In the end it was easier to get NFS working.
 
Yes, it does seem to be a bit of a b*gger to cross compile! I might keep at it for a little while though. @xyz321 can you send me the configure options you used for the old version?
 
I have Samba 3.6.3 compiled so I'll see if it's any better... I did only need 6Mb/s to watch Hi-Def over samba though.
 
Well what do you know. I bypassed the HomePlugs with a long Cat5 to the router, and the problem goes away. Splash on the PC still struggles, but even with Splash running concurrently with the HD-FOX, playback on the HD-FOX was still OK. I guess that vindicates Samba.

Rather annoying if (as it seems) the extra load imposed by the Samba share over and above the DLNA stream is just sufficient to break my network. Perhaps my advice that "200Mbps HomePlugs should be fast enough for anybody" is misplaced.
 
It depends what speed your homeplugs are running at.. they usually come with a utility that you can run on a PC at one end or the other to find out.
 
Thinking about it, it's much more likely to be a problem with the quality of the link rather than the speed (we know that you don't need that much speed).

You can bet that the DLNA client software buffers the stream and can smooth out any jitter in the data stream, but why would Humax bother to do that when playing something off the local disk (which is what it thinks it is doing with the Samba solution)?
 
Back
Top