Recommended cheap device to support SQM on Gigabit connection

Not a bad definition, but alas not the only one out there.

However goodput still tends to be simpler to measure than say the exact gross limit of a link; after all, goodput is the throughput achieved at the "layer" of interest and if that layer is selected carefully it is easy to measure. E.g. IPv4/6-TCP goodput is not that hard to measure (which is why almost all speedtests measure exactly that), IP goodput is already considerably trickier to measure.

There is also the option of using a raspberry pi400 with an USB3 ethernet dongle... I bought one partly for that purpose, but it turned out it makes a sufficiently usable light load desktop machine that I never got around testing its suitability as router...

You can buy any miniPC on aliexpress with an Intel N4100. They cost less than 200€ and the maxium power draw at full is less than 10W...

There are some good (and bad, IMHO) suggestions in Tips for getting cheap used x86-based firewall with full Gbit NAT (a PC Engines APU) if you are in the US

Even though it says US, some might be available in other regions too.

Indeed, https://m.aliexpress.com/item/1005004166377181.html?spm=a2g0n.productlist.0.0.51c719b0hXtmE6&browser_id=f0d1e96512cd42c4b53ef0b24bb1c01a&aff_trace_key=&aff_platform=msite&m_page_id=0011804242019319d1847061e0103997176c998e1c&gclid=

With a UE300 would compete very well with RPi4 and there are plenty other options

but he said in a range of 60/100$
from my point of view, for this price, the closest is a used RT3200, or if he can find an A8000RU (got mine brand new for 86€). The MT7622 with HW/SW NAT really does sparkles.

We are several at home, and we have never needed a router with SQM. With a Gbit Fiber, SQM is good only to make Benchmarks or things like that, in real life not sure if you really need this. just my point of view with my experience. I'm actually with 1000Mbps/500Mbps Fiber in France.

2 Likes

I post this message because I liked the answer a lot :

2 Likes

Well, that is a valid choice, but whenever your link gets saturated, be it transiently only or continuously, the default FIFO with too deep buffers is going to introduce additional variable latency to your flows. If you can either guarantee that you will never fully saturate your link or that you never use latency-sensible flows (like even interactive web-browsing to some degree) then it is a no brainer to not waste CPU cycles on traffic shaping. If you are not 100% sure traffic shaping might be worth trying out.
The result is a subjective policy decision, ranging from people happier having more throughput or people happier having lower latency under load increases.
Personally, I was shaping my 116/37 link down to 49/33 as that was the maximum rate my router at the time allowed with competent AQM and traffic shaping and for my use-cases the link worked considerably better with sqm than with more capacity but without sqm. But again that was my policy decision and not the only true way... :wink:

thats the definition of Brazil. I live here too. Buy an x86 from aliexpress, like i did. 200 dollars well spend.

With my little knowledge check this out:
FriendlyARM NaniPi R4S. It is said that it can handle 1 Gb/s. There are two different versions, 1 GB and 4 GB of RAM. The 4 GB RAM version is supported by an openwrt built. I would not try the 1 GB RAM version since it's not supported yet. It has a Rockchip RK3399 SoC and 2 x Gb/s RJ45-ports. Very kind people over there in the subforum. It is expected that the device will be included in the next major release.
I've ordered one, which already arrived but did not have time to test ist. It has no Wifi!

Openwrt page:
https://openwrt.org/toh/friendlyarm/nanopi_r4s

Support Forums:

As I said I'm an total noobie, so please dont't take my message for granted, but I would check out the device.

2 Likes

Yes, and a Pony!

1 Like

However goodput still tends to be simpler to measure than say the exact gross limit of a link; after all, goodput is the throughput achieved at the "layer" of interest and if that layer is selected carefully it is easy to measure. E.g. IPv4/6-TCP goodput is not that hard to measure (which is why almost all speedtests measure exactly that), IP goodput is already considerably trickier to measure.

I almost agree. It is very easy to measure something, but whether what you are measuring is meaningful is another matter. At a simple level you can take a standard size dataset and time how long it takes to traverse a connection, but once you start delving into lower connectivity layers, things get complicated. I have spent a long time in my career explaining to people why they don't get the goodputs they expect including:

  • not knowing about start bits, stop bits and parity bits on bit-serial connections.
  • confusing kilobits per second with kilobytes per second
  • confusing Mebibytes and Megabytes
  • not understanding the necessity and effects of bit-stuffing on HDLC connections
  • not understanding why 'transparently' compressed data-links transfer some files a lot faster than others.
  • wondering why they can't get a file transfer rate of 1 Gbit/s on a Gigabit Ethernet
  • wondering why they can't get a goodput of more than a certain very small amount on a Fast Ethernet connection*.
  • wondering why they can't get a file transfer rate of more than a few Megabits per second between the UK and Asia when the connection was an order of magnitude faster (old TCP stack with limited window size)
  • wondering why file transfers were glacially slow and often failed on links with high packet loss rates (TCP exponential back-off algorithm interpreting packet-loss as congestion)

