Bug on Speed. Route10

I’m not sure if this is some kind of damage control on your part, but I did notice that the UI sorting issue for IPs, which I reported on another account, has been fixed.

As for this thread, the only thing left is identifying the hardware accelerator that’s limiting traffic. Other than that, I’ve already implemented my own fixes using QoS and scripts to address the port getting knocked off and speed limitations. I won’t share my solution just yet—I’d rather wait for another hardcore user to run into the same issue and raise concerns, so you can truly understand the frustrations of end users.

That being said, I’m currently restricted from making posts and had to use multiple VPNs just to bypass the login ban. I don’t know if you’re genuinely asking whether the bug is resolved or if this is just a public display, but I sincerely hope your intentions toward end users are genuine and in their best interest.

The IP sorting issue was resolved thanks to the cooperation of some other users in this thread. It is my belief that the thread belongs to another of your alt accounts, but since you are using disposable emails and not staying logged in, you may have missed the notifications while we were working on the issue.

Please do not circumvent the moderation and trust level system with VPNs. This behavior can result in additional flags on your accounts, which is something we are trying to avoid.

If you are encountering post limits, then simply wait out the timer. Restrictions on your account will be automatically lifted by the trust level system; meaning, without our intervention to modify your account. Due to your other flagged posts and the age of your account, the trust level has been reduced. This may result in delays in your responses, but circumventing the system will result in bans.

Now, please keep this thread on topic going forward.

  1. What issue are you reporting here?
  2. Does this thread need technical attention and additional support?

If you have discovered workarounds for the issues described herein, then we would like to better understand the problem you are experiencing. We need steps to reproduce, and an environment where those steps do reproduce the issue consistently. To do this, we need to reset your Route10 and clear any and all custom configurations, and work our way through the issue step by step to determine when the issue is presented and in what ways it affects your network.

In one of your other threads, I have already laid out a testing methodology that we’d like to introduce. I also believe that thread heavily overlaps with your reports in this topic.

Let’s try to narrow our focus and work towards our common goal of improving our high-performance and feature rich network gear to end users.

1 Like

First, start by running the following command on Route10 to set up iperf3 in server mode:
iperf3 -s
Next, run iperf3 in client mode from any PC connected via a wired connection to the 2.5G port: iperf3 -c <route10 ip address> -P8 -R -t 600

You’ll notice differences in speed between the uplink and downlink. Additionally, if you ping 1.1.1.1, you may observe occasional latency spikes of around 20ms, though not significant.

However, when pushing 10 Gbps by running speedtest-cli and pinging from both the router itself and other LAN devices, no latency spikes occur.

Connect all ports and execute the following commands to disable flow control on each port:

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
ssdk_sh port flowCtrl get 1
ssdk_sh port flowCtrl  get 2
ssdk_sh port flowCtrl  get 3
ssdk_sh port flowCtrl  get 4
ssdk_sh port flowCtrl  get 5
ssdk_sh port flowCtrl  get 6

You’ll notice that one port always remains enabled. To prevent speed issues, I set flow control back to enabled on that specific port using:
ssdk_sh port flowCtrl set 2 enable
After doing this, the speed issues disappeared, and I was able to maximize full 2.5G download speeds while torrenting.

That’s all I’ll share for now. If you’re serious about improving the product, resolve this issue, and I’ll provide six more bugs. That said, I’ve already implemented scripts as a workaround for all of them in a bash script with UCI commands etc.

First I want to address your attitude here. We are not pack animals you can dangle a carrot in front of and demand action. I’m happy to help diagnose and resolve all of the issues our community discovers, but we will not tolerate this denigrating behavior any further. You have been warned multiple times about your unsavory approach, and those warnings will run out sooner than later. It is also notable that both your Reddit and HardwareZone threads found many other users who chose to comment on your attitude. This constantly detracts focus from the potential bugs that we would like to solve.

If you have more bug reports, please deliver them in order for us to better provide for our valued customers; including you. However, when providing those additional reports, please ensure that your threads stick to the technical details without any additional name-calling again.

Would you clarify what differences we should see? How does this issue present for you, and what should we expect?

What speedtest-cli, from what device, to what server, over what interface and through what switches?

Can you describe to me why we are suddenly disabling flow control and convoluting our experiment with additional factors? Additionally, are you reporting another issue buried in here about one port remaining enabled? Which port? Is it always the same one? Is it random, or is it influenced by the order in which you run your scripts?

I’m sorry, under what pretense is this preventing speed issues? Is it because of a bug you’ve identified here? Can you better explain what this means?

We would like to confirm that there is an issue, and a resolution based on your report, but we cannot work with torrent traffic for data. Can you reproduce this with any other type of traffic? Even if the answer is no, that could remain very valuable information anyway, but you have not been forthcoming so far. Please let me know.

Sometimes another user’s workarounds, such as yours, would be enough for us to establish a bug and implement or improve that workaround to reduce your management overhead. We would be very grateful if you could share that with us, as it would be exactly the kind of technical details that would answer almost all of my other questions.

Thanks for your patience in rooting out these issues. I’ve been trying really hard to understand what you’re experiencing for several days, so please take some time to clarify for us.

First of all, we are the end users—we pay for a product expecting quality, or at the very least, the assurance that you will improve it over time. A simple UI bug was reported by Quackers, which I later confirmed, yet it was brushed off and left unfixed across multiples consecutive updates.

