From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 249ED3B29E for ; Thu, 10 Nov 2022 14:53:05 -0500 (EST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 2AAJlCNF031675; Thu, 10 Nov 2022 11:53:01 -0800 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=SING2pIIhfY0z6UopHTDbWDg4iz4MBPhNVR+3rfkiyA=; b=NmnBzMNNNie65b99xmoL2jSnhMC6SC3tqhzDOxRlg6bSWsB6HNGD/wl6KKNbrAG5DfLE P7oM8Bb16V955at2re3aupdIC4NrvKJHh6nM8Oy5LTy8pwpQR/QxEkYd9dfEFjx3kvax TgCL+qTzwNsG0BSNvZZeLVkg7+BcdCC9HYbcPvp+fKPyfj9lueWvCKlui/A84QRKV9dL refRqcAdCQE2Vn1XLPfjJPdR/g/Rc1oEgRP7/fl6p802oHwOZQxyuNlMkVzfBZRCmRVj 9lXtHPlTbZ9DQ/nhKIitYBOQPnk7JAtUEAAXFxMAWzZFgYkq6vyRGLHn/oX6yjk9LtSS BA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3knptusk9c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Nov 2022 11:53:01 -0800 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) with ESMTPS id <0RL500I73DWCX7C0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Thu, 10 Nov 2022 11:53:00 -0800 (PST) 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.20.20220923 64bit (built Sep 23 2022)) id <0RL500F00DQM1Z00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 10 Nov 2022 11:53:00 -0800 (PST) X-Va-A: X-Va-T-CD: 0af778c0afa90afa8c4c05937d25c782 X-Va-E-CD: e6522529a1c3a53151bafdb6b02f4ea2 X-Va-R-CD: c39ddcbb2776b6dc4205ccce0a2c0401 X-Va-CD: 0 X-Va-ID: bc104cad-7afd-469e-b16e-2bedb7fbfa94 X-V-A: X-V-T-CD: 0af778c0afa90afa8c4c05937d25c782 X-V-E-CD: e6522529a1c3a53151bafdb6b02f4ea2 X-V-R-CD: c39ddcbb2776b6dc4205ccce0a2c0401 X-V-CD: 0 X-V-ID: f7daaa6a-b1f9-48a2-aba8-962081edd0a7 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.545, 18.0.895 definitions=2022-11-10_12:2022-11-09, 2022-11-10 signatures=0 Received: from smtpclient.apple ([17.11.121.197]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) with ESMTPSA id <0RL500L28DWC2H10@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 10 Nov 2022 11:53:00 -0800 (PST) From: Christoph Paasch Message-id: <66ECC547-D13A-4820-B897-21DC409BFB28@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_65373597-8CC4-4F6F-99D5-6CBACC2DD371" MIME-version: 1.0 (Mac OS X Mail 16.0 \(3731.200.92\)) Date: Thu, 10 Nov 2022 11:52:53 -0800 In-reply-to: Cc: Christoph Paasch via Rpm , "jf@jonathanfoulkes.com" To: Sebastian Moeller 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-10_12:2022-11-09, 2022-11-10 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: Thu, 10 Nov 2022 19:53:05 -0000 --Apple-Mail=_65373597-8CC4-4F6F-99D5-6CBACC2DD371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, > On Nov 1, 2022, at 3:09 PM, Sebastian Moeller wrote: >=20 > Hi Christoph, >=20 > On 1 November 2022 22:52:21 CET, Christoph Paasch via Rpm = > wrote: >> Hello Jonathan, >>=20 >>> 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. >>=20 >> 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. >=20 > [SM] I have been wondering quietly before whether reporting both = inter- and intra-load-bearing flow responsiveness would not be a cool = option for verbose mode? Both IMHO are giving relevant information about = a link's usability under working conditions. Yes, that=E2=80=99s a good suggestion! We could expose this in the = verbose mode. Christoph >=20 > Regards > Sebastian >=20 >=20 >>=20 >> 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. >>=20 >>=20 >> Ookla measures latency only on separate connections, thus will also = be heavily impacted by FQ. >>=20 >>=20 >> Does that clarify it? >>=20 >>=20 >> Cheers, >> Christoph=20 >>=20 >>=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 >>=20 >=20 > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. --Apple-Mail=_65373597-8CC4-4F6F-99D5-6CBACC2DD371 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

On = Nov 1, 2022, at 3:09 PM, Sebastian Moeller <moeller0@gmx.de> = wrote:

Hi Christoph,

On 1 November 2022 22:52:21 CET, Christoph = Paasch via Rpm <rpm@lists.bufferbloat.net> = wrote:
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.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.

[SM] I = have been wondering quietly before whether reporting both inter- and = intra-load-bearing flow responsiveness would not be a cool option for = verbose mode? Both IMHO are giving relevant information about a link's = usability under working conditions.

Yes, = that=E2=80=99s a good suggestion! We could expose this in the verbose = mode.


Christoph


Regards
       Sebastian


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 



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

and 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


-- 
Sent from my Android device with K-9 Mail. = Please excuse my = brevity.

= --Apple-Mail=_65373597-8CC4-4F6F-99D5-6CBACC2DD371--