Reply With QuoteOleg firmware is usually about 2MB/s faster than the standard firmware.Originally Posted by msj33
I get speeds around 8MB/s
and I'm able to stream full hd via both samba and twonky
Junior Member
If the latest Oleg Firmware is quite stable. Can some of you please post some transfer speeds again?
FTP and/or Samba speeds?
At the moment i'm on the old WL500g Deluxe and got transfer speeds ~2 MB/sek
What can you get with your RT-N16 with Standard firmware contra Oleg?
And what is the real potential speeds of the RT-N16?
My goal is to use th RT-N16 as a file/streaming server.
Thanks
Student Computer Engineer
Oleg firmware is usually about 2MB/s faster than the standard firmware.
I get speeds around 8MB/s
and I'm able to stream full hd via both samba and twonky
Junior Member
Nice:-) But will this be further improved over time? Or is 8 MB/sec the limit?Oleg firmware is usually about 2MB/s faster than the standard firmware.
I get speeds around 8MB/s
and I'm able to stream full hd via both samba and twonky
At the moment i'm also looking at other alternatives like the Plug computer 3.0 or the beagleboard.
They both have a extremely low power consumption 24/7/365 use , and a good CPU performance both for streaming and filetransfer.
Please keep posting FTP/Samba benchmarks:-)
Student Computer Engineer
well... I don't think much higher is possible, unless we're able to overclock it to stable settings.
at the moment the rt-n16 runs at 480MHz on every available alternative firmware. Instead Asus suggests it should be able to run on 532MHz (I believe), but when you do that, it's not quite stable
still it's quite a difference compared to your plug computer with a 2GHz cpu and the beagleboard with a 720MHz cpu
High clock frequencies on small low-energy consuming cpu's can really make a lot of difference.
Member
NFS transfer speeds are almost 50% better than Samba. If you can, try to use it. Even increasing clock speed won't gain that much (and NFS can be used also in that case).
NFS write using UDP as transport has some issue though (with RT-N16, with WL-500 it's OK.)
Student Computer Engineer
guess what: http://code.google.com/p/wl500g/source/detail?r=1414NFS transfer speeds are almost 50% better than Samba. If you can, try to use it. Even increasing clock speed won't gain that much (and NFS can be used also in that case
NFS write using UDP as transport has some issue though (with RT-N16, with WL-500 it's OK.)
little update there
dunno if it fixes your problem though...
download it from my thread if you want: http://wl500g.info/showpost.php?p=185468&postcount=1
Member
Code:cat /.version 1.9.2.7-rtn-r1416Linux PC:Code:lsmod Module Size Used by Tainted: P nfs 289648 0 nfsd 246944 1 exportfs 5280 1 nfsd lockd 76272 3 nfs,nfsd sunrpc 186864 3 nfs,nfsd,lockd usb_storage 96032 3 sd_mod 24976 4 scsi_mod 104672 2 usb_storage,sd_mod usblp 16304 0 ehci_hcd 36112 0 ohci_hcd 19856 0 usbcore 138000 5 usb_storage,usblp,ehci_hcd,ohci_hcd nf_nat_ftp 2848 0 nf_conntrack_ftp 8416 1 nf_nat_ftp wl 2051616 0 igs 17936 1 wl emf 22688 2 wl,igs et 58752 0
Code:rpcinfo -p 192.168.1.1 program vers proto port service 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 755 mountd 100005 1 tcp 758 mountd 100005 2 udp 755 mountd 100005 2 tcp 758 mountd 100005 3 udp 755 mountd 100005 3 tcp 758 mountdCode:showmount -e 192.168.1.1 Export list for 192.168.1.1: /opt 192.168.1.0/24 /mnt 192.168.1.0/24rpcinfo with r1395:Code:sudo mount -t nfs -o rsize=32768,wsize=32768,timeo=14,intr,proto=udp 192.168.1.1:/mnt /tmp/RT-N16 mount.nfs: mount to NFS server '192.168.1.1:/mnt' failed: RPC Error: Program not registered
Am I doing something wrong?Code:rpcinfo -p 192.168.1.1 program vers proto port service 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100021 1 udp 32770 nlockmgr 100021 3 udp 32770 nlockmgr 100021 4 udp 32770 nlockmgr 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100021 1 tcp 59618 nlockmgr 100021 3 tcp 59618 nlockmgr 100021 4 tcp 59618 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100005 1 udp 778 mountd 100005 1 tcp 781 mountd 100005 2 udp 778 mountd 100005 2 tcp 781 mountd 100005 3 udp 778 mountd 100005 3 tcp 781 mountd
Forum Guru
I got the same rpc list on r1416 as in r1395 (after manual modules load only)
Don't know what goes wrong on your side, maybe some errors in syslog present?Code:rpcinfo -p 192.168.1.1 program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 905 status 100024 1 tcp 908 status 100021 1 udp 32768 nlockmgr 100021 3 udp 32768 nlockmgr 100021 4 udp 32768 nlockmgr 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100021 1 tcp 48463 nlockmgr 100021 3 tcp 48463 nlockmgr 100021 4 tcp 48463 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100005 1 udp 926 mountd 100005 1 tcp 929 mountd 100005 2 udp 926 mountd 100005 2 tcp 929 mountd 100005 3 udp 926 mountd 100005 3 tcp 929 mountd
Member
Sorry my mistake, I had a script in /opt/etc/init.d/ that was needed earlier but not needed now (that NFS is included in the firmware). That messed up things.
When I try to write to NFS share mounted using UDP, I have the same issue however as earlier. The server does not answer to UNSTABLE writes, and my client hangs on retransmitting the requests.
These UNSTABLE writes seem pretty normal in NFS V3 as explained in http://nfs.sourceforge.net/. Using TCP as transport works, but so much slower than UDP...
What can be wrong?
Code:1 0.000000 192.168.1.169 192.168.1.1 NFS V3 ACCESS Call, FH:0x0308030b 2 0.000423 192.168.1.1 192.168.1.169 NFS V3 ACCESS Reply (Call In 1) 3 0.000463 192.168.1.169 192.168.1.1 NFS V3 GETATTR Call, FH:0xea9b0c51 4 0.000871 192.168.1.1 192.168.1.169 NFS V3 GETATTR Reply (Call In 3) Regular File mode:0644 uid:0 gid:0 5 0.000915 192.168.1.169 192.168.1.1 NFS V3 GETATTR Call, FH:0xea9b0c51 6 0.001281 192.168.1.1 192.168.1.169 NFS V3 GETATTR Reply (Call In 5) Regular File mode:0644 uid:0 gid:0 7 0.001303 192.168.1.169 192.168.1.1 NFS V3 ACCESS Call, FH:0xea9b0c51 8 0.001698 192.168.1.1 192.168.1.169 NFS V3 ACCESS Reply (Call In 7) 9 0.001724 192.168.1.169 192.168.1.1 NFS V3 SETATTR Call, FH:0xea9b0c51 10 0.002165 192.168.1.1 192.168.1.169 NFS V3 SETATTR Reply (Call In 9) 11 0.146254 192.168.1.169 192.168.1.1 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=137b) 12 0.146269 192.168.1.169 192.168.1.1 IP Fragmented IP protocol (proto=UDP 0x11, off=6976, ID=137b) 13 0.146275 192.168.1.169 192.168.1.1 NFS V3 WRITE Call, FH:0xea9b0c51 Offset:0 Len:16384 UNSTABLE 14 0.146342 192.168.1.169 192.168.1.1 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=137c) 15 0.146353 192.168.1.169 192.168.1.1 IP Fragmented IP protocol (proto=UDP 0x11, off=6976, ID=137c) 16 0.146357 192.168.1.169 192.168.1.1 NFS V3 WRITE Call, FH:0xea9b0c51 Offset:16384 Len:16384 UNSTABLE 17 1.545688 192.168.1.169 192.168.1.1 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=137d) 18 1.545702 192.168.1.169 192.168.1.1 IP Fragmented IP protocol (proto=UDP 0x11, off=6976, ID=137d) 19 1.545705 192.168.1.169 192.168.1.1 NFS [RPC retransmission of #16]V3 WRITE Call, FH:0xea9b0c51 Offset:16384 Len:16384 UNSTABLE 20 4.345685 192.168.1.169 192.168.1.1 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=137e) 21 4.345697 192.168.1.169 192.168.1.1 IP Fragmented IP protocol (proto=UDP 0x11, off=6976, ID=137e) 22 4.345701 192.168.1.169 192.168.1.1 NFS [RPC retransmission of #13]V3 WRITE Call, FH:0xea9b0c51 Offset:0 Len:16384 UNSTABLE
Forum Guru
Probably, it is bug in our obsolete kernel. Will seek for patch from upstream, but it may take some time.
About buffers size - as you can see in include/linux/nfsd/const.h, NFSv3 buffer equal to RPCSVC_MAXPAYLOAD which is equal to 1Mb for TCP & 32Kb for UDP. I wasn't dig kernel nfsd deeper, so I can't say more at now.
Member
Not needed, sorry it was my mistake again. I forget to lower MTU (I was trying jumbo frame...).
I hope that no other leftovers from my older configuration.
Senior Member
So far i could not understand why, 24h/24h not even a problem... Maybe i have lucky with mineat the moment the rt-n16 runs at 480MHz on every available alternative firmware. Instead Asus suggests it should be able to run on 532MHz (I believe), but when you do that, it's not quite stable
Member
Is it expected that there will be a similar robocfg as with WL-500gP as the one included in the firmware is acting strange?
Does this also depend on some Broadcom/Asus stuff?
Or is it possible achieving an equivalent functionality via setting in nvram the vlanxports (vlan1ports, vlan2ports,...)+vconfig. E.g. can dual WAN config be done with these (Btw. are you aware of some such tutorial e.g. in English)?
Forum Guru
robocfg not ready for BCM53115 yet, will be fixed later.
Member
There is one issue with Samba that keeps me wondering since long:
It seems that Samba reading speed (when data is read from USB disk via network) is comparable with writing speed (when data is written to USB disk from network).
Actually I've measured that writing is even faster than reading.
Why is it so (what can be the reason)?
Writing has some journaling overhead (I always use ext3).
When NFS is used, reading (as I'd expect) is significantly faster than writing.
But not Samba.
Posting Permissions
