Fusionhub Solo bandwidth observation

I’ve read everything about Fusionhub and Speedfusion, including the overhead that Speedfusion VPN requires.

No matter HOW you explain it, it simply doesn’t make sense that Speedfusion bonding an AT&T and Verizon WAN connection (with similar latency/bandwidth) gives Speedtest results of 35Mbs down when either of the single connections, on the same Peplink LAN device running Speedtest gives MORE than double this at between 80 to 90Mbs down.

I would expect AT&T plus Verizon bandwidth minus about 19% but the bonded connection is LESS than any single connection by ±100%.

My Speedfusion Solo is located on Vultr at their closest site to me.

Bonding is supposed to help speed, not just reliability.

What gives?


1 Like

Ah - that depends who is explaining it and what data they have to understand and explain your particular situation.

I was working with someone recently. They had 150Mbps of measured bandwidth (speedtest.net) available across all the available cellular connections (4 from three networks) when tested, but 60-70 Mbps in speedfusion. The cause of the issues for them was a combination of bufferbloat on the operator networks (MNO latency frequently hit 5 whole seconds when under load), packet loss on another providers upload stream and MNO #1 and MNO #2 were sharing bandwidth at the tower.

A common misconception. Actually Speedfusion Bonding - when configured properly, will provide high quality combined bandwidth and session reliability. Its not about raw speed.

If you want raw bandwidth alone and don’t care about packet loss, jitter or high latency then use load balancing and apps that only use UDP traffic and aren’t real time in nature (like file transfers or unidirectional video streaming).

If you actually want as much high quality bandwidth as possible from your available links then there are two tools you need to use to work out whats going on. The WAN analysis tool (fusionhub as server, Peplink hardware as client) to push and pull data back and forward across all WAN links at the same time to see what bandwidth is actually available point to point between you and the Fusionhub.

Then the speedfusion status graph and test tool that shows you packet loss and latency per link.

You need to analyse each wan link under load and in combination with other links to work out what the underlying issues are that cause the results you’re seeing.


Thanks Martin,
II know that it’s complicated. To most, bandwidth, simply stated, improves speed; not a scientific explanation.
In your example, the users got, let’s say half of there cumulative bandwidth. In my situation, I’m not even getting Speedfusion bandwidth equal to one of my two connections. Worse yet, I’m getting about 1/3 of the bandwidth for any ONE connection.

According to Speedfusion, users should expect 19% overhead, all things being equal. So best case, if I have two 50Mbs WANs processed by Speedfusion, I could expect 81Mbs through the VPN.

There are a LOT of factors that I’m aware. But nothing explains my results:

Expected - 2 X 80Mbs = 160Mbs - Speedfusion 19% (30Mbs) = 130Mbs (best case).
Actual - 2 X 80Mbs = 160Mbs - ??? = 30Mbs (actual through Speedfusion).

This means that the Speedfusion overhead is 81%. This result of 30Mbs is only about 40% of the bandwidth that any ONE of the participating WANs provide without Speedfusion.

I think that this is extreme and I can’t find any factor that explains this case.

Like I’m wondering, what gives? I think that Peplink ought work with me to figure out what is going on. What do you think?


I’ll take a look if you like. Will private message you in a sec.

1 Like

I think your Peplink partner should for sure.

You could always share your WAN analysis results and speedfusion graphs here for review if you like.

1 Like

I’d love to if I knew how. :slight_smile:

I understand. Either work with me to take a look (I have messaged you on here), speak with your Peplink partner / point of purchase and get their help, or log a ticket direct with Peplink.

1 Like

I’d love to hear the rest of this story…

1 Like