Let’s be real—on HWZ, the general sentiment is simple: your product is considered cheap and affordable, but that does not justify delivering a poor product. Being budget-friendly is not an excuse for lackluster quality, and many other users have pointed this out.

Second, your documentation is terrible—or rather, nonexistent—as countless users have mentioned. To this day, there is still no proper documentation. You have no idea how frustrating it is, especially for users who can fix things themselves via SSH but are left in the dark due to your failure to provide even basic guidance.

Now, let’s talk about iPerf. If you had actually read my previous posts, you’d know that downlink is capped at 1.9 Gbit, while upload can max out. And no, I still believe this is nothing more than damage control—all these sudden “fixes” appeared in a single day, yet you had two months to address these issues properly.

I refuse to provide more details on how I resolved these problems because this is a test of competence. These issues no longer affect me since I’ve already fixed them myself, but when another power user runs into the same problems, it will become blatantly obvious how long these bugs have been lingering. I want to see if you are truly competent in solving bugs wholeheartedly—or if this is just another case of damage control to silence complaints.

This is as much as I will provide. It doesn’t matter much to me now, as I’ve made my system as stable as it can be with tweaks and patches since this bootloader isn’t locked. Had I received more support instead of constant blame-shifting, you would have realized that most of my comments, even if sarcastic, carried legitimate weight. This would also be my last reply. Consider studying openwrt.ai on others automated configuration, it is way more stable than your product.

It was resolved within the hour after we had access to an environment where the issue was consistently reproducible. I do apologize that your thread during the holiday season was overlooked, and regret that we couldn’t prioritize this low-impact bug report sooner. In the meantime, you can see the amount of work we continued to do and the value we continued to add to our products by reviewing the release notes category. My favorite one is the WireGuard server, but I’m looking forward to site-to-site VPN next.

I think we can agree that it’s no excuse, but I would not so quickly agree that our product is lackluster. You have some gripes, and we’d like to resolve those, but your case is extremely custom and we don’t even know what you’re actually trying to achieve in your testing so far.

I do agree that our documentation is falling behind. Can you let me know which specific deficiencies we could address first in order to improve our coverage the most? I have a few in-progress documents, and we’re still revising some others, but I would be glad to add some more topics to my list.

I have read your posts, but you’ve made such a spider’s web of the forums lately that I’m struggling to keep up with everything. Forgive me.

I do recall your results about the downstream and upstream directions now. I can hardly believe this is the same thread!

I believe Jeff commented on them here, and we would appreciate your grace and patience while we continue to investigate.

There’s only been one fix so far – the IP sorting issue should be resolved on the cloud platform, and will be released in an upcoming update for self-hosted and local Control units.

Again, it is regrettable that we couldn’t prioritize this bug sooner, but you will not get away with piggy-backing off of the report from Quackers. Your grievances came to us during the tail end of the holiday break on January 4 here. In a more generous interpretation, we could refer to your older account’s post here, but that still only gives you 2 weeks, not 8, and it’s buried deeper in the middle of the end of year holiday excitement.

If you want to pick up your ball and leave the playground, that’s your prerogative. If you’d like to assist us in resolving these issues, I am listening very intently. Otherwise, I will simply point those future power users to your threads, and ask that they give us an opportunity to work with them toward a resolution. I don’t believe the outcome will be as you expect.

Please let me know if you’d like to continue debugging the issues you perceive. I would like to document them, at the very least, for our records and for the good of our community.

1 Like

Please demonstrate good faith by lifting the restrictions on my account so I don’t need to create multiple accounts in the future just to report bugs. Implement a proper bug tracking portal rather than relying on a forum, and I may consider returning. At this point, I don’t see any reason to share my fixes, as I invested time in debugging them and dealt with aggressive responses and the frustrations that came with it.

My responses to your threads and replies are a demonstration of good faith. We will not be lifting any restrictions on your account; they will automatically lift themselves as your participation in this community grows and remains positive. It is your job to make that happen if you want to continue to participate here.

We also accept bug reports through our support center, which you can reach directly by emailing us at support@alta.inc. If that’s not good enough for you, we also filter social media for bug reports and have received many by direct message through channels such as Instagram, TikTok and YouTube. Again, your account’s standing will continue to improve automatically as long as your engagement here remains constructive and positive. Continuing to get flagged by other users will continue to slow that process, but it moves faster if you can cooperate with our troubleshooting and hold your tongue before calling names again.

Additionally, we will consider a bug tracking portal. At this time, it is not within scope to offer this service. Our developers work tirelessly managing bugs and providing fixes already. I don’t have the time in my day to additionally filter a user-submitted database and triage and confirm the reports.

I appreciate that you put a lot of effort into finding these issues and their workarounds. However, you were the one who became openly hostile with other users here, and what you dealt with were the repercussions of your actions.

Please understand that we regret not being able to prioritize, reproduce or maybe even understand your reports. This is why I am working so hard to get you to divulge the details that have otherwise been left out of the discussion.

Again, you are privileged with every right as the consumer to walk away and take your toys out of the sandbox with you. This is not going to solve the issues you perceive, but it may give you a personal satisfaction. However, I may remind you that your threads will be the example I point to if or when future power users arrive describing a similar issue to your own. We will then solve the issues with their cooperation instead of yours. But we will solve the issue when we have the necessary details to do so.

1 Like