Also, don't forget to measure with working-loads too
--working-load[=up|down|bidir][,n]
request a concurrent working load, currently TCP stream(s), defaults to
full duplex (or bidir) unless the up or down option is provided. The
number of TCP streams defaults to 1 and can be changed via the n value,
e.g. --working-load=down,4 will use four TCP streams from server to the
client as the working load. The IP ToS will be BE (0x0) for working load
traffic.
--working-load-cca
Set the congestion control algorithm to be used for TCP working loads
Maybe keep a few rasberry pi's in one's backback with iperf 2? That way
you're always prepared for latency emergencies. The Rpi5 has a TCXO for
it's clock.
Bob
It's frustrating to me that even experts here don't measure latency as
a first priority. The tooling has been available for years to do this.
And it's only getting better and more feature rich, e.g. bounce-back.
--bounceback[=n]
run a TCP bounceback or rps test with optional number writes in a
burst per value of n. The default is ten writes every period and the
default period is one second (Note: set size with
--bounceback-request). See NOTES on clock unsynchronized detections.
--bounceback-hold n
request the server to insert a delay of n milliseconds between its
read and write (default is no delay)
--bounceback-no-quickack
request the server not set the TCP_QUICKACK socket option (disabling
TCP ACK delays) during a bounceback test (see NOTES)
--bounceback-period[=n]
request the client schedule its send(s) every n seconds (default is
one second, use zero value for immediate or continuous back to back)
--bounceback-request n
set the bounceback request size in units bytes. Default value is 100
bytes.
--bounceback-reply n
set the bounceback reply size in units bytes. This supports asymmetric
message sizes between the request and the reply. Default value is
zero, which uses the value of --bounceback-request.
--bounceback-txdelay n
request the client to delay n seconds between the start of the working
load and the bounceback traffic (default is no delay)
https://iperf2.sourceforge.io/iperf-manpage.html
Bob
If video conferencing worked well enough, they would not have to all
get together in one place and would instead hold IETF meetings online
...?
Did anyone measure latency? Does anyone measure throughput of
"useful" traffic - e.g., excluding video/audio data that didn't arrive
in time to be actually used on the screen or speaker?
Jack Haverty
On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
if they had not been all together they would have been consuming
tons of video capacity doing video conference calls....
:-))
v
On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain
<[email protected]> wrote:
On the subject of how much bandwidth does one household need,
here's a fun stat for you.
At the IETF’s 118th meeting [1] last week (Nov 4 – 10, 2023),
there were over 1,000 engineers in attendance. At peak there were
870 devices connected to the WiFi network. Peak bandwidth usage:
* Downstream peak ~750 Mbps
* Upstream ~250 Mbps
From my pre-meeting Twitter poll
(https://twitter.com/jlivingood/status/1720060429311901873):
_______________________________________________
Nnagain mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/nnagain
--
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346
until further notice
_______________________________________________
Nnagain mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/nnagain
Links:
------
[1] https://www.ietf.org/how/meetings/118/
_______________________________________________
Nnagain mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/nnagain
_______________________________________________
Nnagain mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/nnagain
_______________________________________________
Nnagain mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/nnagain
