Can a pocket router go fast? (GL-AR750)

With a GL-AR750 I had laying around, I wondered what fun project I could do with it. I then figured that with a USB 2.0 port AND a micro-sd card this could be a small NAS to duplicate some backup!

This could be the perfect device for an off-site backup. Even if I already knew that it would not be blazing fast, I wondered what kind of performance this small package could handle!

The specification of this small little router look like :

  • A small linux OS (openWRT)
  • 650 Mhz single core processor (QCA9531)
  • 16 MB of flash storage!
  • 128 MB of DDR2 Ram
  • 802.11a/b/g/n/ac
  • 3 Ethernet ports
  • One Micro usb port
  • one USB 2.0 port

Yes, Quite the little device!

I began by benchmarking an SD card to know what performance it could reach without being limited by the Micro Usb port of the AR750. I obtained something like :

the base benchmark of the sd card

So about 22 MB/s read speed and 14 MB/s write speed.

Before testing the sd card, I ran a quick Iperf3 benchmark just to make sure that the device could handle a synthetic load on its network interface.

mathieu@LINUXPUTER:~$ iperf3 -c -f K
Connecting to host, port 5201
[  5] local port 48898 connected to port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  12.6 MBytes  12877 KBytes/sec    0    471 KBytes       
[  5]   1.00-2.00   sec  11.5 MBytes  11736 KBytes/sec    0    471 KBytes       
[  5]   2.00-3.00   sec  11.4 MBytes  11675 KBytes/sec    0    471 KBytes       
[  5]   3.00-4.00   sec  11.4 MBytes  11674 KBytes/sec    0    471 KBytes       
[  5]   4.00-5.00   sec  10.5 MBytes  10702 KBytes/sec    0    471 KBytes       
[  5]   5.00-6.00   sec  11.4 MBytes  11674 KBytes/sec    0    471 KBytes       
[  5]   6.00-7.00   sec  11.4 MBytes  11675 KBytes/sec    0    471 KBytes       
[  5]   7.00-8.00   sec  10.5 MBytes  10701 KBytes/sec    0    471 KBytes       
[  5]   8.00-9.00   sec  11.4 MBytes  11675 KBytes/sec    0    471 KBytes       
[  5]   9.00-10.00  sec  11.4 MBytes  11674 KBytes/sec    0    471 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   113 MBytes  11606 KBytes/sec    0             sender
[  5]   0.00-10.04  sec   111 MBytes  11364 KBytes/sec                  receiver

iperf Done.

That seems good, I was using the 100 mbits ethernet port so this was also expected to cap around this speed. While running the Iperf3 benchmark the cpu was pinned at 100% … so yeah I wasn’t expecting to reach that kind of speed with the sd card.

First try : scp

I began by running the most basic scp command to get a first impression on what kind of performance I would get :

For the writing speed I did :

scp -v linuxmint-20.2-mate-64bit.iso root@
linuxmint-20.2-mate-64bit.iso   2%   56MB   4.4MB/s   07:34 ETA

For the reading speed test I did the inverse command and got :

scp -v root@ ./testiso.iso
linuxmint-20.2-mate-64bit.iso                                                                                               2%   60MB   5.0MB/s   06:37 ETA

The htop view while running SCP

The thing I noticed for both these tests was how the dropbear was using most of the cpu instead of the scp command. I also wondered why the read speed was hitting a ceiling at 5.0Mb/s.

I assumed that high cpu usage of the dropbear process was because of the encryption and wondered if I could get something a little bit faster by having a quicker SSH encryption. Sadly openWRT doesn’t contain much cypher so I didn’t get better results.I then wondered if using an other program could yield me quicker results.

Second try : rsync

I then wondered if I could gain any speed by just using rsync instead of scp. I changed my basic scp function for the equivalent basic rsync function :

For the writing speed I got :

$rsync --progress linuxmint-20.2-mate-64bit.iso root@
sending incremental file list
    221,904,896  10%    3.26MB/s    0:09:35

And for the reading speed I got :

$rsync --progress root@ ./testfile.iso
    336,035,840  15%    3.74MB/s    0:07:52

The htop view while running rsync this time

This was actually quite underwhelming in term of speed. I was expecting at least the same speed as SCP and maybe a slight advantage, but I did not expect a downgrade in performance. Fortunately, the time spent researching information on rsync made me stumble onto something really interesting. Rsync has a tcp protocol to talk from an Rsync client to a Rsync daemon.

Third try : The rsync protocol

On the server I installed the rsync daemon using the openWRT package manager. I then modified the /etc/rsyncd.conffile so that it contained :

# Minimal configuration for rsync daemon

# Next line required for init script
pid file = /var/run/
log file = /var/log/rsyncd.log

# Basic shared folder
path = /mnt/sda1/download
read only = false

An rsync client can then access the test_dir folder and read/write to it. On the client I then ran similar command as before, but this time using the rsync:// protocol :

$rsync --progress rsync:// ./testiso.iso
    667,385,856  31%    6.08MB/s    0:03:56

Success!! This time I nearly doubled my previous download speed! The thing to know is that by default this protocol isn’t really secure so you need to add a password to your network share.

The biggest win of all is that the cpu on our small server wasn’t even capped at 100% so there must be another bottleneck now!.

htop of the transfer when using the rsync protocol

Just for fun I tested the write speed onto our little server and the speed was more than decent… and I actually really don’t understand how this could be possible.

rsync --progress ./linuxmint-20.2-cinnamon-64bit.iso rsync://
    213,155,840   9%    9.16MB/s    0:03:27

We were almost reaching the maximum write speed of our SD card, and we were faster than the reading speed which doesn’t really make sense… I’ll have to dig a little deeper to explain why. The good news is that those speeds were far better than what we initially had, so I consider this a win!

The key takeaway message is that on a small embedded device, there is a good performance boost that can be gained by bypassing the ssh protocol. Just don’t forget to secure your network share if you end up using the rsync daemon!