Printable View
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
Oleg firmware is usually about 2MB/s faster than the standard firmware.Quote:
Originally Posted by msj33
I get speeds around 8MB/s
and I'm able to stream full hd via both samba and twonky:)
Nice:-) But will this be further improved over time? Or is 8 MB/sec the limit?Quote:
Originally Posted by wpte
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:-)
well... I don't think much higher is possible, unless we're able to overclock it to stable settings.Quote:
Originally Posted by msj33
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:p
still it's quite a difference compared to your plug computer with a 2GHz cpu and the beagleboard with a 720MHz cpu:p
High clock frequencies on small low-energy consuming cpu's can really make a lot of difference.
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.)
guess what: http://code.google.com/p/wl500g/source/detail?r=1414Quote:
Originally Posted by ecaddict
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
Code:cat /.version
1.9.2.7-rtn-r1416
Linux 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 mountd
Code:showmount -e 192.168.1.1
Export list for 192.168.1.1:
/opt 192.168.1.0/24
/mnt 192.168.1.0/24
rpcinfo 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
I got the same rpc list on r1416 as in r1395 (after manual modules load only)Quote:
Originally Posted by ecaddict
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
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.Quote:
Originally Posted by lly
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
Probably, it is bug in our obsolete kernel. Will seek for patch from upstream, but it may take some time.Quote:
Originally Posted by ecaddict
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.
Not needed, sorry it was my mistake again. I forget to lower MTU (I was trying jumbo frame...).Quote:
Originally Posted by lly
I hope that no other leftovers from my older configuration.
So far i could not understand why, 24h/24h not even a problem... Maybe i have lucky with mine ;)Quote:
Originally Posted by wpte
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)?
robocfg not ready for BCM53115 yet, will be fixed later.Quote:
Originally Posted by ecaddict
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.