From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 507573B29E for ; Wed, 4 Nov 2020 16:30:27 -0500 (EST) Received: by mail-lf1-x136.google.com with SMTP id 126so29101996lfi.8 for ; Wed, 04 Nov 2020 13:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=repeaterstore.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=T5Nv/HgjmMIIWbePBtXOIDeXox+OvqMEKyabWGhC4CU=; b=ioY5T8lQKaDaPp4pNHh+no0B3WBqmYEsSYiaiQv2zph88oNkiZWK/67r249C2TnfP4 3Vwy9do8Ctip6UKFPsRxFQTJDDFEmObEfftuO67saaHRQSXxO3DiIKPcxv3RYFoM7pWR o50BY1SK/cLS2CuyhOpIdTvcNnWvLIjdH/Q+M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=T5Nv/HgjmMIIWbePBtXOIDeXox+OvqMEKyabWGhC4CU=; b=h4uQc/O22fsDsVuRpD7l+uzVBdRrJgY4KtyvKlRiqia8JM0fVeHVNNJ2ko9fQRwTte Azik/lfMY97ikB9WWZQi/94kr0OG5X9Y2Wp0WqUchGRZIhOPkfVDqX9CpT4AZCzPNy2b 6JbU/1tnCawGEO4BLxS8BoDtQMj7HAKs+CiPmOSMU/q9v/y8aRVPE3iTXi2h362NvoH1 O1CxtYBTILDqRiO8lxQSrq8afjhWSkmbigq4UJUqmGkry5S8WaDPFF/OxzlRvuSeI7gz 21inhVYGbuuuJdJfYB2ta4sg0YhmktGgASnwZMz79Rbs3RhkWDrJpjc4YL3hacnVzbGr aatQ== X-Gm-Message-State: AOAM5302OH1Sjs9KZei56J/o2suCbIwAKu0RbLUm4hBi2HFuXicWoTxT oAl0SZz1pEUZZmdDxQgH/JSSv0yaU+FtDn++f4tMtiJevruom3ycvsPXJhsfgKhYjwelRN8t8GY UzdW/P7wYVPJCCGReCTEhKU6ZlUccAKpai44lMoZMkNP+OA6WpN5pccQXZS4yYh6UEJFbXROsCz y+WQ45Zbtl/uUuJlyhFsfdOSLAJn8n X-Google-Smtp-Source: ABdhPJziuQzNgXSmizAr33V+DlmulXIt5I8IHgdl9lvMapbRcXQfhyyD0XUAm6+9tVR73u+U5VFuXGJqFJ4Qye0+qMc= X-Received: by 2002:a19:857:: with SMTP id 84mr9880092lfi.235.1604525425448; Wed, 04 Nov 2020 13:30:25 -0800 (PST) MIME-Version: 1.0 From: Sam Westwood Date: Wed, 4 Nov 2020 21:30:14 +0000 Message-ID: To: bloat@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000046dd905b34eb0df" X-Mailman-Approved-At: Wed, 04 Nov 2020 17:43:57 -0500 Subject: [Bloat] We built a new bufferbloat test and keen for feedback X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 21:30:27 -0000 --000000000000046dd905b34eb0df Content-Type: text/plain; charset="UTF-8" Hi everyone, My name is Sam and I'm the co-founder and COO of Waveform.com. At Waveform we provide equipment to help improve cell phone service, and being in the industry we've always been interested in all aspects of network connectivity. Bufferbloat for us has always been interesting, and while there are a few tests out there we never found one that was fantastic. So we thought we'd try and build one! My colleague Arshan has built the test, which we based upon the Cloudflare Speedtest template that was discussed earlier in the summer in a previous thread. We measure bufferbloat under two conditions: when downlink is saturated and when uplink is saturated. The test involves three stages: Unloaded, Downlink Saturated, and Uplink Saturated. In the first stage we simply measure latency to a file hosted on a CDN. This is usually around 5ms and could vary a bit based on the user's location. We use the webTiming API to find the time-to-first-byte, and consider that as the latency. In the second stage we run a download, while simultaneously measuring latency. In the third stage we do the same but for upload. Both download and upload usually take around 5 seconds. We show the median, first quartile and the third quartile on distribution charts corresponding to each stage to provide a visual representation of the latency variations. For download and upload we have used Cloudflare's speedtest backend. You can find the test here: https://www.waveform.com/apps/dev-arshan We built testing it on Chrome, but it works on Firefox and mobile too. On mobile results may be a little different, as the APIs aren't available and so instead we implemented a more manual method, which can be a little noisier. This is a really early alpha, and so we are keen to get any and all feedback you have :-). Things that we would particularly like feedback on: - How does the bufferbloat measure compare to other tests you may have run on the same connection (e.g. dslreports, fast.com) - How the throughput results (download/upload/latency) look compared to other tools - Any feedback on the user interface of the test itself? We know that before releasing more widely we will put more effort into explaining bufferbloat than we have so far. - Anything else you would like to give feedback on? We have added a feature to share results via a URL, so please feel free to share these if you have specific feedback. Thanks! Sam and Arshan ************************* Sam Westwood Co-Founder & COO | RSRF & Waveform E sam@waveform.com D (949) 207-3175 T 1-800-761-3041 Ext. 100 W www.rsrf.com & www.waveform.com --000000000000046dd905b34eb0df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,=C2=A0

