RT N66U firm. 3.0.0.3_151

[jyavenard]

SMB has a lot of overhead, and uses very small blocks (as the protocol was designed back in the old Windows 3.1 days). It was never designed for transferring large files, even less in a streaming capacity.

DLNA on the other end is designed for streaming, with much less overhead.

DLNA is just UPnP with a fee attached.. It's still crap.

As for SMB using very small blocks or not designed for transferring big files... Sorry but that's just bollocks.
It's samba that by default uses quite small buffers inappropriate of modern network. All of this can be adjusted easily and configuring properly samba will easily give you speed maxing out a gigabit link...
Windows out of the box will perform just fine

Typically adding something like in the global section of smb.conf
socket options = TCP_NODELAY SO_SNDBUF=131072 SO_RCVBUF=131072

You'll see dramatic performance increase.
I do in excess of 90MB/s read over SMB between my disks server (RAID 5 array) over a gigabit link

 

[xrecar]

DLNA is just UPnP with a fee attached.. It's still crap.

As for SMB using very small blocks or not designed for transferring big files... Sorry but that's just bollocks.
It's samba that by default uses quite small buffers inappropriate of modern network. All of this can be adjusted easily and configuring properly samba will easily give you speed maxing out a gigabit link...
Windows out of the box will perform just fine

Typically adding something like in the global section of smb.conf
socket options = TCP_NODELAY SO_SNDBUF=131072 SO_RCVBUF=131072

You'll see dramatic performance increase.
I do in excess of 90MB/s read over SMB between my disks server (RAID 5 array) over a gigabit link

Is there some way to tweak 151 in that manner(is there a command via telnet? Not sure where smb.conf is)- or do you have to do it in something like tomato?

 

[RMerlin]

DLNA is just UPnP with a fee attached.. It's still crap.

As for SMB using very small blocks or not designed for transferring big files... Sorry but that's just bollocks.
It's samba that by default uses quite small buffers inappropriate of modern network. All of this can be adjusted easily and configuring properly samba will easily give you speed maxing out a gigabit link...
Windows out of the box will perform just fine

I'm talking block size, not buffering. SMB block size is limited to 64KB max, which is inefficient in many modern scenarios. That was corrected with SMB2, which was only implemented in Samba 3.6.0.

There are tons of reports in the audio/video circles about SMB being inefficient for video streaming. Most people switch to either NFS or DLNA, because both have lower overhead.

 

[RMerlin]

I finally had time to try out build 151. So far I have to say this is a very good improvement over build 144. I tested some of the bugs I was aware of in build 144:

Fixed:
- IPv6 tunnels no longer leak memory like crazy while transferring large amount of data
- Connecting a Wifi client with SMB sharing enabled (i.e. with GRO enabled) no longer crashes the router
- Multiport virtual servers (ports eparated by a ",") no longer generate invalid iptable rules

Still broken:
- Router crash when accessing a device client over VPN (related to GRO)
- Timezone incorrectly applied to /etc/TZ (and the rest of the firmware) if you don't enable manual DST

It shows they have spent a serious amount of efforts on fixing bugs in the past few weeks. This is a good sign

Now c'mon Asus, I need a newer GPL release to play with

 

[Gingernut]

RMerlin,

I've downloaded and redownloaded your source but I'm still incapable of getting it to build, probably not enough knowledge.

It would be great if you could build a version for the RT-N16 with all the extras you've added and are available in your RT-N66U version.

 

[RMerlin]

RMerlin,

I've downloaded and redownloaded your source but I'm still incapable of getting it to build, probably not enough knowledge.

It would be great if you could build a version for the RT-N16 with all the extras you've added and are available in your RT-N66U version.

I did, but I couldn't find anyone to test it to confirm it actually worked. I'll send you a PM in a minute with a download URL.

 

[M3Rocket]

What does the error message says?

Solved it--thanx. Needed WAN to be connected before being able to change the LAN setting.

How do I tell if DYNDNS is working? Both the username and password field has a red box around it even with the correct username and password.

 

[RMerlin]

