From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mcr@sandelman.ca>
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19])
 (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by lists.bufferbloat.net (Postfix) with ESMTPS id 1D30B3B29E
 for <bloat@lists.bufferbloat.net>; Sat, 28 Aug 2021 15:36:31 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
 by tuna.sandelman.ca (Postfix) with ESMTP id 3155238D1C;
 Sat, 28 Aug 2021 15:42:13 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1])
 by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024)
 with LMTP id 5rG-hTo3BXpm; Sat, 28 Aug 2021 15:42:09 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21])
 by tuna.sandelman.ca (Postfix) with ESMTP id 5192638A63;
 Sat, 28 Aug 2021 15:42:09 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1])
 by sandelman.ca (Postfix) with ESMTP id 09C4B90;
 Sat, 28 Aug 2021 15:36:25 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ca>
To: Jonathan Morton <chromatix99@gmail.com>,
 Kenneth Porter <shiva@sewingwitch.com>, bloat <bloat@lists.bufferbloat.net>
In-Reply-To: <133F6C06-4354-4E84-8D7A-AED43E00126D@gmail.com>
References: <810C04263C4D0099AD780B2F@[192.168.1.16]>
 <133F6C06-4354-4E84-8D7A-AED43E00126D@gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;
 <'$9xN5Ub#
 z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4087.1630179384.1@localhost>
Date: Sat, 28 Aug 2021 15:36:25 -0400
Message-ID: <4088.1630179385@localhost>
Subject: Re: [Bloat] DSLReports Speed Test doesn't like Remote Desktop
X-BeenThere: bloat@lists.bufferbloat.net
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: General list for discussing Bufferbloat <bloat.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/bloat>,
 <mailto:bloat-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/bloat>
List-Post: <mailto:bloat@lists.bufferbloat.net>
List-Help: <mailto:bloat-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/bloat>,
 <mailto:bloat-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Sat, 28 Aug 2021 19:36:31 -0000

RDP (specifically with Windows as the desktop) is integrated into the display
pipeline such that it effectively never loses frames.  The results of an
(e.g.) Excel redraw over a slow link can be spectactically stupid with every
cell being drawn each time it is "re"-computed.  The result is that the
application itself is blocked when the RDP frames are being generated.

I/we observed this a decade ago when building virtual desktop infrastructure.
There was a Linux Xrdp server (via a bunch of patches that didn't survive)
that was more screen-scraper.  VNC has always screen scraped the pixels, so it
"naturally" skips the intermediate frames when the application draws faster
than then remote desktop protocol can keep up.

I thought that there were patches to RDP to make this better, but I never
confirmed this.