Buffer Bloat

Thanks, ah see that it suggests to test hard wired, most of my devices are wifi so im not going to get precise results over wifi.

Test it anyway. At least it will assure you everything is fine if it passes the test. If it doesn't pass then you can consider a long ethernet cable to take the testing one step further.
 
Test it anyway. At least it will assure you everything is fine if it passes the test. If it doesn't pass then you can consider a long ethernet cable to take the testing one step further.

It was pretty rubbish I got a C score on my MacBook and and a B on my iPhone, both connected to same access point over wifi.

Not got any issue though, I can game online perfectly fine for example.




Why the variation under same conditions?
 
Last edited:
It was pretty rubbish I got a C score on my MacBook and and a B on my iPhone, both connected to same access point over wifi.
Well, I won't say it's rubbish, but it can lead to some questionable results.

I just did that test once in Firefox just now, got an A. Then tried it in Edge and got a C. :confused: (Same machine, different browser, cat6 gigabit network throughout)

Firefox test

Edge test
 
Last edited:
Well, I won't say it's rubbish, but it can lead to some questionable results.

I just did that test once in Firefox just now, got an A. Then tried it in Edge and got a C. :confused: (Same machine, different browser, cat6 gigabit network throughout)
Did you repeat the test a few times in both browsers, to confirm the difference was the browser and nothing else? There are loads of variables here - different browser engines, tracking protection, SmartScreen, extensions etc etc. That's before you even consider the fact that no two runs will be the same, as your local network, router, and the wider Internet will differ from microsecond to microsecond. I'd run it again a few times, and if it averages out start looking at your router. If the test keeps showing Edge is crap, then switch to Firefox like the rest of us I suppose. :p
 
VM HUB 3 (modem mode) Eero pro 6 (wired backhaul)

I did the test over wifi though on my MacBook Pro, I would need to get some adapter dongle to use network cable.
Yep a cable would be a good start...

Here is an example of what I would use to troubleshoot my connection

iperf3 -c iperf.as42831.net -p 5300-5400 -b 20M -t 40

iperf3 -c speedtest-london.its-tg.net -t 40 -b 20M -R

mtr -n bbc.co.uk
press j for jitter run forward and reverse tests above at the same time which will give you useful info, ie how many retr am I getting, what is my ping when I saturate my connection, what is the jitter etc,etc. At the same time I would see what my cpu is doing while tranfering all this data back and forth... what memory am I using, is my QOS runing in the RED.
I use wsl om windows11 powershell --install wsl after install fire-up 3x ubuntu=2x iperf3 1x mtr on mac uhm.. dunno!
 
Try the Init7 server. It's also 10G but I find it much less variable than other public servers.

Code:
iperf3 -c speedtest.init7.net -P 10 -4 -R -V -O 3 -Z

If you're not on *nix, lose the -Z flag.
Yeah I was just making a point, it irks me these servers don't use the --bidir --get-server-info blah!
 
Sorry, it (quod erat demonstrandum) means you've proven the point. You're asking why your runs are variable, and then say they were performed over WiFi (which is, inherently, variable and subject to interference).

Exactly this. Wifi is not a predictable thing, unless you are a telecoms company and have access to seriously expensive kit. It is hihgly prone to interference from other sources.

(It still amazes me that my Wifi has trouble picking up my old laptop at 10 feet while BT happily chat to it from two miles away.)
 
Last edited:
It works for me ok.
It may just work in a local setting though not sure. parallel is very useful as you have pointed out. as well as udp testing which gives jitter.

--get
gives you the server view.

Code:
 .\iperf3 -c 192.168.0.110 -b 300M --bidir
Connecting to host 192.168.0.110, port 5201
[  5] local 192.168.0.106 port 50877 connected to 192.168.0.110 port 5201
[  7] local 192.168.0.106 port 50878 connected to 192.168.0.110 port 5201
[ ID][Role] Interval           Transfer     Bitrate
[  5][TX-C]   0.00-1.01   sec  35.8 MBytes   298 Mbits/sec
[  7][RX-C]   0.00-1.01   sec  35.8 MBytes   298 Mbits/sec
[  5][TX-C]   1.01-2.01   sec  35.8 MBytes   299 Mbits/sec
[  7][RX-C]   1.01-2.01   sec  35.8 MBytes   299 Mbits/sec
[  5][TX-C]   2.01-3.00   sec  35.6 MBytes   302 Mbits/sec
[  7][RX-C]   2.01-3.00   sec  35.6 MBytes   302 Mbits/sec
[  5][TX-C]   3.00-4.01   sec  35.9 MBytes   299 Mbits/sec
[  7][RX-C]   3.00-4.01   sec  35.9 MBytes   299 Mbits/sec
[  5][TX-C]   4.01-5.01   sec  35.8 MBytes   299 Mbits/sec
[  7][RX-C]   4.01-5.01   sec  35.8 MBytes   300 Mbits/sec
[  5][TX-C]   5.01-6.01   sec  35.5 MBytes   299 Mbits/sec
[  7][RX-C]   5.01-6.01   sec  22.9 MBytes   193 Mbits/sec
[  5][TX-C]   6.01-7.00   sec  36.1 MBytes   305 Mbits/sec
[  7][RX-C]   6.01-7.00   sec  48.4 MBytes   408 Mbits/sec
[  5][TX-C]   7.00-8.00   sec  35.8 MBytes   300 Mbits/sec
[  7][RX-C]   7.00-8.00   sec  35.6 MBytes   299 Mbits/sec
[  5][TX-C]   8.00-9.01   sec  35.6 MBytes   297 Mbits/sec
[  7][RX-C]   8.00-9.01   sec  36.0 MBytes   300 Mbits/sec
[  5][TX-C]   9.01-10.00  sec  36.0 MBytes   304 Mbits/sec
[  7][RX-C]   9.01-10.00  sec  26.2 MBytes   221 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval           Transfer     Bitrate
[  5][TX-C]   0.00-10.00  sec   358 MBytes   300 Mbits/sec                  sender
[  5][TX-C]   0.00-10.01  sec   357 MBytes   299 Mbits/sec                  receiver
[  7][RX-C]   0.00-10.00  sec   348 MBytes   292 Mbits/sec                  sender
[  7][RX-C]   0.00-10.01  sec   348 MBytes   292 Mbits/sec                  receiver






