leenuxg33k wrote:

does tcpdump or ethereal come with osx? If so its real easy to use tcpdump.

tcpdump -s 512 -w networkdump.bin

Thanks, leenuxg33k. The command does come with OS X, and I have the file generated (I let it run for a couple of minutes while I was playing an mp3 on the Roku and then hit control C to stop). Don't know how to interpret what's in the file, though.

OK, some clues; looks like it may be some sort of setting issue.

Back when I had last tested SMB transfer rates, I was running 10.4.2 on my mac and getting rates of 17-20 Mbps (which I guess is a little low but approximately normal). Before I upgraded to the 2.0.36 firmware, I ran the tests again (I now have 10.4.3 on my Mac) and got rates of around 10 Mbps. Not sure if the difference has to do with the update to OS X, but 10.4.3 definitely changes something with the NFS server on my mac; now I can't even mount a shared NFS directory on my local machine (but I digress).

After the updgrade to 2.0.36, as I mentioned before, I couldn't even measure the transfer rates. I was about to reinstall 2.0.35 this morning, but decided to take a look at my /etc/smb.conf file on my mac, and I noticed the following line which I had commented out:

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=2048 SO_RCVBUF=2048

This came from some post a few months ago here on the forums, and was supposed to speed up SMB transfer rates. In my hands, it made things considerably worse, so I commented it out. I decided to try, just for yucks, enabling it again, and my SMB transfer rates went back to 7 Mbps. Not great, I know, but at least it was working.

I've tried setting the two buffer options at 16384, which I gather is the new segment size in 2.0.36, but it hosed things again. I'm currently running with these two buffers at 4096 and getting transfers at 17.6 Mbps. I can play around with the segment size settings on both the mac and the Roku, but I don't really know what I'm doing and I'm a little nervous.

Any other mac users out there have any suggestions on what to do here? Or any of the Unix users have any suggestions on how I might change the smb.conf file so that things work better?

Here's what I get when I set the "segment=" option in /etc/smbprefs, on the Roku, and the "SO_SNDBUF=" and "SO_RCVBUF=" options in /etc/smb.conf on the mac, to various settings. Transfer speeds were tested in quadruplicate and are measured in Mbps; the high speeds were tested with a 105 MB file, and the low speeds were tested with a 35 KB file.

4096: 20.8, 13.8, 13.7, 13.7
8192: 0.25, 0.22, 0.10, 0.27
16384: 0.14, 0.11, 0.26, 0.27

Anyone have any idea what's going on?

chackett wrote:

Here's what I get when I set the "segment=" option in /etc/smbprefs, on the Roku, and the "SO_SNDBUF=" and "SO_RCVBUF=" options in /etc/smb.conf on the mac, to various settings. Transfer speeds were tested in quadruplicate and are measured in Mbps; the high speeds were tested with a 105 MB file, and the low speeds were tested with a 35 KB file.

4096: 20.8, 13.8, 13.7, 13.7
8192: 0.25, 0.22, 0.10, 0.27
16384: 0.14, 0.11, 0.26, 0.27

Anyone have any idea what's going on?

Even your good speeds aren't that great, but those slow speeds are just amazing.
What exactly does your figures mean, what are you changing the values of SO_SNDBUF etc. to be?

This article here
http://www.dd.iij4u.or.jp/~okuyamak/Documents/tuning.english.html

does mention that changing the values for this can result in awful performance.

soiaf wrote:

Even your good speeds aren't that great, but those slow speeds are just amazing.
What exactly does your figures mean, what are you changing the values of SO_SNDBUF etc. to be?

Amazing isn't the word I had in mind

The SO_xxx settings are being changed to 4096, 8192, or 16384 (matched with whatever the segment setting was on the Roku).

chackett wrote:

Amazing isn't the word I had in mind

The SO_xxx settings are being changed to 4096, 8192, or 16384 (matched with whatever the segment setting was on the Roku).

Have you tried picking one value of segment on the Roku, and then try a few different buffer values on the Mac (both smaller and bigger)?

soiaf wrote:

chackett wrote:

Amazing isn't the word I had in mind

The SO_xxx settings are being changed to 4096, 8192, or 16384 (matched with whatever the segment setting was on the Roku).

Have you tried picking one value of segment on the Roku, and then try a few different buffer values on the Mac (both smaller and bigger)?

No; I don't know anything about networking, but having different segment sizes seemed counterintuitive to me. Where would you recommend I start?

chackett wrote:

No; I don't know anything about networking, but having different segment sizes seemed counterintuitive to me. Where would you recommend I start?

Intuitive? What has that got to do with linux/networking?

Try segment 16384, with buffer of
4096, 8196 and 32768

soiaf wrote:

Try segment 16384, with buffer of
4096, 8196 and 32768

In triplicate this time, since we're looking at large differences:

buffer 4096 yields 17.0, 17.4, 17.3
buffer 8196 yields 0.21, 0.10, 0.19
buffer 32768 yields 0.11, 0.20, 0.19

Well, buffer at 4096 looks a lot better (though not great relative to where it should be).

Could you try a different value for the buffers i.e.
the send buffer being 4096 and the receive buffer 8192

Got the same results: 17.5, 16.7, 17.4.

Interestingly, I found a post on www.macosxhints.com that suggested using the SO_KEEPALIVE socket option, so I tried adding it to my smb.conf file. If the Roku has just been rebooted, I get good transfer speeds (26.9), but they only work the first time. When I run the test a 2nd and 3rd time, I get speeds in the 16-17 range, until I reboot.

As most computer problems things happen amazingly at the same time. I haven't done much, rebooted both roku and my router and the problem seems to have gone away.

Still able to play a DVD movie wirelessly, without stutters.

chackett wrote:

Got the same results: 17.5, 16.7, 17.4.

Interestingly, I found a post on www.macosxhints.com that suggested using the SO_KEEPALIVE socket option, so I tried adding it to my smb.conf file. If the Roku has just been rebooted, I get good transfer speeds (26.9), but they only work the first time. When I run the test a 2nd and 3rd time, I get speeds in the 16-17 range, until I reboot.

If I'm looking at the same article they seem to suggest

TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_SNDBUF=8576 SO_RCVBUF=8576

Well, at least at this stage you know how to get your setup to a usable state, but this whole SMB configuration seems to be full of pitfalls and hidden knowledge.

soiaf wrote:

If I'm looking at the same article they seem to suggest

TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_SNDBUF=8576 SO_RCVBUF=8576

Well, at least at this stage you know how to get your setup to a usable state, but this whole SMB configuration seems to be full of pitfalls and hidden knowledge.

Thank god; last night I actually had to find some CDs and put them in the player (shudder)

And yeah, that's the article. I tried the 8576 setting but it hosed the transfer rates again.

I would agree that this is more complicated than it appears; I think I'm having some sort of Mac-specific configuration issues. I found some more suggestions on macosxhints; I'll try them out and post the results (if they improve things) for the benefit of my mac brethren (although they're a silent bunch if they're out there). Thanks for your help.

Well, I upgraded this morning from .35 to .36 and am VERY happy with the results! My server is a Mac Dual G4 (runing 10.3), using built-in SMB sharing.

I have some HDV (1080i, edited on iMovie HD from a Sony HDR-HC1) movies that MPLAY info show as 27.9 mbps. The previous version (.35) would always stutter video and play only 2 seconds of sound. Now with .36 I have played over 30 minutes of video (four different TS files) with perfect results - no stuttering, clear video, no problems!

Thank you RokuDave so much! This makes my HD1000 finally do what I most want to do -- play HD movies from my server! -steve-