From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.rno.apple.com [17.179.253.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 19DAD3B2A4 for ; Tue, 1 Nov 2022 17:52:34 -0400 (EDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 2A1LbFcg022600; Tue, 1 Nov 2022 14:52:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=0mjiTWa/7JE4P4SKSUnaupeCZ/vpdRYCH75z5D0PK0g=; b=pgj//WlfuSPKLooVK3eEIkD2xraN4bUZZw0rlaoT+PYQ8zKBb20VRitmgyJldwBkZiFj P2yGtUOnaNP7idxFSbbSH+Bi3bUUwcPAKc6dcSVz6M3kq295THZTrwhmrnjKO8oYeQFr MxvFzHNic2gutWb8U1oBu+/FfQ11tUnzQvGWezlAh4of2sBDHojqQY6rMLbc+aZRRgrq iPG2pFC6lLzBwGOsaQ+2ooTOEQkn5Y56z5ytLlozdApX1E6rICSNPuhtSjCK17E76qIS 36ZaJpYeEu+xqmLKsTrV3kTCnkG0S61u8k6aZmOuoe0WfYjw+tu4zbR8OB8af/f5xLR5 jg== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 3kgyq6xkhd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 01 Nov 2022 14:52:32 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) with ESMTPS id <0RKO00SXXVFKFF10@rn-mailsvcp-mta-lapp02.rno.apple.com>; Tue, 01 Nov 2022 14:52:32 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) id <0RKO00I00VE12100@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Tue, 01 Nov 2022 14:52:32 -0700 (PDT) X-Va-A: X-Va-T-CD: 87fb32bc225d5809fa663d8e3ce5e235 X-Va-E-CD: e6522529a1c3a53151bafdb6b02f4ea2 X-Va-R-CD: c39ddcbb2776b6dc4205ccce0a2c0401 X-Va-CD: 0 X-Va-ID: 395ed186-5679-46c0-b86b-043343092e83 X-V-A: X-V-T-CD: 87fb32bc225d5809fa663d8e3ce5e235 X-V-E-CD: e6522529a1c3a53151bafdb6b02f4ea2 X-V-R-CD: c39ddcbb2776b6dc4205ccce0a2c0401 X-V-CD: 0 X-V-ID: ed1bff4d-117c-43cd-bf97-ea62700bf7bc X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.545, 18.0.895 definitions=2022-11-01_10:2022-11-01, 2022-11-01 signatures=0 Received: from smtpclient.apple (unknown [17.149.224.67]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) with ESMTPSA id <0RKO0019NVFKAM00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Tue, 01 Nov 2022 14:52:32 -0700 (PDT) From: Christoph Paasch Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_744A3EBB-83FC-404F-AEEC-D1CC0D6F1620" MIME-version: 1.0 (Mac OS X Mail 16.0 \(3731.200.92\)) Date: Tue, 01 Nov 2022 14:52:21 -0700 In-reply-to: Cc: Rpm To: "jf@jonathanfoulkes.com" References: X-Mailer: Apple Mail (2.3731.200.92) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.545, 18.0.895 definitions=2022-11-01_10:2022-11-01, 2022-11-01 signatures=0 Subject: Re: [Rpm] Changes to RPM calculation for MacOS Ventura? X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2022 21:52:34 -0000 --Apple-Mail=_744A3EBB-83FC-404F-AEEC-D1CC0D6F1620 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Jonathan, > On Oct 28, 2022, at 2:45 PM, jf--- via Rpm = wrote: >=20 > Hopefully, Christoph can provide some details on the changes from the = prior networkQuality test, as we=E2=80=99re seeing some pretty large = changes in results for the latest RPM tests. >=20 > Where before we=E2=80=99d see results in the >1,500 RPM (and multiple = >2,000 RPM results) for a DOCSIS 3.1 line with QoS enabled (180 down/35 = up), it now returns peak download RPM of ~600 and ~800 for upload. >=20 > latest results: >=20 > =3D=3D=3D=3D SUMMARY =3D=3D=3D=3D > Uplink capacity: 25.480 Mbps (Accuracy: High) > Downlink capacity: 137.768 Mbps (Accuracy: High) > Uplink Responsiveness: Medium (385 RPM) (Accuracy: High) > Downlink Responsiveness: Medium (376 RPM) (Accuracy: High) > Idle Latency: 43.875 milli-seconds (Accuracy: High) > Interface: en8 > Uplink bytes transferred: 35.015 MB > Downlink bytes transferred: 154.649 MB > Uplink Flow count: 16 > Downlink Flow count: 12 > Start: 10/28/22, 5:12:30 PM > End: 10/28/22, 5:12:54 PM > OS Version: Version 13.0 (Build 22A380) >=20 > Latencies (as monitored via PingPlotter) stay absolutely steady during = these tests, >=20 > So unless my ISP coincidentally started having major service issues, = I=E2=80=99m scratching my head as to why. >=20 > For contrast, the Ookla result is as follows: = https://www.speedtest.net/result/13865976456 with 15ms down, 18ms up = loaded latencies. In Ventura, we started adding the latency on the load-generating = connections to the final RPM-calulcation as well. The formula being used = is now exactly what is in the v01 IETF draft. Very likely the bottleneck in your network does FQ, and so latency on = separate connections is very low, while your load-generating connections = are still bufferbloated. Ookla measures latency only on separate connections, thus will also be = heavily impacted by FQ. Does that clarify it? Cheers, Christoph=20 >=20 > Further machine details: MacBook Pro 16=E2=80=9D (2019) using a USB-C = to Ethernet adapter. > I run with full ECN enabled: > sudo sysctl -w net.inet.tcp.disable_tcp_heuristics=3D1=20 >=20 > sudo sysctl -w net.inet.tcp.ecn_initiate_out=3D1 >=20 > sudo sysctl -w net.inet.tcp.ecn_negotiate_in=3D1 >=20 > and also with instant ack replies: >=20 > sysctl net.inet.tcp.delayed_ack > net.inet.tcp.delayed_ack: 0 >=20 > I did try with delayed_ack=3D1, and the results were about the same. >=20 > Thanks in advance, >=20 > Jonathan Foulkes >=20 > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm --Apple-Mail=_744A3EBB-83FC-404F-AEEC-D1CC0D6F1620 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello = Jonathan,

On Oct 28, 2022, at = 2:45 PM, jf--- via Rpm <rpm@lists.bufferbloat.net> wrote:

Hopefully, Christoph can provide some details on the = changes from the prior networkQuality test, as we=E2=80=99re seeing some = pretty large changes in results for the latest RPM = tests.

Where before we=E2=80=99d see results in the = >1,500 RPM (and multiple >2,000 RPM results) for a DOCSIS 3.1 line = with QoS enabled (180 down/35 up), it now returns peak download RPM of = ~600 and ~800 for upload.

latest = results:

=3D=3D=3D=3D SUMMARY = =3D=3D=3D=3D
Uplink capacity: 25.480 Mbps (Accuracy: = High)
Downlink capacity: 137.768 Mbps (Accuracy: = High)
Uplink Responsiveness: Medium (385 RPM) (Accuracy: = High)
Downlink Responsiveness: Medium (376 RPM) (Accuracy: = High)
Idle Latency: 43.875 milli-seconds (Accuracy: = High)
Interface: en8
Uplink bytes transferred: = 35.015 MB
Downlink bytes transferred: 154.649 = MB
Uplink Flow count: 16
Downlink Flow count: = 12
Start: 10/28/22, 5:12:30 PM
End: 10/28/22, = 5:12:54 PM
OS Version: Version 13.0 (Build = 22A380)

Latencies (as monitored via = PingPlotter) stay absolutely steady during these = tests,

So unless my ISP coincidentally started = having major service issues, I=E2=80=99m scratching my head as to = why.

For contrast, the Ookla result is as = follows: https://www.speedtes= t.net/result/13865976456  with 15ms down, 18ms up loaded = latencies.

In Ventura, = we started adding the latency on the load-generating connections to the = final RPM-calulcation as well. The formula being used is now exactly = what is in the v01 IETF draft.

Very likely the = bottleneck in your network does FQ, and so latency on separate = connections is very low, while your load-generating connections are = still bufferbloated.


Ookla = measures latency only on separate connections, thus will also be heavily = impacted by FQ.


Does that = clarify = it?


Cheers,
Christoph&nb= sp;



Further machine = details: MacBook Pro 16=E2=80=9D (2019) using a USB-C to Ethernet = adapter.
I run with full ECN enabled:

sudo sysctl -w = net.inet.tcp.disable_tcp_heuristics=3D1 

sudo sysctl -w net.inet.tcp.ecn_initiate_out=3D1

sudo sysctl -w = net.inet.tcp.ecn_negotiate_in=3D1

a= nd also with instant ack replies:

sysctl = net.inet.tcp.delayed_ack
net.inet.tcp.delayed_ack: = 0

I did try with delayed_ack=3D1, and the = results were about the same.

Thanks in = advance,

Jonathan = Foulkes

________________________________________= _______
Rpm mailing = list
Rpm@lists.bufferbloat.net
https://lists.bufferbloat.net/listinf= o/rpm

= --Apple-Mail=_744A3EBB-83FC-404F-AEEC-D1CC0D6F1620--