From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (masada.superduper.net [85.119.82.91]) (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 24F9A3B2A4 for ; Thu, 25 Feb 2021 08:53:41 -0500 (EST) Received: from 52-119-118-48.public.monkeybrains.net ([52.119.118.48] helo=[192.168.131.74]) by masada.superduper.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1lFH5F-0004Va-6y; Thu, 25 Feb 2021 13:53:37 +0000 From: Simon Barber To: Mikael Abrahamsson CC: Sina Khanifar , , bloat Date: Thu, 25 Feb 2021 05:53:36 -0800 Message-ID: <177d9776300.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> In-Reply-To: References: <177d80af608.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <177d9698ff0.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> User-Agent: AquaMail/1.28.1-1760 (build: 102800003) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------177d977666032f727a91ff5196" X-Spam-Score: -2.9 (--) Subject: Re: [Bloat] Updated Bufferbloat Test 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: Thu, 25 Feb 2021 13:53:41 -0000 This is a multi-part message in MIME format. ------------177d977666032f727a91ff5196 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit So perhaps this can feed into the rating system, total latency < 50mS is an A, < 150mS is a B, 600mS is a C or something like that. Simon On February 25, 2021 5:49:26 AM Mikael Abrahamsson wrote: > On Thu, 25 Feb 2021, Simon Barber wrote: > >> The ITU say voice should be <150mS, however in the real world people are >> a lot more tolerant. A GSM -> GSM phone call is ~350mS, and very few >> people complain about that. That said the quality of the conversation is >> affected, and staying under 150mS is better for a fast free flowing >> conversation. Most people won't have a problem at 600mS and will have a >> problem at 1000mS. That is for a 2 party voice call. A large group >> presentation over video can tolerate more, but may have issues with >> talking over when switching from presenter to questioner for example. > > I worked at a phone company 10+ years ago. We had some equipment that > internally was ATM based and each "hop" added 7ms. This in combination > with IP based telephony at the end points that added 40ms one-way per > end-point (PDV buffer) caused people to complain when RTT started creeping > up to 300-400ms. This was for PSTN calls. > > Yes, people might have more tolerance with mobile phone calls because they > have lower expectations when out and about, but my experience is that > people will definitely notice 300-400ms RTT but they might not get upset > enough to open a support ticket until 600ms or more. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se ------------177d977666032f727a91ff5196 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So perhaps this can feed into the rating system, total la= tency < 50mS is an A, < 150mS is a B, 600mS is a C or something like = that.

Simon

On February 25, 2021 5:49:26 AM Mikael Abrahamsson <sw= mike@swm.pp.se> wrote:

On Thu, 25 Feb 2021, Simon Barber wrote:

The ITU say voice should be <150mS, however in the rea= l world people are 
a lot more tolerant. A GSM -> GSM phone call is ~350mS= , and very few 
people complain about that. That said the quality of the = conversation is 
affected, and staying under 150mS is better for a fast fr= ee flowing 
conversation. Most people won't have a problem at 600mS a= nd will have a 
problem at 1000mS. That is for a 2 party voice call. A la= rge group 
presentation over video can tolerate more, but may have i= ssues with 
talking over when switching from presenter to questioner = for example.

I worked at a phone company 10+ years ago. We had some eq= uipment that 
internally was ATM based and each "hop" added 7ms. This i= n combination 
with IP based telephony at the end points that added 40ms= one-way per 
end-point (PDV buffer) caused people to complain when RTT= started creeping 
up to 300-400ms. This was for PSTN calls.

Yes, people might have more tolerance with mobile phone c= alls because they 
have lower expectations when out and about, but my experi= ence is that 
people will definitely notice 300-400ms RTT but they migh= t not get upset 
enough to open a support ticket until 600ms or more.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

------------177d977666032f727a91ff5196--