Weird Speed Test Results

I have a dual WAN setup (2 cable modems) and Peplink Balance One. Most of the time when I run a speed test (on one of the major services, e.g., ATT, etc.) I get the expected speed, about 96.0/9.0.

However, about 1 out of 5 times, the upload speed seems to only be using one of my WANs so I get a lower speed. If I immediately repeat the test, I get the full bandwidth.

I’ve been recently trying the beta speediest at and seeing similar issues: download is fine, but upload is bouncing around like crazy. Example: Speed result of 96.2/5.71 Mbps | DSLReports, ISP Information

I don’t know if this is a bug in the DSLReports test, or perhaps a subtle bug in the Balance One? I’m curious if others see normal or abnormal speed test results…

This is not a bug with the speedtest sites or the Balance router. Those tests allow for 2 or more sockets to be used during the test, so you end up using both of your connections simultaneously. This is a double-edged sword though because while it indeed is showing you your total capacity, but in real life your actual transfer speed will be equal to the single connection that is being used.

Unless of course if you are using our SpeedFusion VPN bonding technology. :slight_smile:

Hi Tim,

Thanks, but I’m aware of the 1 vs. 2 WAN issue, but I’m seeing weirdness even with a single WAN enabled.

Please check out this graph:

These tests were made with WAN 1 disabled (thus using only WAN2, a 55/5 TWC cable modem).

Notice how in a few cases, the Blue Upload bandwidth spikes well above 5.0mbps. Since my cable modem is supposed to only deliver 5.0 mbps upload speed, this seems… somewhat disturbing.


  • Some companies offered a “turbo” feature which temporarily boosted your speeds, but I thought that TWC wasn’t doing that any longer.
  • The Peplink graphing algorithm is wrong
  • My TWC “5.0” upload modem is delivering higher than it’s rated speed.
  • Gremlins


Traffics will be send out based on available bandwidth (when you do speed test) before Qos kick in on ISP side. Please refer my explanation below (just an example).

Browser (30Mbps upload) —> Balance router (30Mbps upload) —> ISP (5Mbps upload) —> Speedtest server

Therefore what you got on Real-time graph are acceptable.

Another interesting issue:

When running multiple speed tests on multiple services (ookla, dslreports, etc.) I often see the following pattern:

Download is always 96. Upload is sometimes 9 (representing WAN1 + WAN2). But sometimes Upload is 5 (representing WAN1 only). If i re-run the test immediately, upload will usually jump back to 9 (WAN1+WAN).

From my research, it looks like the speed tests are using 2 to 8 streams for upload. So one would expect that the Peplink load balancing algorithms would split the streams across WAN1 + WAN2.

I wonder if there is some case in which this doesn’t work correctly?

My setup’s outbound policy only HTTPS_Persistence (Src, Auto) / ANY / TCP 443.


This could be browser behavior when you do speed test or affected by Default Outbound Policy. Anyway, What you have done will not give you an accurate result. Like what Tim has mentioned, in real life your actual transfer speed will be equal to the single connection that is being used.

In real real life, I have multiple devices and apps active, and they typically use several (if not dozens) of streams. So the overall bandwidth (up and down) is what I’m interested in measuring, and it should generally be WAN1+WAN2.

As I said, the download test always works fine : (WAN1+WAN2). The upload test, most of the time it works fine, but sometimes, it only uses one WAN for upload bandwidth (in spite of 8 streams going).

Is there a situation in which the Outbound policy might not deal with this well and why would it be inconsistent from test to test?


You wouldn’t get WAN1+WAN2 for a same session. Assume you set Auto in Default Policy. Let me explain the situation:-

[table=“width: 500”]

WAN1 latency (ms)
WAN2 latency (ms)
Preferred WAN

App A

App B

App C

App D

App E


User A launched 3 applications. Only last application will uses WAN2 since WAN2 has lower latency at that time. Please take note same session will stick to same WAN until session timeout. So you can’t achieve WAN1+WAN2 for same session unless you are using SpeedFusion Bonding. You can’t rely on speed test to measure your application behavior.

Hope this help. :slight_smile:

About 75% of the time when running the speed test from one machine, I do get WAN1+WAN2 upload speeds. But about 25% of the time I do not.

I’m not understanding how this would happen under your explanation.

The default algorithm is lowest latency, so the Balance will always favor the connection with the lowest latency in real-time. If latency goes up slightly because a WAN is under load than the other WAN will kick in, this will lead to erratic speed test results. Again, this is all session based so the speed test results should not be relied on for actual applications.

If you want you could change your default policy to weighted balance and give both WAN’s a value of 10. This will provide a round robin effect and each new session opened will go out a different WAN.

Thanks, that makes perfect sense now.

In the case where the two lines are pretty well matched, I wonder if the weighted balance / round robin algorithm might be a little better at spreading out the load? So far the Peplink has been great with mostly default settings - this isn’t an area I’ve played with.

Also : if two different machines do an upload one after the other, will the “lowest latency” approach usually send both over the same WAN? Or does it do round-robin since they aren’t the same machine or session?


If your concern are spreading the load across 2 WANs, Weighted Balance is right choice for you.

This is depending on the condition of WAN links. For example:-

  1. User A is performing upload via WAN1.
  2. WAN1 still having lower latency if compare to WAN2.
  3. User B performs upload.
  4. WAN1 will be selected for user B since WAN1 has lower latency than WAN2

Thank you for that explanation - in fact, I think the “lowest latency” default may be the issue here for another reason: I have two different models of cable modems in use (Arris DG1670 and SurfBoard 6141), and I’ve seen reports from others that the 6141 has lower ping latency than the 1670 - if so, this would suggest that the BalanceOne is generally going to favor the 6141 modem.

I will try the weighted balance suggestion with 10 value for both and report back.