.\iperf3 -h
Usage: iperf3 [-s|-c host] [options]
iperf3 [-h|--help] [-v|--version]

Server or Client:
-p, --port # server port to listen on/connect to
-f, --format [kmgtKMGT] format to report: Kbits, Mbits, Gbits, Tbits
-i, --interval # seconds between periodic throughput reports
-I, --pidfile file write PID file
-F, --file name xmit/recv the specified file
-A, --affinity n/n,m set CPU affinity
-B, --bind <host> bind to the interface associated with the address <host>
-V, --verbose more detailed output
-J, --json output in JSON format
--logfile f send output to a log file
--forceflush force flushing output at every interval
--timestamps<=format> emit a timestamp at the start of each output line
(optional "=" and format string as per strftime(3))
--rcv-timeout # idle timeout for receiving data
(default 120000 ms)
-d, --debug emit debugging output
-v, --version show version information and quit
-h, --help show this message and quit
Server specific:
-s, --server run in server mode
-D, --daemon run the server as a daemon
-1, --one-off handle one client connection then exit
--server-bitrate-limit #[KMG][/#] server's total bit rate limit (default 0 = no limit)
(optional slash and number of secs interval for averaging
total data rate. Default is 5 seconds)
--idle-timeout # restart idle server after # seconds in case it
got stuck (default - no timeout)
Client specific:
-c, --client <host> run in client mode, connecting to <host>
-u, --udp use UDP rather than TCP
--connect-timeout # timeout for control connection setup (ms)
-b, --bitrate #[KMG][/#] target bitrate in bits/sec (0 for unlimited)
(default 1 Mbit/sec for UDP, unlimited for TCP)
(optional slash and packet count for burst mode)
--pacing-timer #[KMG] set the timing for pacing, in microseconds (default 1000)
-t, --time # time in seconds to transmit for (default 10 secs)
-n, --bytes #[KMG] number of bytes to transmit (instead of -t)
-k, --blockcount #[KMG] number of blocks (packets) to transmit (instead of -t or -n)
-l, --length #[KMG] length of buffer to read or write
(default 128 KB for TCP, dynamic or 1460 for UDP)
--cport <port> bind to a specific client port (TCP and UDP, default: ephemeral port)
-P, --parallel # number of parallel client streams to run
-R, --reverse run in reverse mode (server sends, client receives)
--bidir run in bidirectional mode.
Client and server send and receive data.
-w, --window #[KMG] set window size / socket buffer size
-M, --set-mss # set TCP/SCTP maximum segment size (MTU - 40 bytes)
-N, --no-delay set TCP/SCTP no delay, disabling Nagle's Algorithm
-4, --version4 only use IPv4
-6, --version6 only use IPv6
-S, --tos N set the IP type of service, 0-255.
The usual prefixes for octal and hex can be used,
i.e. 52, 064 and 0x34 all specify the same value.
--dscp N or --dscp val set the IP dscp value, either 0-63 or symbolic.
Numeric values can be specified in decimal,
octal and hex (see --tos above).
-Z, --zerocopy use a 'zero copy' method of sending data
-O, --omit N omit the first n seconds
-T, --title str prefix every output line with this string
--extra-data str data string to include in client and server JSON
--get-server-output get results from server
--udp-counters-64bit use 64-bit counters in UDP test packets
--repeating-payload use repeating pattern in payload, instead of
randomized payload (like in iperf2)
--dont-fragment set IPv4 Don't Fragment flag

[KMG] indicates options that support a K/M/G suffix for kilo-, mega-, or giga-

iperf3 homepage at: https://software.es.net/iperf/
Report bugs to: https://github.com/esnet/iperf
 
It works for me ok.
It may just work in a local setting though not sure. parallel is very useful as you have pointed out. as well as udp testing which gives jitter.

--get
gives you the server view.
Doh! The documentation at iperf.fr says bidirectional was deprecated for v3. Serves me right for not double checking man iperf3. :o
 
Back
Top Bottom