From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2CA103CB37 for ; Sun, 19 Nov 2023 19:35:12 -0500 (EST) Received: by mail-qt1-x833.google.com with SMTP id d75a77b69052e-41e3e77e675so23806511cf.1 for ; Sun, 19 Nov 2023 16:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=connectivitycap.com; s=google; t=1700440511; x=1701045311; darn=lists.bufferbloat.net; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dFMdO7OtBahe/FYGq5zagT5iU5A+ogDq7hbJvb/MlOI=; b=Ib5VPdaddbuEpJa2B6sXoqEtD9FdVKgQwNEWQsq3xbVuZQgOmyJq0Vv3n1SQ+Lr9+6 2/Jyq7yH9/jUDXMZR07lHuvtgB+9fPlUW+UQhTaQSlT1ZAYFQXTO8FYTdpm4JAR61VKY ZxX7mTv3WmcetLu+hdotr0669aw4K6Bu8DZhabQygkhQrRrBTkHe4qR8H8+HT0mf2rUD sfLjn+LXWqICd7k5Vf831KKKo2WQX+6bX4jBEpLg95cit/iEosG0LDfDyZYnv9Aoepnk MmporZz3mRSh5Sgfn4MZGvDrjIZ37uvC93CTpb3XBS+4DOzx59mIz9/vt2AAGZnoepLi +uvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700440511; x=1701045311; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dFMdO7OtBahe/FYGq5zagT5iU5A+ogDq7hbJvb/MlOI=; b=w+6g2A0F9dyPCMUSeNOHWDsl5nJcp/QkDevloA26orCKsv+zhQvaZvc0PPhjubZfQQ xUQLAjfZgqtnZ9Jq4idGwW09ilK8YLZbbS7yIOSFj7+wvPJF3ccKE03Mboy05SST8ZAA Lmz25PtsK7ldZ9QzYUDLvXyOAp8Ywndthg3+1MmbmF7pIEnnBQ0Jmg7BCUD2YuRxqdSz pXq05hLHNgVEAGdSxz7/zaIHjy3/Hj7MIkAzrj0tJOLb39EPd7hzf7oYVClf42e4Y4mf y5/C/zkF+mNvWerSfQ8LzlfXu6rwk2VnPE6LzClK27yKnfXaYgaa7LnLZwcAXTCogCyI mMVA== X-Gm-Message-State: AOJu0YzfkOYeuK9RFypGGv5d+zSxLpcEC4vwKF32iBgW6Tpen6KqigH0 UU8Ke0aHpvmOuUvdOSs+mjS5Zg== X-Google-Smtp-Source: AGHT+IFouZkjUp5N4aiPQoyhq9E52ii1vAl3IWpGvm9df12IWsRGYLLDWXKk5hVy1QDGV2IqhQnRiQ== X-Received: by 2002:a05:622a:11c4:b0:41e:3de2:c8ff with SMTP id n4-20020a05622a11c400b0041e3de2c8ffmr9890868qtk.51.1700440511215; Sun, 19 Nov 2023 16:35:11 -0800 (PST) Received: from smtpclient.apple ([205.220.129.20]) by smtp.gmail.com with ESMTPSA id h8-20020ac87448000000b00419714dd0b9sm2244468qtr.62.2023.11.19.16.34.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Nov 2023 16:35:10 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) From: Jim Forster In-Reply-To: Date: Mon, 20 Nov 2023 02:34:20 +0200 Cc: Nicholas Weaver , libreqos , Dave Taht Content-Transfer-Encoding: quoted-printable Message-Id: <77361236-700F-462F-A8AA-74F592D3DE84@connectivitycap.com> References: To: Jonathan Brewer X-Mailer: Apple Mail (2.3774.200.91.1.1) Subject: Re: [LibreQoS] The New Zealand broadband report X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2023 00:35:12 -0000 Jon, I couldn=E2=80=99t resist asking you for comment. :-) Jim > On Nov 9, 2023, at 4:56=E2=80=AFPM, Dave Taht via LibreQoS = wrote: >=20 > = https://comcom.govt.nz/__data/assets/pdf_file/0025/329515/MBNZ-Winter-Repo= rt-28-September-2023.pdf >=20 > While this is evolving to be one of the best of government reports I > know of, leveraging samknows rather than ookla, it has > a few glaring omissions that I wish someone would address. >=20 > It does not measure web page load time. This is probably a relative > constant across all access technologies, limited only by the closeness > of the (latency) to the web serving site(s). >=20 > It does not break out non-lte, non-5g fixed wireless. I am in touch > with multiple companies within NZ that use unlicensed or licensed > spectrum such as uber.nz that are quite proud of how competitive they > are with fiber. Much of the 5g problem is actually backhaul routing in > this report's case. Rural links can also have more latency because of > how far away from the central servers they are in the first place, it > would be good if future reports did a bit more geo-location to > determine how much latency was unavoidable due to the laws of physics. >=20 > My second biggest kvetch is on figure 16. The differences in latency > under load are *directly* correlated to a fixed and overlarge buffer > size across all these technologies running at different bandwidths. > More speed, at the same buffering =3D less delay. The NetAlyzer = research > showed this back in 2011 - so if they re-plotted this data in the way > described below - they would derive the same result. Sadly the > netalyzer project died due to lack of funding and the closest I have > to being able to have a historical record of dslreports variant of the > same test is via the internet archive. >=20 > = https://web.archive.org/web/20230000000000*/http://www.dslreports.com/spee= dtest/results/bufferbloat?up=3D1 >=20 > To pick one of those datasets and try to explain them - >=20 > = https://web.archive.org/web/20180323183459/http://www.dslreports.com/speed= test/results/bufferbloat?up=3D1 >=20 > The big blue blobs were the default buffersizes in cable 2018 at those > upload speeds. DSL was similar. Fiber historically had saner values > for buffering in the first place - but I am seeing bad clusters of > 100+ms extra ms at 100Mbit speeds there. >=20 > dslreports has been dying also, so anything much past 2020 is suspect > and even before then, as the site was heavily used by people tuning > their SQM/fq_codel/or cake implementations, not representative of the > real world, which is worse. The test also cuts off at 4 seconds. This > and most speedtests we have today do not include tests that do not > complete - which is probably the most important indicator of genuine > problems. >=20 > My biggest kvetch (for decades now) is that none of the tests test up > + down + voip or videoconferencing, just sequentially. This is the > elephant in the room, the screenshare or upload moment when a home > internet gets glitchy, your videoconference freezes or distorts, or > your kids scream in frustration at missing their shot in their game. 1 > second of induced latency on the upload link makes a web page like > slashdot, normally taking > 10s, take... wait for it... 4 minutes. This very easily demonstrable > to anyone that might disbelieve this.... >=20 > Despite my advocacy of fancy algorithms like SFQ, fq_codel or cake, > the mere adoption across the routers along the edge of a correct FIFO > buffersize for the configured bandwidth would help enormously, > especially for uploads. We are talking about setting *one* number > here correctly for the configured bandwidth. We are not talking about > recompiling firmware, either. Just one number, set right. I typically > see 1256 packet buffers, where at 10Mbit, not much more than 50 packet > buffers is needed. Ideally that gets set in bytes... or replaced with > at the very least, SFQ, which has been in linux since 2002. >=20 >=20 > --=20 > Oct 30: = https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html > Dave T=C3=A4ht CSO, LibreQos > _______________________________________________ > LibreQoS mailing list > LibreQoS@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/libreqos