My name is Sam and I'm the = co-founder and COO of Waveform.com. At Waveform we provide equipment to hel= p improve cell phone service, and being in the industry we've always be= en interested in all aspects of network connectivity. Bufferbloat for us ha= s always been interesting, and while there are a few tests out there we nev= er found one that was fantastic. So we thought we'd try and build one!<= /div>

My colleague Arshan has built the test, which we based upon t= he Cloudflare Speedtest template that was discussed earlier in the summer i= n a previous thread.

We measure bufferbloat under two co= nditions: when downlink is saturated and when uplink is saturated. The test= involves three stages: Unloaded, Downlink Saturated, and Uplink Saturated.= In the first stage we simply measure latency to a file hosted on a CDN. Th= is is usually around 5ms and could vary a bit based on the user's locat= ion. We use the webTiming API to find the time-to-first-byte, and consider = that as the latency. In the second stage we run a download, while simultane= ously measuring latency. In the third stage we do the same but for upload. = Both download and upload usually take around 5 seconds. We show the median,= first quartile and the third quartile on distribution charts corresponding= to each stage to provide a visual representation of the latency variations= . For download and upload we have used Cloudflare's speedtest backend. =

You can find the test here: https://www.waveform.com/apps/dev-arshan
We built testing it on Chrome, but it works on Firefox and mob= ile too. On mobile results may be a little different, as the APIs aren'= t available and so instead we implemented a more manual method, which can b= e a little noisier.

This is a really early alpha, and so= we are keen to get any and all feedback you have :-). Things that we would= particularly like feedback on:
  • How does the bufferbloat measur= e compare to other tests you may have run on the same connection (e.g. dslr= eports, fast.com)
  • How the throughpu= t results (download/upload/latency) look compared to other tools
  • An= y feedback on the user interface of the test itself? We know that before re= leasing more widely we will put more effort into explaining bufferbloat tha= n we have so far. =C2=A0
  • Anything else you would like to give feedb= ack on?
We have added a feature to share results via a URL, so ple= ase feel free to share these if you have specific feedback.=C2=A0

Thanks!
Sam and Arshan

*******= ******************
Sam Westwood
Co-Founder & CO= O | RSRF & Waveform
D =C2=A0=C2=A0(949) 207-3175=C2=A0= =C2=A0
T =C2=A0=C2=A01-800-761-3041 Ext. 100
W =C2=A0=C2=A0www.rsrf.com & www.waveform.com
--000000000000046dd905b34eb0df--