Bug on Speed. Route10

When you change any setting other than “Default” or “Auto” on the network tab, the device gets disconnected and loses its route. To restore normal operation, you have to reset everything back to the default or auto settings.

Here’s an example of an iperf3 test result:

And with the reverse direction:

Notice the download speed drops by about 400 Mbit compared to the upload when using the -R flag.

Additionally, I disabled acceleration, DPI engine, and IDS at manage.alta.inc and as follows:

ssdk_sh flow status set 0
ssdk_sh port flowCtrl set 5 disable
ssdk_sh port flowCtrl set 6 disable

However, the speed is still terrible. Initially, when I started a torrent, I was able to reach 1.88 Gbit down (on a 10 Gbit connection), but within a few seconds, the speed dropped drastically to around 100-200 Mbit/s.

I have two ISPs, and I initially suspected the new ISP was throttling me, but when I tested with the old ISP, I got the same issue. My old ISP doesn’t throttle, and even on their 1 Gbit connection, the speed drops to around 10-20 Mbit/s.

When I connected both ISPs to my MikroTik router, I had no issues. Everything worked fine, maxing out the connection. I’ve been testing Route10 for nearly a week, and these ongoing issues are extremely frustrating. I’m seriously considering making a YouTube video where I smash this router to pieces!

Unbelievably a unfinished product and we end users suffering.

Chill out! Give folks time to analyze and work on the issue first!

1 Like

I can confirm I am able to duplicate the “bug”, however I am not aware of it being an officially supported feature yet anyhow. @Alta-Jeff let me know if I can help troubleshoot in any way.

I wished, but it is such an unpolished product, everyday finding new bugs and issues here and there. I’m not even upset about missing features, but UI bugs, issues that cause speed drops.

It’s a nature of the beast. I was on a call for almost two hours last night with Cisco dealing with a Meraki bug that was causing huge network slowdowns when instructors were using Apple Classroom during presentations. We pay a lot monthly for their “enterprise” gear that has more bugs than Alta.

Remember also that any manual changes you make without also putting them in post-cfg.sh are likely to revert on the whim of the controller.

Yes I have them in post-cfg.sh, issue is that it won’t work, one of the ports will still have flow control on as you can see from my terminal commands.

No offense but grow up. Throwing a temper tantrum and saying you are going break something like a child over a bug is just cringe.

It’s more about highlighting how poor the software of this product is at the moment, and advising others to avoid it. As I dive deeper into Route10, I notice that many of their packages are severely outdated. OpenWRT 21.02 has already reached its end-of-life, and there have been numerous security updates since then. Routing issues on their 2.5G ports could likely have been resolved if they were using a more current version. I have different models of NanoPi running OpenWRT, and everything works flawlessly compared to this outdated mess.

I even returned the router and got a replacement, hoping the first one was faulty, but the same issues have persisted since version 1.3f on the new unit. So many updates, yet zero fixes.

Since version 1.3f? Where are the release notes for that version? Do you mean 1.3i? I thought you have only been testing it for a week?

Thanks for the warning but I think I’ll keep mine. Have fun with the Pie thing. Have a blessed evening. :church: :pray:

No, it’s the default version that came with the replacement before automatic updates. Might be k might be f, can’t really recall well but it’s way before k, which is about 2 months of updates and yet alta don’t even realize all this bugs existed. With me testing a week and caught so many issues, I can’t imagine if I were to use for months, probably be in a mental institute by now.

@jaianna sorry for the trouble, but let’s please stick with technical details so we can actually sort out what’s going on here.

What is it you’re attempting to do here? You’re trying to set what speed, on which interface? If it’s one of the SFP+ ports, what SFP+ module do you have connected?

The flow control part is an entirely separate thing, do you have a need to disable it? Granted, it’d be more sensible to disable by default, I made a note to look into that tomorrow.

As I dive deeper into Route10, I notice that many of their packages are severely outdated. OpenWRT 21.02 has already reached its end-of-life, and there have been numerous security updates since then. Routing issues on their 2.5G ports could likely have been resolved if they were using a more current version.

Every single portion of this is false.

Qualcomm’s SDK uses OpenWrt 21, and it is still currently maintained by Qualcomm and us. In fact the drivers are only fully and properly supported via Qualcomm’s proprietary components (the latest stock OpenWrt release won’t work at all on this hardware). It doesn’t matter whether OpenWrt maintains it, we don’t rely on them for that.

In fact, the packages we include are often newer than any OpenWrt release version includes. We already have some that are only in OpenWrt main branch that you won’t get until later this year in an OpenWrt release.

