Just run a test between my LTE12 modem (MikroTik) and my MikroTik server in the same AWS cloud where my PepLink FusionHub Solo is deployed as well:
It shows zero lost packet.
From the facts collected, I assume that the components participating in this recent test are not responsible for the packet loss on the Cellular 1 (LTE12). So neither my LTE12 modem, nor AWS, nor the ISP seem to be responsible for the packet loss. Where else it can come from?
Interesting. Do the same thing using the WAN analysis tools on the Peplink (System > Tools | Wan Analysis) and post the results.
I noticed the test above was conducted using TCP instead of UDP, have you tried running Peplink in “Experimental” TCP mode?
I noticed the test above was conducted using TCP instead of UDP, have you tried running Peplink in “Experimental” TCP mode?
Yes, I will try it in UDP as well.
The “Experimental” TCP mode did not work for me - I just tried. Probably I would need to open a suitable port on the AWS firewall…
The result of WAN Analysis:
Zero packet loss at 50 MBps upload.
I did some further tests:
Lets ask @Steve if he has any idea why the Speedfusion graph shows packetloss when the CAT12 modem is the only WAN in use, but p2p wan analysis using that WAN against the same Fusionhub doesn’t.
Also - the latest firmware (8.1.0RC1) has much better speedfusion graphing and is probably worth installing at both ends. Firmware 8.1.0 RC 1
Thank you! I am usually willing to be the early adopter of any new firmware. The reason why I refraine to do so:
I am looking forward to read ideas from @Steve .
I also moved this finding as a dedicated topic itself: Does Speedfusion overdrive WAN connection and causes packetloss?
On this orginal topic, I will try to make the latencies of the two LTEs more similar by increasing radio performance. I hope that I will see some speed bonding after that.
Just realised I have never asked what Peplink device you are using. What is it?
Balance 20X - I mentioned it earlier in the context that tunel bandwidth is limited at 100 MBps.
Hi @blade, this is impressive, you have done a lot of tests here!
I’d suggest you to upgrade to firmware 8.1.0 RC 1, because the new SpeedFusion chart will show a lot more information, and also we have a new SpeedFusion algorithm “Dynamic Weighted Bonding” which is designed for Cellular connections and may perform differently compare to the default bonding algo:
==
Also, for me to get a better understanding of your environment the best way is by enabling Remote Assistance (RA):
With RA enabled, Peplink team (including me) will be able to access your device remotely and do some tests and apply configuration change to it. Is this possible for your case? After enabling RA, you can either send me the Serial Number using direct message (don’t post it in public forum post), or create support ticket here then I’ll follow up:
https://ticket.peplink.com/ticket/new/public
==
And if possible, I’d like to see how it perform when you test with WAN Analysis tool using one Cellular WAN at a time, and both Cellular WAN simultaneously, test mode using TCP is fine. Looks like both LTE is on the same ISP, and and it’s possible a single Cellular already consumed all the available bandwidth on the cell tower side and thus using both WAN together doesn’t give any benefits.
The results will be interesting.
Cellular 1 (LTE12):
Cellular 2 (LTE4):
Cellular 1 & 2 in parallel:
This did not reach the same speed as the separate tests.
So I tried to drive the connections explicitly at a certain speed with UDP:
It seems that the speed parameters were ignored and test was done at a lower speed.
These LTEs are not from the same ISP. These are two real ISPs with two different towers with 5+ km distance, not VNOs (Virtual Network Operators) - but I see that somehow the connections share the bandwidth indeed. My guess is rather that either Balance 20x or FusionHub Solo has a hidden 55 MBit limitation. Although according to the spec, there is no limitation at FusionHub Solo anymore and there is a 100 MBit limitation on Balance 20x.
I wait with the upgrade to 8.1.0 RC1 until it is clarified and provide you with RA. Thanks a lot in advance!
Careful, that doesn’t mean that the backhaul bandwidth can not be shared.
Here in the UK we often see EE and Three, and O2 and Vodafone networks share physical infrastructure. We also have facilities management companies that get planning permission and install the physical towers and masts and the backhaul connectivity (microwave links and fiber generally) who then lease this to the mobile network operators. As such I will frequently see backhaul contention when combining EE and Three SIMs for example and both of these are full blown mobile network operators.
I have also done installs in the countryside here with a directional antenna on Three Mobile where I have connected in turn to different masts at different distances and different points on the compass only to prove that they are daisy chained together using microwave links and sharing the backhaul bandwidth. @Steve 's analysis here will be welcome.
The balance 20x has an advertised limit of 60Mbps VPN throughput encrypted. It is 100Mbps unencrypted. Have you disabled encryption at both ends in each profile?
Yes, encryption is disabled at both ends.
There are ca. 10 towers in 5 km radius here. How typical is that the backhaul of multiple daisy chained towers of multiple providers is only 50 MBit in total? - which is enough only for a single subscriber. This sounds very exotic to me…
But I am open to any explanation which can be proven and lead to a solution…
I am also looking for an explanation why the UDP test of two parallel stream did not drive the connection with the specified speed. If I test with a single UDP stream, then it drives the connection exactly with the specified speed and this leads to packetloss. Something might throttle the speed in Balance 20X itself when two UDP streams are being tested. See picture again:
So I moved the LTE4 antenna to the other side of the building where a different tower has the best signal.
The cross-talk seems to have disappeared. This is either because
Cellular 2 (LTE12) is intentionally not aimed yet properly at the tower.
As next step I will upgrade to 8.1.0 RC1 to see if that Dynamic Weighted Bonding deals better with such quality difference between two LTEs.
To wrap-up here are the latest measurement results.
Changes in the setup:
WAN Analysis:
SpeedFusion with Dynamic Weighted Bonding:
SpeedFusions with Bonding:
Latency Cutoff:
EndPoint: 
Hub:
My interpretation what helped:
Any further proposal what I could improve?
What is strange: Dynamic Weighted Bonding seems to have better performance when both WAN connections are ON - BUT if only one connection is ON (for the measurement) then SpeedFusion does not seem to utilize the full available bandwidth of that WAN connection
@Steve, do you want to still look at that? Remote Assistance is still on.
Thank you in advance!
@blade I downloaded RC2 and did some of the same experiments as you did. my conclusion for myself was…
My connections
A. T-Mobile 40-50ms base latency 55-65Mbps middle of the night, As low as 1Mbps during congested times with latency spiking repeatedly to 400-450 when tower is deprioritizing me. Connection stable for 30days plus at a time.
B. AT&T 25-30ms base latency 130Mbps middle of the night. Always at least 95Mbps during congestion. A latency spike for it is 75ms. Disconnects 3 times a day on average.
All this said, I can push 100-120Mbps inside the tunnel and a little over 200Mbps outside (maximum)
Yes, my concern is also that bonding works as long as everything is good. BUT if one connection will have degradation, then the entire tunel might have degradation. Nevertheless I set the latency cutoffs now to 150 ms everywhere.
Regarding Dynamic Weighted Bonding. I see in the chart that it is somewhat better for me than plain Bonding. Not utilizing full bandwidth of a single WAN connection when only one of them might be a bug. Adding again the relevant chart:
Hi @blade, sorry for replying late, we are too focused to wrap up 8.1.0 for the next RC firmware. During the previous test cycle we have identified different issues related to the new Dynamic Weighted Bonding algo and we have fixed that now. 8.1.0 RC3 will be out soon, would you mind test it again when the firmware is ready?
Steve, any way you can please enable weighted balance algorithm for BR1/MK2? Thanks!
Sure, I will test RC3. It sounds promising. Thank you!