So sometimes, not getting the goodput you expect is because you have the wrong idea of what the goodput should be, and sometimes because a variable you don't know about has affected the system.

All good fun. Sometimes.

*Interface statistics showed a huge collision rate. Turned out to be a bug in link autonegotiation such that one end of the link thought it was full duplex Fast Ethernet and the other end half-duplex. This works at sufficiently low data rates, so the problem is not immediately obvious.

4 Likes

Cheap / SQM / Gbit
combining these 3 words in the same sentence must result in a syntax error/ 404 not found/ BSOD/ Guru meditation..... :sweat_smile:
1 term must be removed for the equation to work.

This is IMHO orthogonal to goodput being relative simple to measure. But I agree estimating the achievable goodput over a given link is considerably trickier... especially since end-users often do not know all relevant information.

+1, I agree, but that is were the fun lives :wink:

1 Like

This is in your price range, available, can route Gigabit with SQM and has low electrical power requirements: NanoPi R4S 4GB with Metal Case. You can add a managed switch and/or an all-in-one wifi router set up as a dumb AP if you need more ports and/or wifi.

Getting through customs may be another matter though. And delivery time can be on the order of ~3 months. Still - it's a great little router once it arrives.

2 Likes

NanoPi R4S would be the way to go. Although you might want to wait for the next full release of OpenWRT for full R4S support unless you don't mind running a snapshot. I've been running a snapshot on mine for months without any issues.

2 Likes

I use the R4S and love it. The thread has a couple of vids of a guy benchmarking it and hitting it with a 1gbps stream. Its an impressive bit of kit. Add in a 1gb switch and a nice dedicated AP and you have a decent home network.

Snapshot only atm with OpenWrt. (It is due with the 22.03 build apparently?)
https://github.com/anaelorlinski/OpenWrt-NanoPi-R2S-R4S-Builds has a nice build with docker in it and a few extra bits.

2 Likes

Nice. I overlooked NanoPi R4S first. I remember there was a board with almost the same name, "NanoPi R4something", which had 2nd ethernet port through a usb controller to cpu. Ie. almost as RPi 4 with a USB-dongle, but one can't change the dongle. The R4S seems to have both real (quote from the above OpenWrt Developer thread):

  • Networking – 2x GbE(RTL8211E 1Gbps - RTL8111H 1Gbps), including one native Gigabit Ethernet, and one PCIe Gigabit Ethernet

(fierce ducking) reveals "NanoPi R4something" is NanoPi R2S.

Still five weeks delivery time is bad. My case in hand. I had a x86 box running OpenWrt in VM for Gigabit link. The box died over five weeks ago, exactly motherboard did. I have kept principle, x86 hw setups are easily replaced by plenty and readily available parts. Not this time, although, living in EU.

Over the five weeks the gigabit link with full-duplex 200 Mbps subscription has been delivered by an old box from PC Engines, the box kept cold for backup. The box can barely handle its interface speed 100Mbps in half-duplex without any kind of shaping or transforming.

However, with SQM and traffic bounded to full-duplex 50Mbps all is well. No home user knows anything or experience any glitches during multiple simultaneous streaming ("teaming") flows. Anything abnormal a home user can notice from, is file transfers. A gamer in house barks always. I haven't kept eye on packet loss counters. I think they are rising not continuously but moderately.

A newly built x86 system is coming from partly used and mostly new components. But I'm not very enthusiastic. Unit size grows, power demand grows, heat management grows, price grows... performance grows. Well, the last one is nice, but net sum goes below zero, I think.

Forgot to mention one feature I was partly after in the new x86 build, the build has option for adding a 10Gbit network interface for stress testing network load on various devices (needs an investment to a switch with 10G interface as well). However, if things goes as they have in recent years, I think, I won't collect the option.

I think hw wise my future lays in low cost SBCs and miniPC boxes. Especially I like the metal case option in NanoPi R4S. Enough for units hand crafted, half made and badly fitting, although, they are way too easy to buy as well.

But getting interfaces of 2.5Gbit and over on SBCs and miniPCs seems hard currently. They exists, at least in product announcements.