Solved it--thanx. Needed WAN to be connected before being able to change the LAN setting.

How do I tell if DYNDNS is working? Both the username and password field has a red box around it even with the correct username and password.

Try nslookup in a command prompt. For example, if your hostname is myhost.dyndns.org:

nslookup myhost.dyndns.org

You will see if it returns an IP - make sure it's the same as your WAN IP.

You might also have more info on the System Log page.

 

[richto]

I'm talking block size, not buffering. SMB block size is limited to 64KB max, which is inefficient in many modern scenarios. That was corrected with SMB2, which was only implemented in Samba 3.6.0.

There are tons of reports in the audio/video circles about SMB being inefficient for video streaming. Most people switch to either NFS or DLNA, because both have lower overhead.

That's because they are Open Source versions and are outdated and not the real thing. SMB V2.1 is faster and more efficient than NFS:

http://silvertonconsulting.com/blog...sis-cifs-vs-nfs-corrected-chart-of-the-month/

"Given similar storage systems, with similar SW, cache and hard disk drives, it’s now clear to me that CIFS provides faster access to data than NFS does, at least on a per spindle basis"

SMB V3 (which is likely RTM in July) is even faster:

http://blogs.technet.com/b/windowsserver/archive/2012/04/19/smb-2-2-is-now-smb-3-0.aspx

http://www.hpcwire.com/hpcwire/2012-06-26/mellanox_releases_infiniband_benchmark_results.html

Try finding an NFS solution that gets even close to 15GB/Sec...

 

[RMerlin]

SMB V2.1 is faster and more efficient than NFS:

http://silvertonconsulting.com/blog/2012/03/27/smb2-2-cifs-screams-over-infiniband/

http://silvertonconsulting.com/blog...sis-cifs-vs-nfs-corrected-chart-of-the-month/

"Given similar storage systems, with similar SW, cache and hard disk drives, it’s now clear to me that CIFS provides faster access to data than NFS does, at least on a per spindle basis"

SMB V3 (which is likely RTM in July) is even faster:

http://blogs.technet.com/b/windowsserver/archive/2012/04/19/smb-2-2-is-now-smb-3-0.aspx

http://www.hpcwire.com/hpcwire/2012-06-26/mellanox_releases_infiniband_benchmark_results.html

Try finding an NFS solution that gets even close to 15GB/Sec...

This is all moot since Asus uses Samba 3.0, which only supports the older SMB 1 protocol. And I did say that those performance issues were fixed in SMB 2...

 

[richto]

Is updating that just a module change? Why would they use such an ancient version?

 

[RMerlin]

Is updating that just a module change? Why would they use such an ancient version?

The majority of low-powered devices still use older versions of Samba, just like they use quite older kernel versions. One of the reasons is because the device manufacturer stick to the software versions that were validated by the platform designer in their SDK (in this case, Broadcom). Since that SDK is a few years old, it looks like it never really got updated.

Also, I remember that newer versions of Samba take much more flash space than 3.0 did. I had to deal with that problem when I updated the Samba version used by WDLXTV. I don't remember what particular change in Samba made it grow so much larger, I think it was something related to ther egistry.

Asus recently added 3.5.8 to the source tree, but they are only using parts of it for AiCloud. I suspect they haven't fully upgraded for the reasons mentionned.

Sadly, Samba is getting a bit on the fat side for low-powered devices with limited flash space. While NAND space is increasing with newer device, I wonder if at some point someone won't come up with a slimmer alternative to Samba - just like almost nobody uses Apache in their devices, but instead look at lighttpd and similar alternatives.

I haven't looked at Samba4 - I wonder if maybe it's more modular, making it easier to use in limited storage devices?

I considered upgrading Samba in my builds, but that will require extensive tests to determine if it introduces any regression. Maybe eventually when Asus once again slows down with the firmware releases.

 

[richardeid]

I did, but I couldn't find anyone to test it to confirm it actually worked. I'll send you a PM in a minute with a download URL.

