Hey everyone!
For several years now, I’ve been tinkering with getting a stable LTE internet connection out here in the countryside, and I just wanted to share my experience with you all. This may be relevant for all other LTE router products and countries.
For a very long time, I was fixated on speed and signal strength—but that doesn't automatically translate to good latency or stability.
Transparency Note: This post was summarized using ChatGPT for better readability. It is based on a months-long chat with my "MikroTik Agent," including data, screenshots, tests, and more. 
A second important note before you start reading: The figures—particularly those for download and upload—pertain to my specific case. They do not constitute a general recommendation; rather, they are based individually on the available bandwidth. You must perform your own measurements and adjust these values accordingly.
---
I wanted to share a practical LTE optimization experience that might help other MikroTik users dealing with unstable latency, Google Meet issues, video call dropouts, gaming lag, YouTube buffering, or the classic problem: “The speed test looks fine, but the connection still feels bad.”
I am located in Germany and use a Congstar / Telekom LTE connection. This matters because LTE performance, available bands, carrier aggregation behavior, cell load and regulatory Wi-Fi settings can vary significantly by country, provider and region.
The exact numbers in this post are not universal recommendations. They are the result of my own testing on a German LTE network. However, the general approach — measuring bufferbloat, shaping below the reliably available capacity, disabling FastTrack for queues, and separating Wi-Fi issues from LTE issues — should be useful for MikroTik LTE users in other countries as well.
My setup is based on a MikroTik LTE router as the main internet gateway and a separate MikroTik hAP ax² as access point.
This post is mainly for people who need stability more than maximum speed.
If your priority is downloading large files as fast as possible, my final settings may look too conservative. But if you rely on LTE for home office, Google Meet, Zoom, Microsoft Teams, Slack calls, remote work, VoIP or online gaming, then latency, jitter and packet loss are much more important than peak throughput.
In my case, chasing the highest possible LTE speed made the connection feel worse. Limiting the connection to a lower but stable bandwidth made it much more usable.
The Setup
My network setup is roughly:
MikroTik LTE ATL LTE18 Kit router = main router, LTE, DHCP, NAT, QoS
MikroTik hAP ax² = access point / bridge
Work laptop = prioritized device
Gaming PC = prioritized device
Other devices = lower priority
The LTE connection is theoretically capable of up to around 100 Mbps downstream. In some tests I actually reached nearly that speed. Signal quality is also quite good after careful antenna positioning.
Typical LTE values after optimization:
RSRP: around -70 dBm
SINR: around 19–25 dB
RSRQ: around -9 to -13 dB
CQI: often good
Carrier Aggregation: B3 primary, sometimes B3+B8
So from a pure radio perspective, the connection looked fine. During the day (see screenshot), the signal is weaker than in the evening. The weather can also affect the signal.
Still, the real-world experience was inconsistent. Google Meet sometimes had audio/video glitches. Gaming latency was unstable. YouTube could buffer or stutter. Ping tests showed occasional spikes even though the average latency looked acceptable.
The important lesson: good LTE signal values do not automatically mean good real-time performance.
Location and Provider Context
For context: I am located in Germany and use Congstar / Telekom LTE.
This matters because LTE behavior depends heavily on local conditions:
-
provider
-
cell load
-
available bands
-
carrier aggregation behavior
-
backhaul capacity
-
time of day
-
regional network planning
Users in other countries or on other carriers may find a different sweet spot. The exact bandwidth limits are less important than the method: measure, shape below the reliably available capacity, and optimize for latency rather than peak throughput.
Stability Was More Important Than Peak Speed
The main goal was not to maximize download speed. The main goal was to make the connection predictable.
For real-time applications, the worst-case latency matters more than the best-case speed test result. A single latency spike of several hundred milliseconds can be enough to cause a frozen video call, delayed audio, lag in games or a short disconnect in collaboration tools.
This was especially important for:
-
home office
-
Google Meet
-
Slack calls
-
video conferencing
-
online gaming
-
YouTube / streaming
-
general work where dropouts are more annoying than lower speed
A stable 40 Mbps LTE (down) connection is much more useful to me than an unstable 100 Mbps connection with 600 ms latency spikes.
The Problem: LTE Speed Was Available, But Not Stable
My mobile plan theoretically allows around 100 Mbps Download. However, the actually available LTE capacity changes constantly depending on cell load, scheduler behavior, carrier aggregation, time of day and probably provider-side backhaul/load.
This makes LTE very different from a fixed DSL, fiber or cable line.
One moment the cell can deliver 80–100 Mbps download, a few minutes later the stable capacity may be much lower. If the router allows clients to use the full available bandwidth without shaping, latency can explode.
Without shaping, my bufferbloat tests looked terrible:
Idle latency: around 140–180 ms
Download loaded: 400–600+ ms
Upload loaded: 250–600+ ms
Bufferbloat: C / D
That explains why the connection felt bad even when “speed” seemed acceptable.
In short: the LTE connection was fast sometimes, but not predictably stable.
Why Upload Was Easier Than Download
Upload shaping worked quite well because the MikroTik router can control packets before they enter the LTE uplink.
Download shaping is more difficult. By the time download packets arrive at the MikroTik router, congestion may already have happened inside the LTE network or provider path.
This is important: downstream bufferbloat on LTE is harder to control than upstream bufferbloat. Still, setting a realistic downstream limit helped a lot.
What Did Not Work Well
I tested several download limits:
No shaper: very bad, massive latency spikes
65 Mbps: better, but still inconsistent
60 Mbps: still inconsistent
45 Mbps: not clearly better
40 Mbps: significantly more stable
The interesting part was that lowering from 65 to 60 or 45 did not always improve the result. LTE conditions were too variable. But at around 40 Mbps downstream, the connection became much more predictable.
The best result was not the highest speed. The best result was the most stable latency under load.
The Sweet Spot for me: 25M upload /40M download
One important point: the 40 Mbps down / 25 Mbps up limit is not a universal LTE recommendation. (these numbers belong to my case)
The right shaper value depends heavily on the local LTE conditions, including signal strength, noise, cell load, carrier aggregation, time of day and even weather conditions.
In my case, 40 Mbps down worked well as a stable baseline. But another user may need 30 Mbps, 50 Mbps or a completely different value. The best approach is to measure several times during the day:
- during work hours
- after work
- in the evening
- at night
- during bad weather if possible
LTE capacity is dynamic. A limit that works perfectly at night may be too high during busy evening hours.
A more advanced approach would be to use different queue profiles depending on the time of day. For example:
- conservative limits during work hours
- higher limits after work
- maximum throughput profile at night or for large downloads
Some users solve this with scheduled scripts and Queue Tree rules, where parent limits change by time period and child queues are adjusted proportionally. My setup is simpler and uses a fixed stability-first limit, but the general principle is the same: shape below the reliably available capacity, not below the theoretical maximum speed.
My final stable profile is:
Upload: 25 Mbps
Download: 40 Mbps
Queue: fq-codel
This may look conservative compared to the theoretical 100 Mbps, but the difference in usability is huge.
With the 25M/40M shaper active, bufferbloat tests improved significantly:
Idle latency: around 199–205 ms
Download loaded: around 170–218 ms
Upload loaded: around 150–174 ms
Bufferbloat: A / A+
The absolute idle latency is still LTE-like and not comparable to fiber, but the important part is that the latency no longer explodes under load.
The connection became much more usable for:
-
Google Meet
-
Slack calls
-
YouTube
-
gaming
-
general browsing
For my LTE connection, 25M up /40M down was the practical stability sweet spot.
MikroTik Simple Queue Setup
My simplified queue structure looks like this:
TOTAL LTE SHAPER
-
WORK MAC MEET UDP
-
WORK MAC PRIORITY
-
GAMING PC PRIORITY
-
OTHER DEVICES
Important device IPs in my setup are anonymized below:
Work laptop Wi-Fi: <WORK_LAPTOP_WIFI_IP>
Work laptop LAN: <WORK_LAPTOP_LAN_IP>
Gaming PC: <GAMING_PC_IP>
LAN subnet: <LAN_SUBNET>
The work laptop and gaming PC get priority. Other devices are still usable, but they cannot easily destroy latency for the important machines.
My current queue setup, anonymized:
/queue simple
set [find name="TOTAL LTE SHAPER"] max-limit=25M/40M priority=8/8 limit-at=0/0
set [find name="WORK MAC MEET UDP"] target=<WORK_LAPTOP_WIFI_IP>/32,<WORK_LAPTOP_LAN_IP>/32 packet-marks=work-mac-udp priority=1/1 limit-at=3M/6M max-limit=25M/40M
set [find name="WORK MAC PRIORITY"] target=<WORK_LAPTOP_WIFI_IP>/32,<WORK_LAPTOP_LAN_IP>/32 priority=1/1 limit-at=5M/12M max-limit=25M/40M
set [find name="GAMING PC PRIORITY"] target=<GAMING_PC_IP>/32 priority=2/2 limit-at=5M/12M max-limit=25M/40M
set [find name="OTHER DEVICES"] target=<LAN_SUBNET> priority=8/8 limit-at=0/0 max-limit=10M/25M
The key point is not my exact IP scheme. The key point is the structure: one total LTE shaper, prioritized queues for real-time/important devices, and a lower-priority queue for everything else.
UDP Packet Marking for the Work Laptop
For Google Meet and other real-time traffic, I mark UDP traffic from/to the work laptop:
/ip firewall mangle
add chain=forward src-address=<WORK_LAPTOP_WIFI_IP> protocol=udp action=mark-packet new-packet-mark=work-mac-udp passthrough=yes comment="Mark Work Laptop UDP upload"
add chain=forward dst-address=<WORK_LAPTOP_WIFI_IP> protocol=udp action=mark-packet new-packet-mark=work-mac-udp passthrough=yes comment="Mark Work Laptop UDP download"
add chain=forward src-address=<WORK_LAPTOP_LAN_IP> protocol=udp action=mark-packet new-packet-mark=work-mac-udp passthrough=yes comment="Mark Work Laptop LAN UDP upload"
add chain=forward dst-address=<WORK_LAPTOP_LAN_IP> protocol=udp action=mark-packet new-packet-mark=work-mac-udp passthrough=yes comment="Mark Work Laptop LAN UDP download"
This is not magic, but it helps real-time UDP traffic get preferred treatment when the line is busy.
For video calls and real-time applications, UDP priority can be more useful than simply chasing more bandwidth.
FastTrack Must Be Disabled
For queues to work properly, FastTrack should not bypass the queueing system.
In my case the default FastTrack rule is disabled:
/ip firewall filter
disable [find comment="defconf: fasttrack"]
This is important. If FastTrack is active, your queues may not behave as expected.
MSS Clamping
My LTE interface uses MTU 1420, while the network advertises 1500. I kept MSS clamping active:
/ip firewall mangle
add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp out-interface=<LTE_INTERFACE> comment="Clamp TCP MSS to LTE PMTU"
This avoids MTU-related issues with some TCP connections.
I would not blindly change MTU settings unless there is a specific reason. MSS clamping was the safer approach in my setup.
Wi-Fi Was Also Part of the Problem
At first I blamed LTE for everything. But local ping tests showed that Wi-Fi also introduced latency spikes, especially outside on the terrace.
Testing helped separate the problem:
ping <ACCESS_POINT_IP> = client to access point
ping <LTE_ROUTER_IP> = client to LTE router
ping 1.1.1.1 = full path through LTE
The best Wi-Fi settings for my terrace ended up being:
2.4 GHz
Channel 6 / 2437 MHz
20 MHz channel width
WPA2 only
WPA2/WPA3 mixed caused more local jitter in my setup. Switching to WPA2 only significantly improved local ping stability.
After that change, local Wi-Fi latency to the access point improved to roughly:
0% packet loss
average around 5–6 ms
max around 30–35 ms
That was a major improvement.
Important lesson: Wi-Fi jitter can look like LTE problems. Always test the local network separately.
Ping Watchdog Caused Problems
Another important finding: the MikroTik ping watchdog was too aggressive for LTE.
It was configured to reboot the router after a short ping timeout. That is dangerous on LTE because short reachability issues can happen without the connection being truly dead.
I disabled it:
/system watchdog
set watchdog-timer=no watch-address=none
I kept a scheduled LTE reconnect/reboot during the night instead. That is much safer than a router reboot during a work meeting.
For LTE connections, an aggressive ping watchdog can create more downtime than it prevents.
How I Diagnosed the Problem
The most useful method was to test each segment separately:
Client to access point
Client to LTE router
Client to internet
LTE router to internet
For example:
ping <ACCESS_POINT_IP>
ping <LTE_ROUTER_IP>
ping 1.1.1.1
This helped separate:
-
Wi-Fi issues
-
LAN/bridge issues
-
LTE/provider issues
-
DNS/app issues
One important finding was that a wired client and the router itself could have much better latency than a Wi-Fi client on the terrace. That made it clear that not all “LTE problems” were actually LTE problems.
Segment-by-segment testing was essential. Without it, I would have blamed LTE for issues that were partly caused by Wi-Fi.
What This Setup Is Not For
This setup is not designed to win speed tests.
If you want the highest possible download number, this approach may feel too conservative. But that was not my goal.
My goal was:
-
fewer latency spikes
-
better Google Meet stability
-
better Slack / Teams / Zoom call behavior
-
better online gaming latency
-
less YouTube buffering
-
more predictable everyday performance
For real-time work and gaming, stable latency is more important than peak speed.
Final Lessons Learned
My biggest takeaways:
-
LTE signal quality is only one part of the story.
-
“Up to 100 Mbps” does not mean stable 100 Mbps download speed.
-
Bufferbloat can destroy usability even when speed looks good.
-
Upload shaping is easier than download shaping on LTE.
-
Download limits must be below the reliably available LTE capacity.
-
For my connection, 40 Mbps down is much better than unstable 80–100 Mbps.
-
FastTrack must be disabled for queues to work.
-
Wi-Fi jitter can look like LTE problems.
-
WPA2 only was more stable than WPA2/WPA3 mixed in my setup.
-
Ping watchdog is risky on LTE if configured too aggressively.
Conclusion
The best result was not achieved by chasing maximum throughput. It came from accepting a lower but stable bandwidth limit.
In my case:
Theoretical LTE speed: up to around 100 Mbps
Practical stable limit: 25M upload / 40M download
Result: much better latency and real-world usability
This setup is not meant to win speed tests.
It is meant for people who need a stable connection for real-time applications:
-
home office
-
video meetings
-
Slack / Teams / Zoom / Google Meet
-
online gaming
-
VoIP
-
remote desktop
-
general work where short dropouts are more annoying than lower download speed
For these use cases, a stable 40 Mbps down LTE connection with controlled latency is often much better than an unstable 100 Mbps down LTE connection with 600 ms latency spikes.
Since I am in Germany on the Congstar/Telekom LTE network, users in other countries or on other carriers may find a different sweet spot. The exact bandwidth limits are less important than the method:
-
measure
-
separate Wi-Fi from LTE
-
disable FastTrack for queue testing
-
shape below the reliably available capacity
-
optimize for latency, not peak throughput
For LTE users, especially those working from home, gaming, or using video calls, I strongly recommend testing bufferbloat and not only raw speed.
p.s. If you are a German speaker and want to know how I solved my internet problem in the countryside, I’ve written a blog post about it here.
