Amahi Forums

Thanks for the reply, but this may not be new to you, but for someone else who is new may not know.

Odd? What is odd about this. I did some research and applied my findings to my network and it worked. I do not see anything odd with it.

A CPU boost from 1.6Ghz to 2.3Ghz quad-core might give a "slightly" and I mean VERY slight change in data transfer speeds... We're talking mere 0.5MB/s speed difference.

Have you tested this out yourself? Sounds like you never have, and your just guessing. I have applied it, and saw the difference. Hence why I posted my experience here. Otherwise I would not have said anything.

I already have cat5e and cat6 allover my network. That's a no-brainer.

For you and me yes, but for someone else who is new it may not. Thats why I posted all these possibilities to rule these out.


As for your issue, first thing that came to my mind is a driver issue. Apparently you have all the hardware, great, but maybe its a driver issue on amahi. Maybe the Fedora driver needs to be updated.

Just like to encourage the previous person. While much of the information may seem obvious, it is really excellent when writers take the time to write full posts with lots of information. Many users will not be as technically savvy as others, and it's so helpful when posts are written out in full.

Also, I'd like to say that even veterans make mistakes. I've been in the technology game a long time, but somehow on my own home network I constantly have errors that I miss. For example, this thread reminded me to check all my cables. Sure enough, one of my many runs was actually on some old copper. Just plain CAT 5 I must have cut years back. I had missed this in my earlier trouble shooting and it was a good reminder to not over look the obvious.

Thanks.

Out of interest what kind of throughput have you seen since solving your cable issue.

It's important to note that those are limits based on the specifications, and do not represent real world scenarios which include overhead and interaction of all devices involved. Aside from hardware and drivers Samba itself is a notoriously low performer. I garantee you'll never go faster than that but your also unlikely to ever reach it. In practice a really good disc to disc throughput over gig will likely fall into the 77-80MB/s range, that would require fast drives/SSD/raid especially on the writing end. In practice I'd expect consistent results in the 40-50 MB/s range.

SgtFoo, have you checked the partition alignment on those WD greens? Assuming they are 4K advanced format drives, I've seen a 30-40% performance hit on misaligned partitions.

Out of interest what kind of throughput have you seen since solving your cable issue.

It's important to note that those are limits based on the specifications, and do not represent real world scenarios which include overhead and interaction of all devices involved. Aside from hardware and drivers Samba itself is a notoriously low performer. I garantee you'll never go faster than that but your also unlikely to ever reach it. In practice a really good disc to disc throughput over gig will likely fall into the 77-80MB/s range, that would require fast drives/SSD/raid especially on the writing end. In practice I'd expect consistent results in the 40-50 MB/s range.

SgtFoo, have you checked the partition alignment on those WD greens? Assuming they are 4K advanced format drives, I've seen a 30-40% performance hit on misaligned partitions.

Will check the partitions. My LZ is a drive on its own, so I would have assumed everything be ideal.

has anyone tried this?..

Dropt these lines into your smb.conf file to speed up Samba access. Find the Global area section and paste them underneath:

Code: Select all

read size = 65536 read prediction = true socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

Depending on your network card and configuration, this should speed up your LAN transfers at least tenfold.

source: http://tips4linux.com/speed-up-samba-network-access/

and there's this too...(similar)... http://www.randombugs.com/linux/speed-u ... linux.html

read size = 65536
read prediction = true
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

Thanks for the tip.

I will try this as well and let you guys now if I see a difference.

I will do a few tests before and afterwards.

OK guys

I tried adding this to my smb.conf...

read size = 65536
read prediction = true
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

And my speeds dropped

Before I applied those lines I did a quick file transfer of a 4GB file, and it transfered at about 88MB/sec

I applied those lines above and it dropped down to 24MB/sec.

Same for me. It did not improve anything, only worse. Does not seem like a good solution.

same for me... after those added lines, I fell to the KB/s speeds. UGLY!!!

gonna pull those and see what else..

ANY other ideas??

Out of interest what kind of throughput have you seen since solving your cable issue.

Sorry I did not reply earlier. When I pulled out the old cable and plugged in CAT 6 my transfer speeds are now between 40 - 60 MB/s. Earlier they stayed around 10 - 12 MB/s. It looks to me like the cable finally allowed the NIC and Switch to negotiate closer to gigabit speeds instead of 100Mbit.

Sometimes it will spike to 80 MB/s or so, but only when copying single files. When I have multiple files moving it slows right down. Is that a result of my HDs on the other end? I'm using Greyhole and just eSata. No RAID, not SSD. Just plain drives.

Thanks.

At 80 MB/s I think you are approaching average disk transfer rates. Once you start adding in all the overheads of buffering, network traffic, OS latencies, and head seek times, I don't think you should expect it much faster than that.