Would you mind shooting me that link? I went to .144 before ASUS pulled it, but I ran into a show-stopping DNS problem(...it was actually more than just DNS) and had to revert back to .108 for the time being. Everyone seems to like .151 so if you've already compiled it for the N16 then I'll be happy to provide any feedback.

The problem I had with .144 was weird. On a few of my machines I couldn't access any network shares at all. I tried accessing by IP address instead (eg. \\10.10.0.7\music) and that wouldn't work either. But I could RDP into those machines by IP. While RDP'd in, those machines couldn't see out. It was pretty odd. I thought I had goofed something up on my network because I play around a lot, but then it occurred to me to switch back to .108 and it all began working.

I didn't see anyone report any issue like that for .144, though. On here or on VIP. On both the N16 and N66 subforums. Anyway, maybe I missed it somewhere. But I'll still test out .151 on my N16 if you're cool with that.

Thanks.

 

[RMerlin]

I'd rather not send the link to too many persons, as I don't know yet if it even works But if it does, I'll make a proper public release.

 

[Gingernut]

I did, but I couldn't find anyone to test it to confirm it actually worked. I'll send you a PM in a minute with a download URL.

Amazing!

Thanks

 

[Gingernut]

Would you mind shooting me that link? I went to .144 before ASUS pulled it, but I ran into a show-stopping DNS problem(...it was actually more than just DNS) and had to revert back to .108 for the time being. Everyone seems to like .151 so if you've already compiled it for the N16 then I'll be happy to provide any feedback.

The problem I had with .144 was weird. On a few of my machines I couldn't access any network shares at all. I tried accessing by IP address instead (eg. \\10.10.0.7\music) and that wouldn't work either. But I could RDP into those machines by IP. While RDP'd in, those machines couldn't see out. It was pretty odd. I thought I had goofed something up on my network because I play around a lot, but then it occurred to me to switch back to .108 and it all began working.

I didn't see anyone report any issue like that for .144, though. On here or on VIP. On both the N16 and N66 subforums. Anyway, maybe I missed it somewhere. But I'll still test out .151 on my N16 if you're cool with that.

Thanks.

Don't know if you tried it but Asus also released a .151 build for the RT-N16.

For me it seems quiet stable and the network discovery problem that .144 had are fixed.

http://www.asus.ru/ftp/NW_TO_TEST/RT-N16_3.0.0.3_151.trx

 

[jyavenard]

I haven't looked at Samba4 - I wonder if maybe it's more modular, making it easier to use in limited storage devices?

Samba4 is more than just a file server. It's a whole Windows Active Directory replacement.
It's *much* bigger than samba3, requires the use of BIND (named) to work and various external utilities.

As to make samba3 fast, it's just a matter of editing the default smb.conf and adding the line I provided earlier.
performance gain will be massive and running on the appropriate hardware will maxout a gigabit link

 

[jyavenard]

I did, but I couldn't find anyone to test it to confirm it actually worked. I'll send you a PM in a minute with a download URL.

I compiled a RT-N16 image of the 144 using your source.
was just a matter of calling make rt-n16

I did have some issues at first, but they were the same as I had to compile the rt-n66 image... Some bits are broken can't recall exactly the details now..

I think it was libusb and another lib that didn't compile properly

 

[AnthonyArmato]

Is anyone else still having issues with 5Ghz speeds ? EVERYTHING I do while connected to 5Ghz is much slower. Not sure what adjustments to try.

I had been disabling 5Ghz but though I'd try to enable it with 151 hoping it was resolved.

 

[RMerlin]

Samba4 is more than just a file server. It's a whole Windows Active Directory replacement.
It's *much* bigger than samba3, requires the use of BIND (named) to work and various external utilities.

As to make samba3 fast, it's just a matter of editing the default smb.conf and adding the line I provided earlier.
performance gain will be massive and running on the appropriate hardware will maxout a gigabit link

But would Samba4 be more modular, allowing device makers to only build a version with a smaller subset of features? Otherwise, this will be another reason for hardware makers to start looking at alternatives to Samba in the future (tho I'm sure the Samba team will continue maintaining the Samba3 branch for quite some time).