[SOLVED] ESPRESSObin "sysupgrade"

Mine has always been stable.

I only just upgraded from OpenWRT 19.07 (linux 4.14) to 21.02 (5.3) yesterday. No problems at all. I've been running previous versions of OpenWRT for about 4 years on this hardware.

Hmmm - interesting. Wondering if this is related to the U-Boot (version)? I updated mine to the latest ... you? Or, is it just a bit different on different HW?

The GitHub thread suggests there is some chip to chip variation, though they again seem to be talking about the 1.2GHz variant used in the later models.

1 Like

That makes sense, thanks!

Now that 22.03 is released I'll try it this week. Hopefully still stable out of the box.

1 Like

I have several questions, I hope someone can help me solve them:

-How recommendable is a second hand espressobin v7 for 60 dollars today?
-What would be a reasonable price?
-How fast is it running SQM?
-In the new stable version of OpenWRT will latencies have improved or was this problem only with the Nanopi R4S?

Great, thanks!

The Espressobin is a good device if it fits your needs - WAN port, two LAN ports, and no WiFi. You can buy it new at https://globalscaletechnologies.com/product/espressobin/ for $80 (plus more for an enclosure and power supply) so up to you if $60 is a good price.

I have a 250/25Mbit internet connection and SQM is running ok, although I rarely saturate the connection for long. I have no problem with latency - what is the issue with the Nanopi?

I just did a transfer test using iperf3 from one VLAN to another, routed via the Espressobin, and got 600Mbit/sec. iperf3 to/from the Espressobin itself does 900Mbit/sec.

1 Like

Thanks for your response.

The problem with Nanopi R4S is high latency:

In my router i have maximum 0.206 ms of latency, with other routers like a Nanopi R4S this can be worst, i was referring to that.

Ping test to loopback in my router

root@OpenWrt:~# ping
PING ( 56 data bytes
64 bytes from seq=0 ttl=64 time=0.206 ms
64 bytes from seq=1 ttl=64 time=0.164 ms
64 bytes from seq=2 ttl=64 time=0.164 ms
64 bytes from seq=3 ttl=64 time=0.166 ms
64 bytes from seq=4 ttl=64 time=0.162 ms
64 bytes from seq=5 ttl=64 time=0.165 ms
64 bytes from seq=6 ttl=64 time=0.178 ms
64 bytes from seq=7 ttl=64 time=0.168 ms
64 bytes from seq=8 ttl=64 time=0.166 ms
64 bytes from seq=9 ttl=64 time=0.165 ms
64 bytes from seq=10 ttl=64 time=0.165 ms
64 bytes from seq=11 ttl=64 time=0.163 ms
64 bytes from seq=12 ttl=64 time=0.167 ms
64 bytes from seq=13 ttl=64 time=0.162 ms
64 bytes from seq=14 ttl=64 time=0.159 ms
64 bytes from seq=15 ttl=64 time=0.145 ms
64 bytes from seq=16 ttl=64 time=0.152 ms
64 bytes from seq=17 ttl=64 time=0.165 ms
64 bytes from seq=18 ttl=64 time=0.163 ms
64 bytes from seq=19 ttl=64 time=0.162 ms
--- ping statistics ---
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max = 0.145/0.165/0.206 ms

As far as I know this latency is ok not the best but nothing to worry but the nanopi r4s has double or even more latency.

For now i have a linksys e8450 (works very well), but i was wondering to buy some more powerfull like a Nanopi R4S, but high latency is a problem for me.

I don't want problems like the ones I had with a tp-link router that didn't support openwrt and the stock firmware was rubbish, it gave me very bad latencies and I even lost internet access for a few seconds and had to restart the router.

I want a powerful router that can run QoSify, Adguard Home, Wireguard, Samba and other things, so I want something powerful but I don't want latencies to be an issue. Although I don't think it's as terrible as what happened with the tp-link router that had a Qualcomm Atheros TP9343 SoC and the problem was with the TP-Link firmware, it had version 2 of this router and it didn't support openwrt, which They had v1 that was compatible with Openwrt and confirmed that flashing Openwrt worked much better.

I see. It's the same on my Espressobin v5:

root@router:~# ping localhost
PING localhost (::1): 56 data bytes
64 bytes from ::1: seq=0 ttl=64 time=0.630 ms
64 bytes from ::1: seq=1 ttl=64 time=1.815 ms
64 bytes from ::1: seq=2 ttl=64 time=1.773 ms
64 bytes from ::1: seq=3 ttl=64 time=1.860 ms
64 bytes from ::1: seq=4 ttl=64 time=0.784 ms
64 bytes from ::1: seq=5 ttl=64 time=0.798 ms
64 bytes from ::1: seq=6 ttl=64 time=0.795 ms
64 bytes from ::1: seq=7 ttl=64 time=0.817 ms

The latency is lower when the CPU frequency is higher, but I am using the ondemand governor.

Can I ask why this matters? Unless you are doing high frequency trading, you won't notice it.

None of those applications will suffer due to half a millisecond more ping. Also I don't think it's a good idea to run Samba on the router.

1 Like

to be honest it's pure idiocy to want the best, I really know that I can't differentiate fractions of a millisecond.

Although the problem with the tp-link router did leave me with a terrible experience and thanks to that problem I discovered openwrt, so it wasn't all bad, at least I discovered openwrt.

Why do you say it's not a good idea to run samba on the router? is it because of vulnerabilities and ransomware?

Would you recommend me to buy a better NanoPi R5S? Look at the comparison of the SoCs and if I remember correctly the R4S was better, but the truth is that you can tell me with certainty which one to buy between the R4S and the R5S, I think that the power of the espressobin v7 is outdated and it is not a good business buy today.

Although your comments are welcome since I am assuming many things without really knowing the subject.

I think it is good to separate your networking / routing / firewall from other services, for both security and reliability reasons. My Espressobin does nothing but networking. I have other ARM systems doing file and media sharing.

I don't know the R5S but if it suits your needs and the price is good then get it. It looks like an updated version of the Espressobin in some ways, with a quad core CPU running at higher clock speed.

The latency measurement is to do with power saving and not something you will ever notice in real life. I have had the Espressobin for 4 years and I never noticed this ping measurement before. The solutions in that other thread all make the CPU use more power and run hotter, just to solve a problem that isn't real.

1 Like

I upgraded yesterday. It's been up 19.5 hours, no issues. I ran stress on it for a while to hammer it too.

1 Like

Excellent, thanks! FYI, if I try to use ondemand => often reboots before I even get in to the console :frowning_face:

:frowning: Well if it's stable with 'performance' then I guess that's ok. It might run a bit hotter and use a bit more power but probably barely noticeable.

1 Like

Agreed! And it seems only ~ 36C (sensors), so all is good there.

Arrgh, but now, trying to sysupgrade ... and it won't work without force, but also not with force. Are you able to sysupgrade (to squashfs, MicroSD)?


How do you read the sensors?

I'm using ext4 on micro SD, and I've always used sysupgrade. Even the 19.07 to 21.02 upgrade worked with sysupgrade though it was meant to complain about the DSA transition.

I installed lm-sensors, using that.

OK, let me try moving to ext4. Thanks! BTW, I assume that you always gracefully shut down?

Thanks, didn't know that worked. I found the sensors in /sys by hand, but they are only the switch sensors and not the SoC I think. I did a stress test and I don't see the temperature changing.

Mine reads as 47 degrees.

I never shutdown, except power failures and upgrades.

Oh and nothing should be written to the root file system during normal operation anyway; the log, leases file and so on are all kept on tmpfs in RAM.