I am reaching out for assistance regarding an issue I’ve encountered with my MikroTik Chateau LTE18 ax.
I’ve noticed that whenever I initiate an upload, there is a significant drop in download speed. This seems counterintuitive, as I would expect both upload and download activities to operate efficiently in parallel.
Model: MikroTik Chateau LTE18 ax
Configuration: Standard setup, no significant changes made to default configurations.
Symptoms:
When uploading files (10Mbps by default), the download speed (100 Mbps by default) decreases drastically (up to 1 Mbps).
The issue is consistent and reproducible.
Questions:
Are there any recommended settings or configurations that could help balance upload and download speeds?
Could this be related to the LTE modem’s capabilities or a limitation in the network architecture?
I would greatly appreciate any insights or recommendations from the experts. If additional information is required to diagnose the problem, please let me know, and I will provide it promptly.
Thank you in advance for your time and assistance!
The way TCP works (and most connections nowdays are TCP) is that every packet in forward direction (e.g. direction from your device towards internet in case of uploading) has to be acknowledged in the return direction. ACK packets are typically small (they only have TCP headers, no other payload), but they are as frequent as packets in forward direction. Since normal ACKs in TCP mean that ACKing certain packet implicitly ACKs all preceding packets (unless selective ACK is used where same ACK can ACK some packets and un-ACK others), most TCP stack implementations reduce number of return packets by certain factor (so far I’ve seen factor of 2). This, however, may have negative side effect on forward throughput (sender can only have certain amount of unacked packets sent and if those are not ACKed in timely manner, sender stalls).
Having written the above it’s obvious that return traffic (ACKs) will be subject to potential congestions. If DL is congested while you’re trying to test UL, then ACKs from the connection peer can get significantly delayed and sender will stall … thus showing reduced throughput. The amount of throughput reduction corresponds to buffer sizes and if your ISP utilizes larger buffers (buffer bloat), which in principle allows for higher throughputs, but causes high delay jitter (and one of effects is what you see).
Thank you for the detailed explanation of the TCP behavior and the role of ACK packets in network congestion. It has provided a clearer understanding of the underlying mechanics that might be contributing to the reduced throughput during simultaneous upload and download activities on my MikroTik Chateau LTE18 ax.
While the theory behind the TCP-induced congestion is insightful, I am still in search of specific steps that can be taken to mitigate this issue. Specifically, I am looking for guidance on any configuration changes or settings adjustments within my MikroTik device that can help maintain a balance between upload and download speeds, especially in scenarios where ACK packets are causing noticeable delays.
Questions:
Are there specific MikroTik settings that can be tweaked to optimize the handling of ACK packets and reduce their impact on throughput?
Can any QoS (Quality of Service) or traffic shaping policies be applied to prioritize ACK packets and alleviate congestion?
Is it possible to adjust buffer sizes or other parameters to minimize delay jitter and improve overall network performance?
Any step-by-step instructions or recommendations for configuration changes would be highly beneficial!
Thank you once again for your assistance, and I look forward to any suggestions you may have.
I’m not an expert on QoS in ROS, so I don’t know if there are any mechanisms which would prioritize ACKs over full-payload packets. The additional problem here is that it seems that it’s DL direction where congestion affects the bi-di throughputs. And DL direction is in ISP’s hands. The only thing that you can do is to enable queuing and set the overall DL throughput to something lower than 100% of your available bandwidth. Which can be quite a challenge if DL throughput (the “last mile”) is not constant … and with public broadband networks (where multiple users share same resource bucket) you never know what kind of throughput you may realistically get to limit queues to, say, 95% of it.
So no, realistically there’s no way of fixing your performance issues when almost everything is out of your hands (even UL … you can affect the queuing, you can prioritize certain types of traffic, such as ACKs, … but you don’t know what kind of throughput you are getting in every moment).
are we talking about LOCAL wifi speed, or downstream from the mobile base station?
LOCAL wifi shares airtime. in case of bad signal from client, those 10mbit up could eat all the airtime so that’s why you have extremely low download speed. try to test via cable.
IF you’re talking about GSM connection - that’s at ISP level. LTE networks have different UL and DL bands and usage of uplink doesn’t affect downlink.
I should clarify that the speed issues I’m encountering are indeed related to the LTE connection, and during my testing, I have been using a computer connected via cable directly to the MikroTik Chateau LTE18 ax router. This setup was to ensure that local Wi-Fi factors did not influence the test results.
Given that the tests were conducted over a wired connection, the problem seems to be isolated to the GSM side of things, which, as you mentioned, would typically suggest an issue at the ISP level since LTE networks usually have separate UL and DL channels.
I’m keen to understand if there’s anything within the MikroTik’s configuration that can be adjusted to better manage the GSM throughput or if there are known issues with this model that could lead to such behavior?
Any additional insights into this matter or further troubleshooting steps would be greatly appreciated. Thank you once again for your time and assistance!