For some reason, ethtool will not change to a speed that the adapter is capable of.
Attempting to change Auto-negotiation to off results in a total system lockup, the only way out being a hard shutdown.
I'm at this moment running the same rsync job that took over 18 hours (first time) the last time I ran it ie: before switching all the patch cables for new CAT5e ones and as a result getting the iperf speeds I reported in my previous post:
groucho@devuan:~$ iperf -c 192.168.1.3
------------------------------------------------------------
Client connecting to 192.168.1.3, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.2 port 35408 connected with 192.168.1.3 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 771 MBytes 646 Mbits/sec
pcl@devuan:~$
But something seems amiss ...
My conky panel is reporting a speed of 7.46MiB /s
Incoming: 114KiB /s
Outgoing: 7.46MiB /s
The NAS's CPU/Memory load at this moment are these:
PID Owner CPU Mem Process
213 root 9% 0% kswapd0
1904 root 67% 0% Dropbear
1905 root 0% 7% rsync --server
1906 root 22% 13% rsync --server
I've checked with ethtool again and both links (box and NAS) are negiociated at 1000Mb/s Full Duplex.
So ...
Why the 7.47MiB /s?
Shouldn't it be 7 or 8 times higher?
Maybe the NAS CPU is maxed out?
ie: kswap 9% + Dropbear 67% + rsync 22% = 98%
My rsync stanza is this:
time rsync -a /media/bkups root@192.168.1.3:/mnt/sda3
Added time so I can leave it running and know just how much time it took to finish.
Apparently rsync is tunneled through ssh. Which means encryption is added, which is expensive. To stream data fast, you can use a netcat tunnel. https://linuxhint.com/use-netcat-to-transfer-files/. But rsync won't support that.
Must be, Dropbear is OpenWRT's de-facto SSL2 client/server application.
But I don't really neeed encryption as it is all local traffic.
ie: going nowhere else but from a back-up drive inside my box to the NAS under my desk.
But I do need rsync.
Given the CPU/Mem this board has, a 67% load is expensive.
ie: APM82181 @ 800 MHz + RAM 256 MB
No. Theoretically it could, but cypher 'none' is not supported. But you can run an rsync daemon, which is available as package rsyncd. A bit less convenient than an ssh tunnel (which doesn't need any configuration at server side). More here: https://linuxconfig.org/how-to-setup-the-rsync-daemon-on-linux
The WD-MBL, save for the HDD/SD card difference, seems to be much heftier.
Could I be able to get at least his 10.0Mb/s?
To my chagrin, I have not been able to make heads or tails of what he did.
The link you've provided me with will surely have clearer instructions. ;^ )
Thank you very much for your input.
I'll try to get this set up asap and report on how I do.
:~$ sudo hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
Model Number: WDC WD10EURX-63FH1Y0
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
--- snip ---
:~$
You're still going through dropbear/ssh, not to the rsyncd directly, which explains the low speed and high load caused by dropbear.
Contacting an rsync daemon directly happens when the source or destination path contains a double colon (::) separator after a host specification, OR when an rsync:// URL is specified
(You will need to set up the "sources"/"destinations" in /etc/rsyncd.conf, it will only work with defined destinations, not with random directories. See the manpage for that.)
I got around 20 MB/s between two MBLs using rsync ... with 18.06, back when I last consciously benchmarked it. Still not blazingly fast, especially compared to the speeds I got with rsync on the original firmware, there's probably room for optimization. But it can certainly do better than what you're getting right now.
I see.
Got the syntax wrong. :^/
I'll check the man page again and see if /etc/rsyncd.conf is correctly set.
I have not found straightforward examples on the web.
Still 3x times what I'm getting now.
I just recalled a post by you from back in 10/18.
Came across it when I was having issues installing OpenWRT on the MBL.
Your post is from when OpenWRT was using kernel 4.19, we're at 5.41.
Seems the apparent speed limit was never taken care of.
Maybe the OpenWRT firmware is also responsible for the low speed I get with iperf. ie: ~645 Mbits /sec between my box and the WD-MB NAS.
Or maybe it is the driver?
groucho@OpenWrt:~$ ethtool -i eth0
driver: ibm_emac <---- ###
version: 3.54 <---- ###
firmware-version:
expansion-rom-version:
bus-info: PPC 4xx EMAC-0 /plb/opb/etherne
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
groucho@OpenWrt:~$
What version is the ibm_emac driver at now?
I'll check then rsync syntax/.conf file and see what I can get.