SpeedFusion Connect for gaming

Hey all,
I have started playing around with the SFC stuff on my Balance 310x. I am trying to determine the best settings for lowest possible latency with the least amount of packet loss.

I have three pipes that I am bonding. Low capacity DSL 3/1.5 (but steady latency until congested), a 40/16 microwave connection that is low latency except during peak hours (and then it suffers from jitter spikes), and a Starlink gen 2 connection.

I have found that smoothing all UDP traffic causes congestion on the DSL link which causes packet loss. I am able to use the “normal” setting if I isolate only the game stream To the tunnel.

my goal is to have the same udp packet go down all 3 WAN links, and whichever packet makes it there first is the one that gets sent to the game server. What are the optimal settings for that?

I have been doing some testing with these settings and it looks like there is no “easy button” for what I wanting to do.

Obviously, the best approach would be to have smoothing and FEC enabled in the tunnel, but then the DSL link becomes saturated and starts dropping packets. The excessive packet loss/congestion causes an unpleasant user experience.

So, the DSL link is the “weak” spot for throughput. To mitigate this, I am going to limit what all traffic can go down the tunnel. Rather than all UDP from that source address, I will only send the game data through the tunnel. Discord chat can go directly to WAN. So two outbound policies – one for UDP 50K-60K (game data) and the other for 37K to 40K (discord chat).

Now that I have offloaded some data out of the tunnel, I can enable wan smoothing to Normal. Without WAN smoothing – it looks like the tunnel is using packet based round robin – which results in the LAST packet making it to the speed fusion hub is what is forwarded.

My current setup is for the tunnel to include all 3 WAN links, with Normal WAN Smoothing, No FEC, set with the default “bonding”, maximum level on the same link is off, and I am using TCP for the data port.

The StarLink connection suffers from lots of packet loss on the uplink. I switched from UDP to TCP to try to mitigate this. I have seen better results for TCP flows opposed to UDP flows. I think the built in retransmissions will keep data from dropping out of the data stream. The game data is a UDP stream, so the TCP encapsulation to the SFC is worth the additional overhead (I think).

So, in summary – WAN smoothing is a requirement for what we are wanting to accomplish. WAN Smoothing increases the bandwidth used which can cause congestion on low throughput links. Very specific isolation of the gaming traffic is required to keep the overall usage of the DSL link low.

The end result (as best I can tell thus far) is that the maximum latency should ALWAYS be the DSL line - which is typically around 60-70ms. But, there are two chances for a packet to make it there in less time - one on the microwave link (20-30ms), and one on the StarLink (40-60ms). During non-peak hours, the fastest route will be the microwave link, and then every now and again the StarLink will be the fastest; and during times of local LAN usage - the DSL link will be the path that gets it there the quickest.

Now, after setting all of this up and testing it – I got to my computer this morning and sometime during the night - the StarLink WAN link was removed from the tunnel. The UI indicated that “no data was received” (or something like that). I had to manually disconnect/reconnect the WAN to get it to rejoin the tunnel. Anyone know what that is all about? The even log didn’t even pick up on the fact it was removed from the tunnel…

Thanks for taking this journey with me. I hope you brought snacks to share with the group

Have you tried Dynamic Weighted Bonding? It is useful when bonding multiple WAN links with significant bufferbloat issues. It can avoid sending packets into a “bad” WAN link when the WAN link’s performance or stability is too poor to be a part of the bonded tunnel.

1 Like

I saw it as an option, but since the description implies that it is for cellular – I didn’t try it. I will give it a try. Thanks for the suggestion!

So, things seem to be working pretty alright at the moment, though I confess - I haven’t had much time for testing it while playing games. Being an adult sucks sometimes…

I am seeing a little bit of a concerning issue, and maybe someone has already come up with a workaround. When I check the status of the SFC tunnel in the mornings - sometimes the StarLink WAN link is down. There is a red square next to the WAN, and the error message says “Not Available - link failure, no data received”. I have no doubt that a connection going through StarLink would crap out at some point – they even specify that there will be temporary blips as new satellites are picked up. What I don’t understand is why Peplink doesn’t ever try to re-establish that portion of the tunnel. Is there any way to manipulate this behavior?

I tried to investigate what happened with the StarLink WAN - I don’t see anything in the event log other than the SpeedFusion event log that states - “SpeedFusion: SFC-SEA-013 (SFC-SEA-013, sn:1195-D38B-3520) disconnected from SFC-SEA (link failure detected)” – but when I look for corresponding events in the System log, I don’t find any.

Is there a way to A.) manipulate retry settings to prevent it from being dropped from the tunnel or B.) manipulate some auto recovery logic? It looks like the WAN crapped out about 24 hours ago, and I see no signs that it has tried to re-establish this portion of the tunnel. The only way I have been able to get it to rejoin the tunnel is to manually disconnect/reconnect the StarLink WAN. Any ideas?