LTE: speedfusion is slower than the fastest link in the bonding?

@Rick-DC, this is for sure, but unfortunately last Friday when I have a chance to check the devices, it’s likely at peak hours and the total bandwidth measured by WAN Analysis (run plain on WAN, without SpeedFusion) is only ~75Mbps, and at that time SpeedFusion using the new Dynamic Weighted Bonding algorithm is able to achieve the same result - 75Mbps, which is working pretty well and didn’t have the problem.

So the problem may be only happens at off-peak hours.

According to blade, the off-peak hours should be 3am to 7am CET, but the setup will not be available for the next 3 weeks so we can’t continue the investigation before the setup is back. I’ll definitely update this thread when we have updates available.


Since it’s 3 weeks till you can test again, I’m running 4940 on FusionHub and 4942 on Max Transit. I setup a 3rd sub tunnel so I have these tunnels configured…

  1. WAN Smoothing all defaults
  2. Bonded, FEC Low, 65ms cutoff diff
  3. DWB all defaults

All use T-Mobile and AT&T as #1 priority
All tests 20 second downloads

WAN Analysis tool



If there is a test I can run or data I can provide while you wait, please let me know, RA is already active for a separate issue related to the cellular modem.

DWB is definitely getting better, I saw it burst much higher than bonded. My take on them currently… if you goal is highest throughout… DWB wins… if the goal is balancing the traffic and trying to load up both pipes, than Bonded appears to be better for making sure both pipes are used.


Thanks @C_Metz! Can you enable RA for the remote FusionHub as well so I can get it and see?


@Steve Done and done :slight_smile:


@C_Metz, you are using MAX Transit and the maximum capacity of SpeedFusion throughput is 100Mbps, you are hitting the hardware limit of the device but I have still tried to modify some parameters and you can see it’s more constantly running @ ~100Mbps now.

  • Cut-off Latency is set to 120ms to allow the latency inflate a bit more before the bufferbloat prevention logic kicks in.
  • Enabled “QoS > DSL/Cable Optimization” to optimize TCP ACK handling.


Thank you very much. I really appreciate the efforts to give us every drop of performance from these devices. You and the rest of the Peplink team continue to go above and beyond. Thank you!


Dear All,

some update.
The remaining “missing” bandwidth compared to the 100 Mbit/s limit of 20X comes from # of parallel TCP streams. Left bar shows SpeedFusion with 4 streams, the right bar shows with 1 stream:

I learned that with real traffic (not the testing tool), even a single stream would reach the 100 Mbit/s.

Thanks a lot for @Steve for this final analysis and to everyone who helped me with advises.
Overall I pretty much got what this product promises and happy with it.


Thank you very much @blade. :+1:t2: As your 100 Mbps throughput is actually hitting the hardware limit of Balance 20X, I believe the result can be even better with a higher end models. This make me think about we should have an extra status on the PepVPN chart when the throughput is bound by hardware resources. I’ll think about it.


I don’t seem to be able to get the RC3 (now 4) beta firmware. The links don’t have the firmware present. I would like the additional Speedfusion features and settings. I belong to the beta program. Please advise.

the final version was released i thought?

Ah. I’m on 8.1.0. I must have gotten the numbers mixed in my head as I thought the beta was newer. Thanks.