This is the nature of embedded software development. Development shops with good practices, like Alta Labs, bring you all the latest packages as appropriate and all needed security updates. In our case, doing so well before OpenWrt itself even does.

9 Likes

Connected using a Huawei S800E, the SFP+ port is functioning properly with no issues, maintaining 10G speeds as verified by running a speed test using Ookla’s speedtest-cli directly on the Route10 device. However, despite completely disabling flow control, there is always one port that remains enabled on the 2.5G interface. If you run the speed test again or attempt to disable the hardware accelerator via the controller, a reboot is required to restore the “2.5G” speed. The reason I put “2.5G” in quotes is that the speed is highly inconsistent. For example, when connecting to nearby speedtest servers (eight in total), with flow control enabled, I can achieve 1.89 Gbps download and 2.3 Gbps on the max servers (two of them), while the rest deliver an average of 500-600 Mbps download and 2.3 Gbps upload. Once flow control is disabled, I can achieve 1.89/2.3 Gbps D/U on all eight servers. This behavior is consistent across two Route10 devices.

On my MikroTik device, the 2.5G port consistently delivers 2.3 Gbps up and down across all eight servers. However, with flow control disabled on ports 1 through 6, port 2 always remains enabled. The only way to disable port 2 is to physically unplug and replug it, but I consider this a “fake disable” since the results are identical to when flow control is enabled—500-600 Mbps speeds on speedtest, and a reboot is still required to achieve 1.89 Gbps speeds (after running my post-cfg.sh script to disable all ports).

This is my post-cfg

ssdk_sh flow status set 0
ssdk_sh port flowCtrl set 1 disable
ssdk_sh port flowCtrl set 2 disable
ssdk_sh port flowCtrl set 3 disable
ssdk_sh port flowCtrl set 4 disable
ssdk_sh port flowCtrl set 5 disable 
ssdk_sh port flowCtrl set 6 disable

double-checked the status using the ssdk_sh port flowCtrl get 1 to 6 command. While port 2 is enabled (Can’t disable it no matter how as per my screenshot) and the others are disabled, I was able to achieve good speeds on the speedtest. However, torrenting is still being throttled. The speed maxes out at 1.89 Gbps, then drops to a low of around 300 Mbps, fluctuating up and down like a roller coaster ride.

Tell me you ain’t finding this weird.

And just so you know, I tested every port, and it stays the same. I used high quality Commscope cables cat 7 shielded and tested with different cables. I had Noctua fans attached to the router to keep things really cool, nothing works out.

Network topology varies greatly from site to site, and while we have tested many scenarios, it’s not possible to guarantee maximum performance in all environments.

We’ll look into the slower speeds when hardware acceleration is enabled in your type of site. We are able to reproduce something similar with a very specific setup here. For the moment, though, I would recommend disabling hardware acceleration just for your site for the time being.

For your specific case, you also have the option to run all traffic through the 10 Gbps ports exclusively, to ensure 10 Gbps speeds throughout your network.

1 Like

Honestly I’m confused as I run a ton of devices including a full blown storage system through this… I guess when you say torrenting your not using a VPN? My tests over a VPN were like 2gbish speeds but I’ve never(and will never) torrent without a VPN so no idea on that. Speed tests have been excellent and I hit my line speed + the overprovisioning my ISP gives. Inter server transfers have been good as well but I’ll admit I’ve not loaded up every port on this thing with servers. Just a 2.5 and a 10gb and the rest are running 1gb.

1 Like

What about ssdk_sh port flowCtrl disable 1-6? There will always be a port that remains enable. Yes, flow control and hardware accelerator can max out on certain sites that give you max speed but still does not stop torrents from getting throttle. You will see better results over cubic tcp congestion control when using bbr v3.

Load a big torrent 50G and above with 3000-5000 seeders and only a couple peers to ensure sufficient bandwidth, check your network graph and see if it’s sustaining the speed, you will see roller coasters ride. I can push what you getting but speeds are dropping, and I am torrenting on nvme drives, not mechanical. On my mikrotik, everything was able to max out and stable.

This thread has been thoroughly derailed, and I would like to get it back on track. @jaianna could you confirm for me whether this is a new, separate issue? It somewhat resembles your note here, but you’ve also tacked on a bunch of other stuff from this thread.

It’s made for a very confusing perspective. Could we consolidate your grievances and try to tackle them one at a time please?

If this thread is further derailed, I will proceed to lock it for being so counter-productive. We can resume in one of your other 2 threads if that becomes the case, as I believe you have been making duplicate reports in your frustration so it will remain on topic there.