You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(83) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(29) |
Feb
(43) |
Mar
(9) |
Apr
(9) |
May
(21) |
Jun
(43) |
Jul
(32) |
Aug
(12) |
Sep
(17) |
Oct
(29) |
Nov
(9) |
Dec
(15) |
2004 |
Jan
(8) |
Feb
(48) |
Mar
(50) |
Apr
(37) |
May
(12) |
Jun
(14) |
Jul
(33) |
Aug
(26) |
Sep
(16) |
Oct
(38) |
Nov
(39) |
Dec
(12) |
2005 |
Jan
(5) |
Feb
(22) |
Mar
(19) |
Apr
(24) |
May
(34) |
Jun
(21) |
Jul
(38) |
Aug
(14) |
Sep
(39) |
Oct
(25) |
Nov
(28) |
Dec
(18) |
2006 |
Jan
(19) |
Feb
(17) |
Mar
(47) |
Apr
(14) |
May
(27) |
Jun
(33) |
Jul
(3) |
Aug
(29) |
Sep
(12) |
Oct
(6) |
Nov
(8) |
Dec
(7) |
2007 |
Jan
(6) |
Feb
(11) |
Mar
(8) |
Apr
(7) |
May
(17) |
Jun
(24) |
Jul
(20) |
Aug
(25) |
Sep
(6) |
Oct
(7) |
Nov
(8) |
Dec
(5) |
2008 |
Jan
(7) |
Feb
(9) |
Mar
(22) |
Apr
(22) |
May
(33) |
Jun
(10) |
Jul
(15) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(8) |
Dec
(5) |
2009 |
Jan
(3) |
Feb
(5) |
Mar
|
Apr
(5) |
May
(4) |
Jun
(5) |
Jul
(5) |
Aug
(6) |
Sep
(2) |
Oct
(7) |
Nov
(11) |
Dec
(12) |
2010 |
Jan
|
Feb
(16) |
Mar
(27) |
Apr
(40) |
May
(13) |
Jun
(11) |
Jul
(10) |
Aug
(8) |
Sep
(9) |
Oct
(2) |
Nov
(5) |
Dec
(6) |
2011 |
Jan
(9) |
Feb
|
Mar
(17) |
Apr
(15) |
May
(4) |
Jun
(10) |
Jul
(9) |
Aug
(4) |
Sep
(4) |
Oct
(11) |
Nov
(12) |
Dec
(4) |
2012 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(9) |
May
(6) |
Jun
|
Jul
(6) |
Aug
(6) |
Sep
(3) |
Oct
(1) |
Nov
(3) |
Dec
(8) |
2013 |
Jan
(2) |
Feb
(4) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
(6) |
Aug
(2) |
Sep
(2) |
Oct
(10) |
Nov
(4) |
Dec
(3) |
2014 |
Jan
(3) |
Feb
(17) |
Mar
(5) |
Apr
(4) |
May
(2) |
Jun
(1) |
Jul
(5) |
Aug
(36) |
Sep
(51) |
Oct
(2) |
Nov
(8) |
Dec
(6) |
2015 |
Jan
(26) |
Feb
(3) |
Mar
(9) |
Apr
(2) |
May
|
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(3) |
2016 |
Jan
|
Feb
(9) |
Mar
|
Apr
|
May
|
Jun
(13) |
Jul
(16) |
Aug
(8) |
Sep
(2) |
Oct
(11) |
Nov
(7) |
Dec
|
2017 |
Jan
(25) |
Feb
(8) |
Mar
(8) |
Apr
(3) |
May
(12) |
Jun
(18) |
Jul
(3) |
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
(1) |
Dec
(1) |
2018 |
Jan
(2) |
Feb
(8) |
Mar
(2) |
Apr
(28) |
May
(32) |
Jun
(7) |
Jul
(11) |
Aug
(11) |
Sep
(18) |
Oct
(4) |
Nov
(9) |
Dec
(4) |
2019 |
Jan
(6) |
Feb
|
Mar
|
Apr
(1) |
May
(13) |
Jun
(13) |
Jul
(1) |
Aug
(6) |
Sep
(9) |
Oct
(9) |
Nov
(1) |
Dec
(5) |
2020 |
Jan
(2) |
Feb
(7) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
(6) |
Jul
(11) |
Aug
(10) |
Sep
(3) |
Oct
(3) |
Nov
(6) |
Dec
(23) |
2021 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
(13) |
Jul
(2) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
2022 |
Jan
(3) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(3) |
Jul
(4) |
Aug
(4) |
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
|
2023 |
Jan
(2) |
Feb
(8) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(3) |
Sep
(16) |
Oct
|
Nov
(1) |
Dec
(2) |
2024 |
Jan
|
Feb
|
Mar
(2) |
Apr
(3) |
May
(5) |
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Aleksey E. <al...@mi...> - 2024-09-12 11:49:41
|
Good day! We added iperf2 services on NL servers: iperf -c speedtest.nl1.mirhosting.net -p 5000-5010 -P 10 (for IPv4) iperf -c speedtest.nl1.mirhosting.net -p 5000-5010 -V -P 10 (for IPv6) iperf -c speedtest.nl3.mirhosting.net -p 5000-5010 -P 10 (for IPv4) iperf -c speedtest.nl3.mirhosting.net -p 5000-5010 -V -P 10 (for IPv6) And launched server in US: location: 10013, New York, NY, US Connection: 20Gbps, IPv4 & IPv6 iperf3 -c speedtest.us.mirhosting.net -p 5200-5210 -P 10 -4 (for IPv4) iperf3 -c speedtest.us.mirhosting.net -p 5200-5210 -P 10 -6 (for IPv6) iperf -c speedtest.us.mirhosting.net -p 5000-5010 -P 10 (for IPv4) iperf -c speedtest.us.mirhosting.net -p 5000-5010 -V -P 10 (for IPv6) And now we have three servers for a public iperf2/3 tests: https://speedtest.nl1.mirhosting.net/ https://speedtest.nl3.mirhosting.net/ https://speedtest.us.mirhosting.net/ On 16/08/2024 22:46, Bob McMahon wrote: > Some may benefit from iperf 2 public servers > https://sourceforge.net/projects/iperf2/ > > Bob > > On Fri, Aug 16, 2024 at 3:14 AM Aleksey Ermak via Iperf-users > <ipe...@li...> wrote: > > Hello! > > We added a two high-performance servers for iperf3, and we would > like to > add them to your list of public servers > https://iperf.fr/iperf-servers.php > > Our site: https://mirhosting.com/ > logo: attached. > > https://speedtest.nl1.mirhosting.net/ > location: 8253PJ, Dronten, The Netherlands > Connection: 40Gbps, IPv4 & IPv6 > > You can use IPERFv3 (client sends, server receives) > iperf3 -c speedtest.nl1.mirhosting.net > <http://speedtest.nl1.mirhosting.net> -p 5201-5209 -P 10 -4 (for IPv4) > iperf3 -c speedtest.nl1.mirhosting.net > <http://speedtest.nl1.mirhosting.net> -p 5201-5209 -P 10 -6 (for IPv6) > ( -R reverse mode (server sends, client receives) > iperf3 -c speedtest.nl1.mirhosting.net > <http://speedtest.nl1.mirhosting.net> -p 5201-5209 -P 10 -4 -R > (for IPv4) > iperf3 -c speedtest.nl1.mirhosting.net > <http://speedtest.nl1.mirhosting.net> -p 5201-5209 -P 10 -6 -R > (for IPv6) > > https://speedtest.nl3.mirhosting.net/ > location: 1098XG, Amsterdam, The Netherlands > Connection: 40Gbps, IPv4 & IPv6 > > You can use IPERFv3 (client sends, server receives) > > iperf3 -c speedtest.nl3.mirhosting.net > <http://speedtest.nl3.mirhosting.net> -p 5201-5209 -P 10 -4 (for IPv4) > iperf3 -c speedtest.nl3.mirhosting.net > <http://speedtest.nl3.mirhosting.net> -p 5201-5209 -P 10 -6 (for IPv6) > ( -R reverse mode (server sends, client receives) > iperf3 -c speedtest.nl3.mirhosting.net > <http://speedtest.nl3.mirhosting.net> -p 5201-5209 -P 10 -4 -R > (for IPv4) > iperf3 -c speedtest.nl3.mirhosting.net > <http://speedtest.nl3.mirhosting.net> -p 5201-5209 -P 10 -6 -R > (for IPv6) > > Thank you! > > -- > > Regards / С уважением, > Aleksey Ermak > Innovation IT Solutions Corp. > Group of international companies to deliver Innovative Internet > Technologies > ------------------------------ > E: al...@mi... > W: www.mirhosting.com <http://www.mirhosting.com> > _______________________________________________ > Iperf-users mailing list > Ipe...@li... > https://lists.sourceforge.net/lists/listinfo/iperf-users > > > This electronic communication and the information and any files > transmitted with it, or attached to it, are confidential and are > intended solely for the use of the individual or entity to whom it is > addressed and may contain information that is confidential, legally > privileged, protected by privacy laws, or otherwise restricted from > disclosure to anyone else. If you are not the intended recipient or > the person responsible for delivering the e-mail to the intended > recipient, you are hereby notified that any use, copying, > distributing, dissemination, forwarding, printing, or copying of this > e-mail is strictly prohibited. If you received this e-mail in error, > please return the e-mail to the sender, delete it from your computer, > and destroy any printed copy of it. -- Regards, Aleksey Ermak Innovation IT Solutions Corp. Group of international companies to deliver Innovative Internet Technologies ------------------------------ E:al...@mi... W:www.mirhosting.com |
From: Bob M. <bob...@br...> - 2024-08-17 00:35:02
|
Some may benefit from iperf 2 public servers https://sourceforge.net/projects/iperf2/ Bob On Fri, Aug 16, 2024 at 3:14 AM Aleksey Ermak via Iperf-users < ipe...@li...> wrote: > Hello! > > We added a two high-performance servers for iperf3, and we would like to > add them to your list of public servers https://iperf.fr/iperf-servers.php > > Our site: https://mirhosting.com/ > logo: attached. > > https://speedtest.nl1.mirhosting.net/ > location: 8253PJ, Dronten, The Netherlands > Connection: 40Gbps, IPv4 & IPv6 > > You can use IPERFv3 (client sends, server receives) > iperf3 -c speedtest.nl1.mirhosting.net -p 5201-5209 -P 10 -4 (for IPv4) > iperf3 -c speedtest.nl1.mirhosting.net -p 5201-5209 -P 10 -6 (for IPv6) > ( -R reverse mode (server sends, client receives) > iperf3 -c speedtest.nl1.mirhosting.net -p 5201-5209 -P 10 -4 -R (for IPv4) > iperf3 -c speedtest.nl1.mirhosting.net -p 5201-5209 -P 10 -6 -R (for IPv6) > > https://speedtest.nl3.mirhosting.net/ > location: 1098XG, Amsterdam, The Netherlands > Connection: 40Gbps, IPv4 & IPv6 > > You can use IPERFv3 (client sends, server receives) > > iperf3 -c speedtest.nl3.mirhosting.net -p 5201-5209 -P 10 -4 (for IPv4) > iperf3 -c speedtest.nl3.mirhosting.net -p 5201-5209 -P 10 -6 (for IPv6) > ( -R reverse mode (server sends, client receives) > iperf3 -c speedtest.nl3.mirhosting.net -p 5201-5209 -P 10 -4 -R (for IPv4) > iperf3 -c speedtest.nl3.mirhosting.net -p 5201-5209 -P 10 -6 -R (for IPv6) > > Thank you! > > -- > > Regards / С уважением, > Aleksey Ermak > Innovation IT Solutions Corp. > Group of international companies to deliver Innovative Internet > Technologies > ------------------------------ > E: al...@mi... > W: www.mirhosting.com > _______________________________________________ > Iperf-users mailing list > Ipe...@li... > https://lists.sourceforge.net/lists/listinfo/iperf-users > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. |
From: Aleksey E. <al...@mi...> - 2024-08-16 10:12:24
|
Hello! We added a two high-performance servers for iperf3, and we would like to add them to your list of public servers https://iperf.fr/iperf-servers.php Our site: https://mirhosting.com/ logo: attached. https://speedtest.nl1.mirhosting.net/ location: 8253PJ, Dronten, The Netherlands Connection: 40Gbps, IPv4 & IPv6 You can use IPERFv3 (client sends, server receives) iperf3 -c speedtest.nl1.mirhosting.net -p 5201-5209 -P 10 -4 (for IPv4) iperf3 -c speedtest.nl1.mirhosting.net -p 5201-5209 -P 10 -6 (for IPv6) ( -R reverse mode (server sends, client receives) iperf3 -c speedtest.nl1.mirhosting.net -p 5201-5209 -P 10 -4 -R (for IPv4) iperf3 -c speedtest.nl1.mirhosting.net -p 5201-5209 -P 10 -6 -R (for IPv6) https://speedtest.nl3.mirhosting.net/ location: 1098XG, Amsterdam, The Netherlands Connection: 40Gbps, IPv4 & IPv6 You can use IPERFv3 (client sends, server receives) iperf3 -c speedtest.nl3.mirhosting.net -p 5201-5209 -P 10 -4 (for IPv4) iperf3 -c speedtest.nl3.mirhosting.net -p 5201-5209 -P 10 -6 (for IPv6) ( -R reverse mode (server sends, client receives) iperf3 -c speedtest.nl3.mirhosting.net -p 5201-5209 -P 10 -4 -R (for IPv4) iperf3 -c speedtest.nl3.mirhosting.net -p 5201-5209 -P 10 -6 -R (for IPv6) Thank you! -- Regards / С уважением, Aleksey Ermak Innovation IT Solutions Corp. Group of international companies to deliver Innovative Internet Technologies ------------------------------ E: al...@mi... W: www.mirhosting.com |
From: Bob M. <bob...@br...> - 2024-05-23 15:48:10
|
Can you provide the commands you used? Here's a link on threads. https://en.m.wikipedia.org/w/index.php?title=Thread_(computing)&action=edit§ion=17 Threads can take advantage of multicore a systems to get better performance. https://en.wikipedia.org/wiki/Multi-core_processor Bob On Thu, May 23, 2024, 1:21 AM Isaac Ugbode <isa...@ho...> wrote: > Hi, hoping someone might be able to help me with this query. I'm new to > networking and in my new role we've just installed a SOGEA line into our > office. As part of the install, we wanted to test the line to see what > speeds we would get. Initially some tests were done sending files from my > office to another but the results returned were not great. I queried the > test as sending files would have all manner of over heads and after some > searching, found iPerf. > > I'm running a single thread test and the speeds do not appear to be great > but when running a multi-thread test the speeds returned appear to be more > in line with what our provider suggests we would get. What is the > difference between single thread and multi-thread? > > Thanks > > Isaac > _______________________________________________ > Iperf-users mailing list > Ipe...@li... > https://lists.sourceforge.net/lists/listinfo/iperf-users > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. |
From: Bob M. <bob...@br...> - 2024-05-23 15:47:53
|
Here's the proper thread link https://en.m.wikipedia.org/w/index.php?title=Thread_%28computing%29 On Thu, May 23, 2024, 8:20 AM Bob McMahon <bob...@br...> wrote: > Can you provide the commands you used? > > Here's a link on threads. > > > https://en.m.wikipedia.org/w/index.php?title=Thread_(computing)&action=edit§ion=17 > > Threads can take advantage of multicore a systems to get better > performance. > > https://en.wikipedia.org/wiki/Multi-core_processor > > Bob > > > > On Thu, May 23, 2024, 1:21 AM Isaac Ugbode <isa...@ho...> > wrote: > >> Hi, hoping someone might be able to help me with this query. I'm new to >> networking and in my new role we've just installed a SOGEA line into our >> office. As part of the install, we wanted to test the line to see what >> speeds we would get. Initially some tests were done sending files from my >> office to another but the results returned were not great. I queried the >> test as sending files would have all manner of over heads and after some >> searching, found iPerf. >> >> I'm running a single thread test and the speeds do not appear to be great >> but when running a multi-thread test the speeds returned appear to be more >> in line with what our provider suggests we would get. What is the >> difference between single thread and multi-thread? >> >> Thanks >> >> Isaac >> _______________________________________________ >> Iperf-users mailing list >> Ipe...@li... >> https://lists.sourceforge.net/lists/listinfo/iperf-users >> > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. |
From: Isaac U. <isa...@ho...> - 2024-05-23 08:20:19
|
Hi, hoping someone might be able to help me with this query. I'm new to networking and in my new role we've just installed a SOGEA line into our office. As part of the install, we wanted to test the line to see what speeds we would get. Initially some tests were done sending files from my office to another but the results returned were not great. I queried the test as sending files would have all manner of over heads and after some searching, found iPerf. I'm running a single thread test and the speeds do not appear to be great but when running a multi-thread test the speeds returned appear to be more in line with what our provider suggests we would get. What is the difference between single thread and multi-thread? Thanks Isaac |
From: Sarah L. <swl...@es...> - 2024-05-13 20:09:58
|
ESnet (Energy Sciences Network) is proud to announce the availability of iperf-3.17.1. This release fixes problems with version numbers in several places. It is functionally identical to iperf-3.17. iperf3 is a tool for measuring the maximum TCP, UDP, and SCTP throughput along a path, allowing for the tuning of various parameters and reporting measurements such as throughput, jitter, and datagram packet loss. It is fully supported on Linux, FreeBSD, and macOS. It may run on other platforms as well, although it has not received the same attention and testing. Note that iperf3 is not compatible with, and will not interoperate with, version 2 or earlier of iperf, although the two versions can co-exist on the same hosts and networks. The source code for iperf 3.17.1 is available at: https://downloads.es.net/pub/iperf/iperf-3.17.1.tar.gz SHA256 hash: 84404ca8431b595e86c473d8f23d8bb102810001f15feaf610effd3b318788aa iperf3 is freely-redistributable under a 3-clause BSD license. More information can be found in the LICENSE file inside the source distribution. Additional documentation for iperf3 can be found at: https://software.es.net/iperf More information about iperf3 (including the issue tracker, source code repository access, and discussion forum) can be found on the iperf3 page on GitHub at: https://github.com/esnet/iperf User questions can go to the iperf users list (which is more-or-less shared between iperf2 and iperf3): ipe...@li... Mailing list information and archives can be found at: https://lists.sourceforge.net/lists/listinfo/iperf-users The mailing list for iperf3 development is: ipe...@go... To see the list archives or join the mailing list, visit: http://groups.google.com/group/iperf-dev |
From: Sarah L. <swl...@es...> - 2024-05-10 20:07:06
|
ESnet (Energy Sciences Network) is proud to announce the availability of iperf-3.17. This release includes several important bug fixes, as well as a correction for a possible side-channel timing vulnerability. To address this issue, a change has been made to the padding applied to encrypted strings. This change is not backwards compatible with older versions of iperf3 (before 3.17). To restore older (vulnerable) behavior for backwards compatibility, please use the --use-pkcs1-padding flag. Special thanks to Hubert Kario from RedHat for reporting this issue and providing feedback for the fix (CVE-2024-26306). This release also includes several other changes, including a new --json-stream option, and it no longer changes its current working directory in --daemon mode. It also includes bug fixes for UDP tests operating between two different endian hosts, and the --fq-rate parameter now works in reverse tests. Statistics reporting interval is now available in the --json start test object, and a negative time duration is now correctly reported as an error. The 3.17 release also includes additional support for Android, VxWorks, and now builds correctly on architectures without native support for 64-bit atomic types. iperf3 is a tool for measuring the maximum TCP, UDP, and SCTP throughput along a path, allowing for the tuning of various parameters and reporting measurements such as throughput, jitter, and datagram packet loss. It is fully supported on Linux, FreeBSD, and macOS. It may run on other platforms as well, although it has not received the same attention and testing. Note that iperf3 is not compatible with, and will not interoperate with, version 2 or earlier of iperf, although the two versions can co-exist on the same hosts and networks. The source code for iperf 3.17 is available at: https://downloads.es.net/pub/iperf/iperf-3.17.tar.gz <https://downloads.es.net/pub/iperf/iperf-3.15.tar.gz> SHA256 hash: 077ede831b11b733ecf8b273abd97f9630fd7448d3ec1eaa789f396d82c8c943 iperf3 is freely-redistributable under a 3-clause BSD license. More information can be found in the LICENSE file inside the source distribution. Additional documentation for iperf3 can be found at: https://software.es.net/iperf More information about iperf3 (including the issue tracker, source code repository access, and discussion forum) can be found on the iperf3 page on GitHub at: https://github.com/esnet/iperf User questions can go to the iperf users list (which is more-or-less shared between iperf2 and iperf3): ipe...@li... Mailing list information and archives can be found at: https://lists.sourceforge.net/lists/listinfo/iperf-users The mailing list for iperf3 development is: ipe...@go... To see the list archives or join the mailing list, visit: http://groups.google.com/group/iperf-dev |
From: Bob M. <bob...@br...> - 2024-04-11 02:00:43
|
Hi All, iperf version 2.2.0 has been officially released. https://sourceforge.net/projects/iperf2/ iperf -v iperf version 2.2.0 (10 April 2024) pthreads Bob -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. |
From: Tim C. <Tim...@ji...> - 2024-04-05 10:18:03
|
Hi, You’d likely ideally want some kind of harness to run iperf, and perhaps other tools, over time and squirrel the results to a database with a useful viewer and alerting system. What we use for this, in a very different scenario of measuring network characteristics between university networks, e.g., those participating in the CERN experiments, is perfSONAR. It’s an open source package that can measure throughput, loss, latency, and path over time, and has support to allow you to configure ‘meshes’ of tests between specific servers, controlled from a single central config file, with the mesh results viewable via Grafana (soon, in 5.1, we’re at 5.1 beta now). It’s not clear though that you could install such a tool in your environment, or add small form factor servers to run it, or be able to run such servers even as containers. So this answer may be quite unhelpful, apologies if so. It requires servers at each measurement point, rather than running tests over time from a single point. The loss/latency tests use OWAMP, running fairly continuously. You can also configure iperf2 or iperf3 tests to run periodically, by default every 6 hours for 30 seconds. See https://www.perfsonar.net/ if interested, and there’s a very helpful user list at https://lists.internet2.edu/sympa/info/perfsonar-user. Tim On 5 Apr 2024, at 05:30, Grahvendy, Patrick (Cobar - AU) <Pat...@me...> wrote: You don't often get email from pat...@me...<mailto:pat...@me...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Greetings Iperf folk I’m responsible for a remote control system for heavy earth moving equipment in an underground mining environment. The system consists of: 1. Windows PC on the surface as the main control unit 2. 4 remote control stations – 1 on the surface, 3 underground 3. Numerous access barrier boxes – controlling laser barrier safety systems 4. Numerous Wifi access points – to connect the loaders to the network 5. 4 underground earth moving front end loaders – equipped with Wifi machine clients Interconnections between all the fixed hardware consist of fibre optic lines to various network switches placed at different levels underground. From those network switches we use Cat6 ethernet cabling to the end devices. 1,2,3 and 5 above all contain a PLC unit which interfaces DC control signals to IP data. If connection is lost between any of these devices the system goes into an immediate fail safe and shuts the machine in operation down. The issue I’m having is lost packet data intermittently causing this shutdown condition. Running various continuous pings from the surface control PC to different IP address locations underground I can determine roughly where the unreliable connections are. Can Iperf be configured to run continuously, say over several hours, and provide more specific feedback on where the system is losing integrity? Any feedback or insight gratefully appreciated. Regards, Patrick Grahvendy AutoMine Specialist _______________________________________________ Iperf-users mailing list Ipe...@li...<mailto:Ipe...@li...> https://lists.sourceforge.net/lists/listinfo/iperf-users |
From: Grahvendy, P. (C. - AU) <Pat...@me...> - 2024-04-05 04:50:26
|
Greetings Iperf folk I'm responsible for a remote control system for heavy earth moving equipment in an underground mining environment. The system consists of: 1. Windows PC on the surface as the main control unit 2. 4 remote control stations - 1 on the surface, 3 underground 3. Numerous access barrier boxes - controlling laser barrier safety systems 4. Numerous Wifi access points - to connect the loaders to the network 5. 4 underground earth moving front end loaders - equipped with Wifi machine clients Interconnections between all the fixed hardware consist of fibre optic lines to various network switches placed at different levels underground. From those network switches we use Cat6 ethernet cabling to the end devices. 1,2,3 and 5 above all contain a PLC unit which interfaces DC control signals to IP data. If connection is lost between any of these devices the system goes into an immediate fail safe and shuts the machine in operation down. The issue I'm having is lost packet data intermittently causing this shutdown condition. Running various continuous pings from the surface control PC to different IP address locations underground I can determine roughly where the unreliable connections are. Can Iperf be configured to run continuously, say over several hours, and provide more specific feedback on where the system is losing integrity? Any feedback or insight gratefully appreciated. Regards, Patrick Grahvendy AutoMine Specialist |
From: Bob M. <bob...@br...> - 2024-03-25 23:56:23
|
Hi All, There is a subtle but important distinction between iperf 2's in progress stats. One is called InF for in-flight and computed by taking the stats from the stack. The second is called InP fo in-progress and taken by computing the queue depth per Little's Law. The latter is e2e. The following two runs illustrate the differences. First a run where there is a very large send side buffer and TCP_NOTSENT_LOWAT is not used. In this case the send side socket buffer should build up, which it does, and the e2e delay is seen per InP but not InF. That's because InF is from the stack's view of the network while InP is from the application view. Notice the InP is near the 100Mbytes socket buffer size while the InF is about 1.5Mbytes The second run sets TCP_NOTSENT_LOWAT and no the InF and InP are aligned at about 1.5Mbytes Run 1: No TCP_NOTSENT_LOWAT rjmcmahon@fedora:~/Code/inflight/iperf2-code$ iperf -c 192.168.1.35 --trip-times -e -i 1 --sync-transfer-id -w 50m --tcp-write-prefetch 0 ------------------------------------------------------------ Client connecting to 192.168.1.35, TCP port 5001 with pid 240696 (1/0 flows/load) Write buffer size: 131072 Byte TCP congestion control using cubic TOS set to 0x0 (dscp=0,ecn=0) (Nagle on) TCP window size: 95.4 MByte (WARNING: requested 47.7 MByte) ------------------------------------------------------------ [ 1] local 192.168.1.103%enp4s0 port 44754 connected with 192.168.1.35 port 5001 (trip-times) (sock=3) (icwnd/mss/irtt=14/1448/176) (ct=0.24 ms) on 2024-03-25 16:50:54.655 (PDT) [ ID] Interval Transfer Bandwidth Write/Err Rtry InF(pkts)/Cwnd/RTT(var) NetPwr [ 1] 0.00-1.00 sec 192 MBytes 1.61 Gbits/sec 1533/0 61 1538K(1088)/1555K/13234(110) us 15183 [ 1] 1.00-2.00 sec 96.4 MBytes 808 Mbits/sec 771/0 0 1667K(1179)/1674K/14273(81) us 7080 [ 1] 2.00-3.00 sec 128 MBytes 1.08 Gbits/sec 1026/0 0 1790K(1266)/1801K/15451(109) us 8704 [ 1] 3.00-4.00 sec 96.2 MBytes 807 Mbits/sec 770/0 0 1859K(1315)/1875K/16008(84) us 6305 [ 1] 4.00-5.00 sec 128 MBytes 1.08 Gbits/sec 1026/0 2 1340K(948)/1365K/11658(133) us 11535 [ 1] 5.00-6.00 sec 96.2 MBytes 807 Mbits/sec 770/0 0 1409K(997)/1448K/12301(98) us 8205 [ 1] 6.00-7.00 sec 128 MBytes 1.08 Gbits/sec 1026/0 0 1474K(1043)/1530K/13059(123) us 10298 [ 1] 7.00-8.00 sec 96.2 MBytes 807 Mbits/sec 770/0 0 1534K(1085)/1575K/13494(111) us 7479 [ 1] 8.00-9.00 sec 128 MBytes 1.08 Gbits/sec 1027/0 0 1602K(1133)/1614K/13807(132) us 9749 [ 1] 9.00-10.00 sec 96.2 MBytes 807 Mbits/sec 770/0 0 1593K(1127)/1636K/13980(130) us 7219 [ 1] 10.00-10.57 sec 128 KBytes 1.83 Mbits/sec 1/0 0 0K(0)/1665K/14358(111) us 15.90 [ 1] 0.00-10.57 sec 1.16 GBytes 941 Mbits/sec 9490/0 63 0K(0)/1665K/14358(111) us 8193 root@rpi5-35:~# iperf -s -i 1 -e ------------------------------------------------------------ Server listening on TCP port 5001 with pid 35250 Read buffer size: 128 KByte (Dist bin width=16.0 KByte) TCP congestion control default cubic TCP window size: 128 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.35%eth0 port 5001 connected with 192.168.1.103 port 44754 (trip-times) (sock=4) (peer 2.2.0-rc) (icwnd/mss/irtt=14/1448/182) on 2024-03-25 16:50:54.655 (PDT) [ ID] Interval Transfer Bandwidth Burst Latency avg/min/max/stdev (cnt/size) inP NetPwr Reads=Dist [ 1] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 451.474/1.878/839.327/236.465 ms (897/131093) 171 MByte 260 22019=21972:11:11:8:0:2:2:13 [ 1] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 709.032/560.182/839.576/80.886 ms (898/131052) 69.9 MByte 166 22841=22836:3:2:0:0:0:0:0 [ 1] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 690.533/559.994/839.511/79.692 ms (897/131201) 90.0 MByte 170 18997=18993:4:0:0:0:0:0:0 [ 1] 3.00-4.00 sec 112 MBytes 942 Mbits/sec 708.975/559.939/839.014/80.667 ms (898/131063) 69.8 MByte 166 19325=19325:0:0:0:0:0:0:0 [ 1] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 689.814/559.899/838.858/79.718 ms (898/131053) 90.0 MByte 171 19552=19552:0:0:0:0:0:0:0 [ 1] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 709.082/559.756/838.974/80.714 ms (898/131053) 69.8 MByte 166 19050=19030:4:0:0:1:0:1:14 [ 1] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 690.027/559.817/839.295/79.776 ms (898/131050) 90.0 MByte 171 19573=19570:2:1:0:0:0:0:0 [ 1] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 709.150/560.197/839.131/80.593 ms (898/131056) 69.8 MByte 166 20616=20608:4:3:1:0:0:0:0 [ 1] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 690.031/560.092/839.122/79.848 ms (898/131050) 90.0 MByte 171 18866=18864:2:0:0:0:0:0:0 [ 1] 9.00-10.00 sec 112 MBytes 942 Mbits/sec 709.217/560.065/838.999/80.484 ms (898/131056) 69.8 MByte 166 18885=18882:2:1:0:0:0:0:0 [ 1] 10.00-10.57 sec 64.0 MBytes 941 Mbits/sec 699.737/560.046/838.851/80.583 ms (512/131051) 69.8 MByte 168 210924=11199:1:0:0:0:0:0:0 [ 1] 0.00-10.57 sec 1.16 GBytes 941 Mbits/sec 677.050/1.878/839.576/128.445 ms (9490/131072) 75.7 MByte 174 210924=210831:33:18:9:1:2:3:27 Run 2: With TCP_NOTSENT_LOWAT rjmcmahon@fedora:~/Code/inflight/iperf2-code$ iperf -c 192.168.1.35 --trip-times -e -i 1 --sync-transfer-id -w 50m --tcp-write-prefetch 128K ------------------------------------------------------------ Client connecting to 192.168.1.35, TCP port 5001 with pid 240730 (1/0 flows/load) Write buffer size: 131072 Byte TCP congestion control using cubic TOS set to 0x0 (dscp=0,ecn=0) (Nagle on) TCP window size: 95.4 MByte (WARNING: requested 47.7 MByte) Event based writes (pending queue watermark at 131072 bytes) ------------------------------------------------------------ [ 1] local 192.168.1.103%enp4s0 port 53192 connected with 192.168.1.35 port 5001 (prefetch=131072) (trip-times) (sock=3) (icwnd/mss/irtt=14/1448/169) (ct=0.23 ms) on 2024-03-25 16:54:02.796 (PDT) [ ID] Interval Transfer Bandwidth Write/Err Rtry InF(pkts)/Cwnd/RTT(var) NetPwr [ 1] 0.00-1.00 sec 114 MBytes 955 Mbits/sec 911/0 72 1534K(1085)/1534K/13047(100) us 9152 [ 1] 1.00-2.00 sec 112 MBytes 942 Mbits/sec 898/0 0 1675K(1185)/1675K/14295(114) us 8234 [ 1] 2.00-3.00 sec 112 MBytes 943 Mbits/sec 899/0 0 1783K(1261)/1788K/15220(188) us 7742 [ 1] 3.00-4.00 sec 112 MBytes 943 Mbits/sec 899/0 0 1875K(1326)/1875K/16128(191) us 7306 [ 1] 4.00-5.00 sec 112 MBytes 937 Mbits/sec 894/0 1 1356K(959)/1356K/11166(273) us 10494 [ 1] 5.00-6.00 sec 112 MBytes 942 Mbits/sec 898/0 0 1450K(1026)/1450K/12334(159) us 9543 [ 1] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 898/0 0 1524K(1078)/1524K/12974(165) us 9072 [ 1] 7.00-8.00 sec 112 MBytes 943 Mbits/sec 899/0 0 1576K(1115)/1576K/13436(112) us 8770 [ 1] 8.00-9.00 sec 112 MBytes 942 Mbits/sec 898/0 0 1610K(1139)/1610K/13789(157) us 8536 [ 1] 9.00-10.00 sec 112 MBytes 942 Mbits/sec 898/0 0 1638K(1159)/1638K/14001(104) us 8407 [ 1] 0.00-10.03 sec 1.10 GBytes 940 Mbits/sec 8993/0 73 0K(0)/1638K/14017(120) us 8386 root@rpi5-35:~# iperf -s -i 1 -e ------------------------------------------------------------ Server listening on TCP port 5001 with pid 35260 Read buffer size: 128 KByte (Dist bin width=16.0 KByte) TCP congestion control default cubic TCP window size: 128 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.35%eth0 port 5001 connected with 192.168.1.103 port 53192 (trip-times) (sock=4) (peer 2.2.0-rc) (icwnd/mss/irtt=14/1448/171) on 2024-03-25 16:54:02.796 (PDT) [ ID] Interval Transfer Bandwidth Burst Latency avg/min/max/stdev (cnt/size) inP NetPwr Reads=Dist [ 1] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 13.100/1.372/34.740/4.362 ms (897/131165) 1.49 MByte 8981 18597=18552:13:5:6:1:3:5:12 [ 1] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 15.244/14.370/16.076/0.389 ms (898/131054) 1.71 MByte 7720 19588=19588:0:0:0:0:0:0:0 [ 1] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 16.325/15.569/17.066/0.318 ms (898/131061) 1.83 MByte 7209 19568=19568:0:0:0:0:0:0:0 [ 1] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 17.187/16.504/17.841/0.272 ms (898/131053) 1.93 MByte 6847 19317=19317:0:0:0:0:0:0:0 [ 1] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 17.979/14.707/34.753/1.359 ms (898/131050) 2.01 MByte 6546 19044=19022:3:3:1:0:0:0:15 [ 1] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 13.481/12.410/14.241/0.298 ms (898/131054) 1.51 MByte 8730 18915=18910:2:1:1:1:0:0:0 [ 1] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 14.220/13.581/14.831/0.245 ms (897/131199) 1.60 MByte 8276 19495=19491:2:2:0:0:0:0:0 [ 1] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 14.762/14.231/15.296/0.211 ms (898/131049) 1.66 MByte 7972 19164=19161:2:1:0:0:0:0:0 [ 1] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 15.144/14.693/15.589/0.180 ms (898/131052) 1.70 MByte 7771 19270=19267:2:0:1:0:0:0:0 [ 1] 9.00-10.00 sec 112 MBytes 942 Mbits/sec 15.398/15.012/15.817/0.172 ms (898/131055) 1.73 MByte 7643 18872=18866:5:0:1:0:0:0:0 [ 1] 0.00-10.02 sec 1.10 GBytes 941 Mbits/sec 15.285/1.372/34.753/2.068 ms (8993/131072) 1.68 MByte 7699 192149=192061:29:12:10:2:3:5:27 Bob -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. |
From: Bob M. <bob...@br...> - 2024-03-25 19:59:27
|
Hi All, iperf 2 has a release candidate ready for users to try. It's on sourceforge <https://sourceforge.net/projects/iperf2/> as iperf 2-2-0-rc. Please file tickets on sourceforge <https://sourceforge.net/p/iperf2/tickets/> as well. Release notes: 2.2.0 (as of March 14th, 2024 ------------------------------ o new ./configure --enable-summing-debug option to help with summing debug o select ahead of writes slow down UDP performance. support ./configure --disable-write-select o support fo -b 0 with UDP, unlimited load or no delay between writes o support for --sync-transfer-id so client and server will match the ids and give a remap message o support --dscp command line option o support for application level retries and minimum retry interval of the TCP connect() syscall via --connect-retry-time and --connect-retry-timer, repsectively o support for --ignore-shutdown so test will end on writes vs the BDP drain and TCP close/shutdown, recommended not to use this but in rare cases o support for --fq-rate-step and --fq-rate-step-interval o CCAs per --tcp-cca, --tcp-congestion, etc neeed to be case sensitive o support for both packets and bytes inflight taken from tcp_info struct amd pkt calc of (tcp_info_buf.tcpi_unacked - tcp_info_buf.tcpi_sacked - tcp_info_buf.tcpi_lost + tcp_info_buf.tcpi_retrans) o man page updates and -h to reflect new options, better descriptions o lots of work around summing with parallel threads, new implementation based on interval or slot counters, hopefully should work reliably o --bounceback tests are much more reliable and robust o Improve event handling around select timeouts, helps with larger -P values and summing o use the getsockopt IP_TOS for the displayed output, warn when set and get don't match o better tos byte output, include dscp and ecn fields individually o better tos setting code for both v6 and v4, so they behave the same around checks and warnings o much better NULL events to help with reporter processing even when traffic is not flowing o support for a new string report o python flows work around CDF based tests o rate limit fflush calls to a max of one every millisecond or 1000 per sec o remove superfulous fflush calls o reports when P = 1 and --sum-only need sum outputs o enable summing with --incr-dstip o add macro TIME_GET_NOW to set a struct timeval in a portable manner o code readability improvements with enums, bools, etc. o fix for TCP rate limited and -l less than min burst size o only use linux/tcp.h when absolutely needed, otherwise use netinet/tcp.h o print bounceback OWD tx/rx in interval reports o add flows Makefiles for tarball or make dist-all o support interval reports for bounceback histograms o support for TCP working loads and UDP primary flows, including UDP isochronous, per ticket 283 o fix working-load with isoch so working-load streams are capacity seeking o exit when CCA not supported or read of the current CCA doesn't match requested CCA o add more make check tests o add support for omit string (omit code not ready for this release) o pyflows qdisc settings and outputs o add first send pacing with --tx-starttime so listener threads udp_accept has time to perform udp_accept() between the client threads o adjust the sender time per the client delay and the client first write, i.e. subtract out this delay in the calculations o fixes for small packets and --tx-starttime o use more modern multicast socket options (now in src/iperf_multicast_api.c) o warn on bind port not sent with --incr-srcport o display fq-rate values in outputs when --fq-rate is used o add support for --test-exchange-timeout o fixes around wait_tick o add support for TCP_TX_DELAY via --tcp-tx-delay <val ms> option on both client and server o pass the CCA from client to server o support burst-size with different write sizes and don't require --burst-period o output traffic thread send scheduling error stats in final ouput o output clock unsync stats with --bounceback o add warn message on MSG_CTRUNC o UDP select fixes o enable TCP_NOTSENTLOWAT and set to a default small value with --tcp-write-times o default histogram max binning to 10 seconds o add a max timestamp to histogram outputs so user can find packets in pcaps or equivalent o autoconf change for struct ip_mreqn o print errno on writen fail -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. |
From: AdX <aa...@pr...> - 2023-12-05 09:10:56
|
Hi, I need help with filter output and save to file on linux. I've tried tons of combinations and none of them work. I need output in csv, filter lost_packets and save to file. I tried: `iperf -s -u -i 1 -y C | awk -F, '{print $11}' >> lost.txt` Output without redirection is good: `iperf -s -u -i 1 -y C | awk -F, '{print $11}' ` This command was the only that worked, but that wasn't quite it. File was not overwritten but appended: iperf -s -u -i 1 -y C | awk -F, '{print $11; fflush(); }' > lost.txt I know that iperf3, have --forceflush option, but iperf3 have json format output only. CSV is better for me. Thank you for help in advance. I tried other version of iperf too 2.0.19. Best regards, Adrian |
From: Bruce A. M. <bm...@es...> - 2023-12-01 19:46:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ESnet (Energy Sciences Network) is proud to announce the release of iperf-3.16. This version of iperf3 introduces a major change in the way that parallel tests (specified with the -P/--parallel flag) are handled. iperf3 now uses a separate thread (pthread) for each test stream. Generally multiple threads will use multiple CPU cores (if available), so this change will likely improve iperf3's ability to do higher-speed tests, particularly on 100+Gbps paths. This version has recorded transfers as high as 148Gbps in internal testing at ESnet over 200Gbps paths. This release also includes a few other minor changes for OpenSSL support. More information on those changes can be found in the iperf-3.16 release notes, which are contained in the RELNOTES.md file in the distribution. iperf-3.16 should be fully backward-compatible with prior iperf3 releases, that is, iperf-3.16 clients and servers should interoperate correctly with all 3.x clients and servers. The source code for iperf-3.16 is available at: https://downloads.es.net/pub/iperf/iperf-3.16.tar.gz SHA256 hash: cc740c6bbea104398cc3e466befc515a25896ec85e44a662d5f4a767b9cf713e iperf3 is freely-redistributable under a 3-clause BSD license. More information can be found in the LICENSE file inside the source distribution. Additional documentation: https://software.es.net/iperf Source code and issue tracker: https://github.com/esnet/iperf Discussion forums: https://github.com/esnet/iperf/discussions Reporting security issues: ip...@es... User questions can go to the iperf users list (which is more-or-less shared between iperf2 and iperf3): ipe...@li... Mailing list information and archives can be found at: https://lists.sourceforge.net/lists/listinfo/iperf-users The mailing list for iperf3 development is: ipe...@go... To see the list archives or join the mailing list, visit: http://groups.google.com/group/iperf-dev -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE+Fo4IENp9xo01E6DSYSRCoyq7ooFAmVqLzcACgkQSYSRCoyq 7opV4QgAwFT7Rpzyh8rUCyj1ZyslCmxr4kPtL56EcZne825ANIMxLmvVneqaESyz XLbLHR1VYAOUC+8r6ElHqGxdy6d07cIQ9wOrOKRVsqEPvSSbdxVZ6dgv/osIB07U U12zJYHCxIwW+5GPf4tRT9e3X6KT25TXvaLu7e7kgTz0zlwNlVAg5u+q4Yrb6IxW 2UjPU9wimrkMs2NrkkW+HhWyeaYtE0ahEs8+tJ+WaGIaLL7Iuio3v695PZad2P+P DSXeQYuPT9srjEd12j677kN7NDO4asd72Jei17JVRh/8E58UhHx/SbPxtt/idbut nsAqu7twYoTpPlhDKc8yQspfqESNPA== =UcX7 -----END PGP SIGNATURE----- |
From: Bruce A. M. <bm...@es...> - 2023-11-15 21:49:11
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ESnet (Energy Sciences Network) is proud to announce the first beta release of iperf-3.16. This version of software, to be released soon as iperf-3.16, uses a multi-threaded implementation that uses a separate thread (pthread) for each test stream. As the streams run more-or-less independently, this should remove some of the performance bottlenecks, and allow iperf3 to perform higher-speed tests, particularly on 100+Gbps paths. This version has recorded transfers as high as 148Gbps in internal testing at ESnet. This release also includes a few other minor changes for OpenSSL support. More information on those changes can be found in the iperf-3.16-beta1 release notes, which are contained in the RELNOTES.md file in the distribution. iperf 3.16-beta1 should be fully backward-compatible with prior iperf3 releases, that is, iperf 3.16-beta1 clients and servers should interoperate correctly with all 3.x clients and servers. The source code for iperf 3.16-beta1 is available at: https://downloads.es.net/pub/iperf/iperf-3.16-beta1.tar.gz SHA256 hash: 9d7bd5c031b4c3ca2eba4942ad57fe0ef46cb89520ea0756edfd42b842d567b6 iperf3 is freely-redistributable under a 3-clause BSD license. More information can be found in the LICENSE file inside the source distribution. Additional documentation: https://software.es.net/iperf Source code and issue tracker: https://github.com/esnet/iperf Discussion forums: https://github.com/esnet/iperf/discussions Reporting security issues: ip...@es... User questions can go to the iperf users list (which is more-or-less shared between iperf2 and iperf3): ipe...@li... Mailing list information and archives can be found at: https://lists.sourceforge.net/lists/listinfo/iperf-users The mailing list for iperf3 development is: ipe...@go... To see the list archives or join the mailing list, visit: http://groups.google.com/group/iperf-dev -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE+Fo4IENp9xo01E6DSYSRCoyq7ooFAmVVH5oACgkQSYSRCoyq 7op6Hgf/QX0TZRm7SPhIpGPEq9RJ2fYWsaWJEQ7Q2GN9MXkVJ95myDxvQNeUkMT7 Y1ND3L65coZsvuleORml661XoE8j9T7OiV7WeJnJcw4qUAggQ57ea6W/AgBqBqdR Yr5DcOhergftVUMIaPymmRx2Wr523Dy1rxFGWKjlbSxc8qOtO/AagM0+cJESp8rM O9DLU/7EVmAd0rQOeA+fIDhr8wXuYOG7F+HEAk4JiaaA04Y8+QLGnzhcuRGvbsuF zJkO4QbJRPEQG8e7y6mRVv7gVNgJqBdBvRHbVrFVEbK+t8f4UFh1DfWvcGj6/DeG bDoiDLMiawz84h4eeDwsncMWnRPaeQ== =vPCs -----END PGP SIGNATURE----- |
From: Bob M. <bob...@br...> - 2023-09-26 20:02:42
|
Hi Bruce, We do -c localhost testing to help isolate performance issues too. I think there are a few classes of bottlenecks that you and your team are aware of: - Core frequencies or cycle times, i.e. cpu limits - On chip accesses, including L1/L2 cache accesses - Pin i/o access, off chip but on board or CPU package, e.g. L3 cache and pcie bus memory - Network i/o accesses It seems a bit of an art to find what is driving performance. I tried to warn when network i/o is not driving a test's limits but not sure how good my mechanism is so I don't really promote it much. Bob On Tue, Sep 26, 2023 at 10:25 AM Bruce A. Mah <bm...@es...> wrote: > Hrm, no not doing zero-copy. > > We probably need to do some more testing to try to nail this stuff down a > bit. The latest results we've been seeing (not by me personally) are less > clear. I'll let the people who were actually doing this testing (or are > closer to it) chime in if and when they feel like it. > > Anyways, I was mostly wondering when I started this thread if there's > something obvious that we're missing. It doesn't sound like there is. > > I think running iperf2 or iperf3 from within numactl should be good for > giving the needed CPU pinning functionality...I think anyways. > > Thanks! > > Bruce. > > If memory serves me right, Bob McMahon wrote: > > Iperf2 doesn't support zero copy. Are your tests using that? Did you try > Iperf2 on your system? I can add an affinity option if you find it > helpful. > > Bob > > On Mon, Sep 25, 2023, 7:14 AM Bruce A. Mah <bm...@es...> wrote: > >> Thanks Bob! Yes the effects of CPU affinity were new to us before testing >> the multi-threading code. At least that's when I started noticing their >> effects (or rather, a couple colleagues pointed this out to me). This >> coincided with us getting results from some different test environments, so >> it might be that we're just running in some new regime and thus seeing >> effects that were hidden to us before. >> >> Bruce. >> >> If memory serves me right, Bob McMahon wrote: >> >> I should note that I mostly test on WiFi networks or 10G. There may be >> improvements on 100G+ with CPU affinity and I just haven't tried it. >> >> Bob >> >> On Fri, Sep 22, 2023, 10:52 AM Bob McMahon <bob...@br...> >> wrote: >> >>> Hi Bruce, >>> >>> Iperf 2 doesn't support CPU affinity. It lets the OS schedule threads on >>> cores. I tried to use CPU affinity a few years ago and I didn't notice any >>> performance impact. I was kinda of surprised by this. I have no idea why >>> there is different behavior between 2 & 3 per this. >>> >>> Bob >>> >>> On Fri, Sep 22, 2023 at 10:29 AM Bruce A. Mah <bm...@es...> wrote: >>> >>>> Hey Bob-- >>>> >>>> As we're doing some testing of the multi-threaded iperf3 in various >>>> environments, we've observed (not surprisingly) that CPU pinning of threads >>>> can have a significant impact on the throughput of tests. Generally we're >>>> running on some recent Ubuntu distribution of Linux. >>>> >>>> I'm trying to understand a report that iperf2 seems to automatically Do >>>> The Right Thing (tm) with respect to getting threads on the right CPU cores >>>> (particularly on multiple CPU package systems). But by contrast, good >>>> performance with iperf3 needs either the -A option for CPU affinity or >>>> running iperf3 within an invocation of numactl. I haven't yet had the >>>> opportunity to experiment with iperf2 much in this kind of environment. >>>> >>>> Is there some magic that iperf2 does to automatically figure out a good >>>> placement for the threads it spawns? I've looked through the source code >>>> (in particular compat/Thread.c) but I can't find anything applicable. I'd >>>> love to do something similar, if indeed this exists, in iperf3. >>>> >>>> Thanks! >>>> >>>> Bruce. >>>> >>> >> This electronic communication and the information and any files >> transmitted with it, or attached to it, are confidential and are intended >> solely for the use of the individual or entity to whom it is addressed and >> may contain information that is confidential, legally privileged, protected >> by privacy laws, or otherwise restricted from disclosure to anyone else. If >> you are not the intended recipient or the person responsible for delivering >> the e-mail to the intended recipient, you are hereby notified that any use, >> copying, distributing, dissemination, forwarding, printing, or copying of >> this e-mail is strictly prohibited. If you received this e-mail in error, >> please return the e-mail to the sender, delete it from your computer, and >> destroy any printed copy of it. >> >> > This electronic communication and the information and any files > transmitted with it, or attached to it, are confidential and are intended > solely for the use of the individual or entity to whom it is addressed and > may contain information that is confidential, legally privileged, protected > by privacy laws, or otherwise restricted from disclosure to anyone else. If > you are not the intended recipient or the person responsible for delivering > the e-mail to the intended recipient, you are hereby notified that any use, > copying, distributing, dissemination, forwarding, printing, or copying of > this e-mail is strictly prohibited. If you received this e-mail in error, > please return the e-mail to the sender, delete it from your computer, and > destroy any printed copy of it. > > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. |
From: Bruce A. M. <bm...@es...> - 2023-09-26 17:33:39
|
Hrm, no not doing zero-copy. We probably need to do some more testing to try to nail this stuff down a bit. The latest results we've been seeing (not by me personally) are less clear. I'll let the people who were actually doing this testing (or are closer to it) chime in if and when they feel like it. Anyways, I was mostly wondering when I started this thread if there's something obvious that we're missing. It doesn't sound like there is. I think running iperf2 or iperf3 from within numactl should be good for giving the needed CPU pinning functionality...I think anyways. Thanks! Bruce. If memory serves me right, Bob McMahon wrote: > Iperf2 doesn't support zero copy. Are your tests using that? Did you try > Iperf2 on your system? I can add an affinity option if you find it helpful. > > Bob > > On Mon, Sep 25, 2023, 7:14 AM Bruce A. Mah <bm...@es...> wrote: > >> Thanks Bob! Yes the effects of CPU affinity were new to us before testing >> the multi-threading code. At least that's when I started noticing their >> effects (or rather, a couple colleagues pointed this out to me). This >> coincided with us getting results from some different test environments, so >> it might be that we're just running in some new regime and thus seeing >> effects that were hidden to us before. >> >> Bruce. >> >> If memory serves me right, Bob McMahon wrote: >> >> I should note that I mostly test on WiFi networks or 10G. There may be >> improvements on 100G+ with CPU affinity and I just haven't tried it. >> >> Bob >> >> On Fri, Sep 22, 2023, 10:52 AM Bob McMahon <bob...@br...> >> wrote: >> >>> Hi Bruce, >>> >>> Iperf 2 doesn't support CPU affinity. It lets the OS schedule threads on >>> cores. I tried to use CPU affinity a few years ago and I didn't notice any >>> performance impact. I was kinda of surprised by this. I have no idea why >>> there is different behavior between 2 & 3 per this. >>> >>> Bob >>> >>> On Fri, Sep 22, 2023 at 10:29 AM Bruce A. Mah <bm...@es...> wrote: >>> >>>> Hey Bob-- >>>> >>>> As we're doing some testing of the multi-threaded iperf3 in various >>>> environments, we've observed (not surprisingly) that CPU pinning of threads >>>> can have a significant impact on the throughput of tests. Generally we're >>>> running on some recent Ubuntu distribution of Linux. >>>> >>>> I'm trying to understand a report that iperf2 seems to automatically Do >>>> The Right Thing (tm) with respect to getting threads on the right CPU cores >>>> (particularly on multiple CPU package systems). But by contrast, good >>>> performance with iperf3 needs either the -A option for CPU affinity or >>>> running iperf3 within an invocation of numactl. I haven't yet had the >>>> opportunity to experiment with iperf2 much in this kind of environment. >>>> >>>> Is there some magic that iperf2 does to automatically figure out a good >>>> placement for the threads it spawns? I've looked through the source code >>>> (in particular compat/Thread.c) but I can't find anything applicable. I'd >>>> love to do something similar, if indeed this exists, in iperf3. >>>> >>>> Thanks! >>>> >>>> Bruce. >>>> >>> >> This electronic communication and the information and any files >> transmitted with it, or attached to it, are confidential and are intended >> solely for the use of the individual or entity to whom it is addressed and >> may contain information that is confidential, legally privileged, protected >> by privacy laws, or otherwise restricted from disclosure to anyone else. If >> you are not the intended recipient or the person responsible for delivering >> the e-mail to the intended recipient, you are hereby notified that any use, >> copying, distributing, dissemination, forwarding, printing, or copying of >> this e-mail is strictly prohibited. If you received this e-mail in error, >> please return the e-mail to the sender, delete it from your computer, and >> destroy any printed copy of it. >> >> > > -- > This electronic communication and the information and any files transmitted > with it, or attached to it, are confidential and are intended solely for > the use of the individual or entity to whom it is addressed and may contain > information that is confidential, legally privileged, protected by privacy > laws, or otherwise restricted from disclosure to anyone else. If you are > not the intended recipient or the person responsible for delivering the > e-mail to the intended recipient, you are hereby notified that any use, > copying, distributing, dissemination, forwarding, printing, or copying of > this e-mail is strictly prohibited. If you received this e-mail in error, > please return the e-mail to the sender, delete it from your computer, and > destroy any printed copy of it. |
From: Bruce A. M. <bm...@es...> - 2023-09-25 19:18:35
|
Thanks Bob! Yes the effects of CPU affinity were new to us before testing the multi-threading code. At least that's when I started noticing their effects (or rather, a couple colleagues pointed this out to me). This coincided with us getting results from some different test environments, so it might be that we're just running in some new regime and thus seeing effects that were hidden to us before. Bruce. If memory serves me right, Bob McMahon wrote: > I should note that I mostly test on WiFi networks or 10G. There may be > improvements on 100G+ with CPU affinity and I just haven't tried it. > > Bob > > On Fri, Sep 22, 2023, 10:52 AM Bob McMahon <bob...@br...> wrote: > >> Hi Bruce, >> >> Iperf 2 doesn't support CPU affinity. It lets the OS schedule threads on >> cores. I tried to use CPU affinity a few years ago and I didn't notice any >> performance impact. I was kinda of surprised by this. I have no idea why >> there is different behavior between 2 & 3 per this. >> >> Bob >> >> On Fri, Sep 22, 2023 at 10:29 AM Bruce A. Mah <bm...@es...> wrote: >> >>> Hey Bob-- >>> >>> As we're doing some testing of the multi-threaded iperf3 in various >>> environments, we've observed (not surprisingly) that CPU pinning of threads >>> can have a significant impact on the throughput of tests. Generally we're >>> running on some recent Ubuntu distribution of Linux. >>> >>> I'm trying to understand a report that iperf2 seems to automatically Do >>> The Right Thing (tm) with respect to getting threads on the right CPU cores >>> (particularly on multiple CPU package systems). But by contrast, good >>> performance with iperf3 needs either the -A option for CPU affinity or >>> running iperf3 within an invocation of numactl. I haven't yet had the >>> opportunity to experiment with iperf2 much in this kind of environment. >>> >>> Is there some magic that iperf2 does to automatically figure out a good >>> placement for the threads it spawns? I've looked through the source code >>> (in particular compat/Thread.c) but I can't find anything applicable. I'd >>> love to do something similar, if indeed this exists, in iperf3. >>> >>> Thanks! >>> >>> Bruce. >>> >> > > -- > This electronic communication and the information and any files transmitted > with it, or attached to it, are confidential and are intended solely for > the use of the individual or entity to whom it is addressed and may contain > information that is confidential, legally privileged, protected by privacy > laws, or otherwise restricted from disclosure to anyone else. If you are > not the intended recipient or the person responsible for delivering the > e-mail to the intended recipient, you are hereby notified that any use, > copying, distributing, dissemination, forwarding, printing, or copying of > this e-mail is strictly prohibited. If you received this e-mail in error, > please return the e-mail to the sender, delete it from your computer, and > destroy any printed copy of it. |
From: Bob M. <bob...@br...> - 2023-09-25 16:21:40
|
Iperf2 doesn't support zero copy. Are your tests using that? Did you try Iperf2 on your system? I can add an affinity option if you find it helpful. Bob On Mon, Sep 25, 2023, 7:14 AM Bruce A. Mah <bm...@es...> wrote: > Thanks Bob! Yes the effects of CPU affinity were new to us before testing > the multi-threading code. At least that's when I started noticing their > effects (or rather, a couple colleagues pointed this out to me). This > coincided with us getting results from some different test environments, so > it might be that we're just running in some new regime and thus seeing > effects that were hidden to us before. > > Bruce. > > If memory serves me right, Bob McMahon wrote: > > I should note that I mostly test on WiFi networks or 10G. There may be > improvements on 100G+ with CPU affinity and I just haven't tried it. > > Bob > > On Fri, Sep 22, 2023, 10:52 AM Bob McMahon <bob...@br...> > wrote: > >> Hi Bruce, >> >> Iperf 2 doesn't support CPU affinity. It lets the OS schedule threads on >> cores. I tried to use CPU affinity a few years ago and I didn't notice any >> performance impact. I was kinda of surprised by this. I have no idea why >> there is different behavior between 2 & 3 per this. >> >> Bob >> >> On Fri, Sep 22, 2023 at 10:29 AM Bruce A. Mah <bm...@es...> wrote: >> >>> Hey Bob-- >>> >>> As we're doing some testing of the multi-threaded iperf3 in various >>> environments, we've observed (not surprisingly) that CPU pinning of threads >>> can have a significant impact on the throughput of tests. Generally we're >>> running on some recent Ubuntu distribution of Linux. >>> >>> I'm trying to understand a report that iperf2 seems to automatically Do >>> The Right Thing (tm) with respect to getting threads on the right CPU cores >>> (particularly on multiple CPU package systems). But by contrast, good >>> performance with iperf3 needs either the -A option for CPU affinity or >>> running iperf3 within an invocation of numactl. I haven't yet had the >>> opportunity to experiment with iperf2 much in this kind of environment. >>> >>> Is there some magic that iperf2 does to automatically figure out a good >>> placement for the threads it spawns? I've looked through the source code >>> (in particular compat/Thread.c) but I can't find anything applicable. I'd >>> love to do something similar, if indeed this exists, in iperf3. >>> >>> Thanks! >>> >>> Bruce. >>> >> > This electronic communication and the information and any files > transmitted with it, or attached to it, are confidential and are intended > solely for the use of the individual or entity to whom it is addressed and > may contain information that is confidential, legally privileged, protected > by privacy laws, or otherwise restricted from disclosure to anyone else. If > you are not the intended recipient or the person responsible for delivering > the e-mail to the intended recipient, you are hereby notified that any use, > copying, distributing, dissemination, forwarding, printing, or copying of > this e-mail is strictly prohibited. If you received this e-mail in error, > please return the e-mail to the sender, delete it from your computer, and > destroy any printed copy of it. > > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. |
From: Bob M. <bob...@br...> - 2023-09-22 19:07:51
|
I should note that I mostly test on WiFi networks or 10G. There may be improvements on 100G+ with CPU affinity and I just haven't tried it. Bob On Fri, Sep 22, 2023, 10:52 AM Bob McMahon <bob...@br...> wrote: > Hi Bruce, > > Iperf 2 doesn't support CPU affinity. It lets the OS schedule threads on > cores. I tried to use CPU affinity a few years ago and I didn't notice any > performance impact. I was kinda of surprised by this. I have no idea why > there is different behavior between 2 & 3 per this. > > Bob > > On Fri, Sep 22, 2023 at 10:29 AM Bruce A. Mah <bm...@es...> wrote: > >> Hey Bob-- >> >> As we're doing some testing of the multi-threaded iperf3 in various >> environments, we've observed (not surprisingly) that CPU pinning of threads >> can have a significant impact on the throughput of tests. Generally we're >> running on some recent Ubuntu distribution of Linux. >> >> I'm trying to understand a report that iperf2 seems to automatically Do >> The Right Thing (tm) with respect to getting threads on the right CPU cores >> (particularly on multiple CPU package systems). But by contrast, good >> performance with iperf3 needs either the -A option for CPU affinity or >> running iperf3 within an invocation of numactl. I haven't yet had the >> opportunity to experiment with iperf2 much in this kind of environment. >> >> Is there some magic that iperf2 does to automatically figure out a good >> placement for the threads it spawns? I've looked through the source code >> (in particular compat/Thread.c) but I can't find anything applicable. I'd >> love to do something similar, if indeed this exists, in iperf3. >> >> Thanks! >> >> Bruce. >> > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. |
From: Bob M. <bob...@br...> - 2023-09-22 17:59:11
|
Hi Bruce, Iperf 2 doesn't support CPU affinity. It lets the OS schedule threads on cores. I tried to use CPU affinity a few years ago and I didn't notice any performance impact. I was kinda of surprised by this. I have no idea why there is different behavior between 2 & 3 per this. Bob On Fri, Sep 22, 2023 at 10:29 AM Bruce A. Mah <bm...@es...> wrote: > Hey Bob-- > > As we're doing some testing of the multi-threaded iperf3 in various > environments, we've observed (not surprisingly) that CPU pinning of threads > can have a significant impact on the throughput of tests. Generally we're > running on some recent Ubuntu distribution of Linux. > > I'm trying to understand a report that iperf2 seems to automatically Do > The Right Thing (tm) with respect to getting threads on the right CPU cores > (particularly on multiple CPU package systems). But by contrast, good > performance with iperf3 needs either the -A option for CPU affinity or > running iperf3 within an invocation of numactl. I haven't yet had the > opportunity to experiment with iperf2 much in this kind of environment. > > Is there some magic that iperf2 does to automatically figure out a good > placement for the threads it spawns? I've looked through the source code > (in particular compat/Thread.c) but I can't find anything applicable. I'd > love to do something similar, if indeed this exists, in iperf3. > > Thanks! > > Bruce. > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. |
From: Bruce A. M. <bm...@es...> - 2023-09-22 17:29:34
|
Hey Bob-- As we're doing some testing of the multi-threaded iperf3 in various environments, we've observed (not surprisingly) that CPU pinning of threads can have a significant impact on the throughput of tests. Generally we're running on some recent Ubuntu distribution of Linux. I'm trying to understand a report that iperf2 seems to automatically Do The Right Thing (tm) with respect to getting threads on the right CPU cores (particularly on multiple CPU package systems). But by contrast, good performance with iperf3 needs either the -A option for CPU affinity or running iperf3 within an invocation of numactl. I haven't yet had the opportunity to experiment with iperf2 much in this kind of environment. Is there some magic that iperf2 does to automatically figure out a good placement for the threads it spawns? I've looked through the source code (in particular compat/Thread.c) but I can't find anything applicable. I'd love to do something similar, if indeed this exists, in iperf3. Thanks! Bruce. |
From: Peter S. <pet...@gm...> - 2023-09-16 04:47:47
|
Thanks a lot, Bruce. On Fri, Sep 15, 2023 at 10:32 PM Bruce A. Mah <bm...@es...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ESnet Software Security Advisory > ESNET-SECADV-2023-0002 > > Topic: iperf3 Server Denial of Service > Issued: 13 September 2023 > Revised: 15 September 2023 > Credits: Jorge Sancho Larraz (Canonical) > Affects: iperf-3.14 and earlier > Corrected: iperf-3.15 > > I. Background > > iperf3 is a utility for testing network performance using TCP, UDP, > and SCTP, running over IPv4 and IPv6. It uses a client/server model, > where a client and server communicate the parameters of a test, > coordinate the start and end of the test, and exchange results. This > message exchange takes place over a TCP "control connection". > > II. Problem Description > > The iperf3 server and client will, at various times, send data over > the control connection that control the parameters, start and stop of > a test, and result exchange. Many of these data have some expected > length to them (whether fixed or variable). > > It is possible for a malicious or malfunctioning client to send less > than the expected amount of data to the server. If this happens, the > server will hang indefinitely waiting for the remainder (or until the > connection gets closed). Because iperf3 is deliberately designed to > service only one client connection at a time, this will prevent other > connections to the iperf3 server. > > III. Impact > > A malicious or misbehaving process can connect to an iperf3 server and > prevent other connections to the server indefinitely. This issue > mainly applies to an iperf3 server that is reachable from some > untrusted host or network, such as the public Internet. It might be > possible for a malicious iperf3 server to mount a similar attack on an > iperf3 client. > > iperf2 uses a different model of interaction between client and > server, and is not affected by this issue. > > IV. Workaround > > There is no workaround for this issue, however as best practice > dictates, iperf3 should not be run with root privileges, to minimize > possible impact. Note that iperf3 was not designed to be a > long-running server on the public Internet. > > V. Solution > > Update iperf3 to a version containing the fix (i.e. iperf-3.15 or > later). > > VI. Correction details > > The bug causing this vulnerability has been fixed by the following > commit in the esnet/iperf Github repository: > > master 5e3704dd850a5df2fb2b3eafd117963d017d07b4 > > All released versions of iperf3 issued on or after the date of this > advisory incorporate the fix. > > ESnet would like to thank Jorge Sancho Larraz (Canonical) for bringing > this issue to our attention. > > Security concerns with iperf3 can be submitted privately by sending an > email to the developers at <ip...@es...>. > > V. Revision history > > 13 September 2023: Original version of security advisory. > > 15 September 2023: Corrected inaccurate information about iperf2. > > -----BEGIN PGP SIGNATURE----- > > iQEzBAEBCgAdFiEE+Fo4IENp9xo01E6DSYSRCoyq7ooFAmUEvc8ACgkQSYSRCoyq > 7oqu+Qf+MgZTo47gNDW98/1dWYMLBhAA9ptVh6BLknpxJ/S2HdeWKQNH68cSLG3b > VM7DkZSyCCmad77ySbr3w7/UoFbD1YJetDSdh3J73vdSQNClCUPG9ddSt45QuWsK > kvURAUWHA4lcR/ZsJruWTa9YNYV2qECVJd9zHmUJ9/o01IAoP5sfEQgJJaPX7JWZ > RyCu9rJVBq5yGlLL86338HIoMmNnD212CkDnpoIcEpdocwJ7dkCIZoOPh/KjYoWQ > tLGEgscW3JT9L1zwAjZuHy8vi+wNyXUr8/vLcns4K3FabYFzrKSq5ODs0qgNmpfS > PHOf94N6Qk97M1BA0A8qV9HLF2yS+w== > =FrPM > -----END PGP SIGNATURE----- > > > _______________________________________________ > Iperf-users mailing list > Ipe...@li... > https://lists.sourceforge.net/lists/listinfo/iperf-users > |
From: Bob M. <bob...@br...> - 2023-09-15 21:53:42
|
No worries Bruce. Thanks for the correction. I'm older too so maybe being called older isn't really a bad thing ;) I do think many users will learn each tool's feature set based upon their needs. Having two similar open source tools with some overlapping capabilities, e.g. to measure throughput or capacity, is a good thing for all. If one suspects the tool they can try the other one. I do think some core properties which both tools support are: - capacity measurements with CWND & RTT sampling (iperf2 requires -e) - --fq-rate based source pacing - support for threads Note: There may be a move towards TCP CCAs that support source pacing, as network hosts evolve from as fast as possible (AFAP) towards congestion mitigation, to help eliminate standing queues or bufferbloat. I've added some --fq-rate options that might be applicable to the iperf 3 user base - not sure. The iperf 2 pacing options include the below as well as supporting the CCA per client side only setting of --tcp-cca which get passed to the server (CCA's like prague need it set on both ends for the L4S ECN support.) *--tcp-cca*Set the congestion control algorithm to be used for TCP connections. (same as --tcp-congestion) *--fq-rate **n*[kmgKMG]Set a rate to be used with fair-queuing based socket-level pacing, in bytes or bits per second. Only available on platforms supporting the SO_MAX_PACING_RATE socket option. (Note: Here the suffixes indicate bytes/sec or bits/sec per use of uppercase or lowercase, respectively)*--fq-rate-step **n*[kmgKMG]Set a step of rate to be used with fair-queuing based socket-level pacing, in bytes or bits per second. Step occurs every fq-rate-step-interval (defaults to one second) *--fq-rate-step-interval **n*Time in seconds before stepping the fq-rate On Fri, Sep 15, 2023 at 1:35 PM Bruce A. Mah <bm...@es...> wrote: > I've corrected our advisory and sent out a new version. > > Once again, sorry for giving the wrong impression. I believe this comes > from a copy-and-paste of some much earlier text that was written before you > started actively maintaining iperf2 (that does not excuse the error, but > that's probably why it happened). > > Bruce. > > I wrote: > > > Hi Bob-- > > > > Apologies! The text "older version" wasn't right and didn't even > contribute any value in the context where it was used. I'm not sure how > that phrase got included, but that mistake is definitely mine. > > > > Thanks for the update on iperf2 activities. We've been working on adding > multi-threading capabilities to iperf3, so that it can use multiple CPU > cores for higher throughput testing. (Of course, iperf2 has had this > ability for quite awhile.) We've done a few public betas over the summer, > with generally useful and favorable results. The plan is to bring this into > a mainline release "soon". > > > > Bruce. > > > > If memory serves me right, Bob McMahon wrote: > > > >> Thanks for this Bruce & to the iperf 3 team. > >> > >> A small correction - not sure I'd say iperf2 is an older version but > rather > >> another version based from the original iperf code (using those design > >> patterns.) The latest version for iperf 2 is version 2.1.9 released on > >> March 14, 2023. One can always compile the bleeding edge from source per > >> the master branch. Those commits come in spurts but can be daily. Some > new > >> multicast code was committed yesterday as an example. > > [snip] > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. |