@blade I downloaded RC2 and did some of the same experiments as you did. my conclusion for myself was…
Old Bonding works better than the new dynamic weighted (for me]
There is some secret relationship between FEC and the Bonding algorithm… it seemed to be a better able to detect when my crappy connection was full and back off with FEC set to low.
Latency difference cutoff had a significant effect. I went as low as 50ms and settled on 75ms for myself.
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?
Please let me know the result of the new algo, and to have more complete information, please use the “Export” button on the SpeedFusion Chart screen to save the PNG file, saving 2 different files from both local and remote devices will be better for me to compare the result, thanks!
Oh, and for the throughput test I’d suggest a longer duration (at least 30 seconds) to get a better understanding of how the network performs.
Hi @mystery, the new Traffic Distribution Policy - “Dynamic Weighted Bonding” is available for all devices with SpeedFusion Bonding capability. However for BR1 MK2 I remember it’s a Hot Failover device? In this case the new algo won’t apply, but one thing - the SpeedFusion Cloud, if you have SpeedFusion Cloud license we can activate bonding for the cloud connection, more details can be found here, we have a free trial tier as well:
MK2 does Speedfusion hot failover and Smoothing. Is there a difference between enabling Dynamic Weighted Bonding for Speedfusion Cloud and Fusionhub Solo? It would be awesome if you can enable it for Fusionhub solo cloud connection. Otherwise, can you please, let me know the reason you can’t?
@blade, please leave all the parameters (e.g. cut-off latency) as empty, the new algo DWB doesn’t work like the default bonding algorithm, many parameters have a different meaning, we don’t have a new set of params designed for DWB yet that’s why we are still hiding it in the support.cgi page. Usually cut-off latency cannot be set too high and using default empty value usually give the best result. I’d suggest to leave all the params empty and test again.
And also, is it possible to enable Remote Assistance (RA) so we can check directly on your device? In this way we can help to fine tune and see whether we can further optimize the algorithm. After enabling RA, you can send me the Serial Number via forum message, or create a support ticket then I’ll pick it up, don’t post it publicly on the forum. Thanks
@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…
WAN Smoothing all defaults
Bonded, FEC Low, 65ms cutoff diff
DWB all defaults
All use T-Mobile and AT&T as #1 priority
All tests 20 second downloads
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.
@Legionetz, 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!
