From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 935DE3B29E for ; Sat, 28 Aug 2021 16:07:35 -0400 (EDT) Received: by mail-lf1-x12d.google.com with SMTP id z2so22122787lft.1 for ; Sat, 28 Aug 2021 13:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DV12BPjmYPVCLo603Y0P/dR6k4O78cfY9ot3sRLi3Z8=; b=UQywXNKXCOhmNb0qiBm/toUgD4/2dkyxDRy6YsePD7W8oL3PpXrsoru1eoYSezwE+J Stz61BOgLj+M28wxouHUBF0j8wfIOSjC9Ggsroa4S4gvSMoSX/GNij2Nng/pe5LjqrEZ MzARDb8xls7oOen9/UqTtjNqBQsiJJ96+AnVK/q/J+licma+u81NcEO6/ILMF0ZortTi y5T199rKkSSPS4yWku4WrP4pZL/4tlQz8Unegm/pputoKDrh5Bc2kwvPztDE+fr+DQt4 mygMmaPWrR2VgCG3yOLVtHx/t3qE0kUdkP94CAw/WCx5XqNNhtjwHVbK7xJ0iIo3kPfT SlYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DV12BPjmYPVCLo603Y0P/dR6k4O78cfY9ot3sRLi3Z8=; b=hSkEX1mvnb/daxoIgKulmyIj1bxHZU1OCan8UpQvVtpsru9TLW7L7LRPPvF2sl5k0v y+mOCCnpWuMb/9lXT+CsrRbbiYtCoBDXzva/bDAZE8lJunPTklaidRgMNeHR+ot9+W2N QvyE2wCPT9K68bQqm0eSuHv9lUXiIeiGV5U0tUsYD7RpDt8aug5Ly+kENUSgBQPVdzOW 9me5wK2IYg9RKQ9d5e+DfuSr9nkvRoWkuyiiN5c8o9oCAR6u0tLPMMnZumj/w4rNUk8Y lTpu+vHBPIryHMEORf1E/I2dCVzaCNlGrhwZGMF0hxFkTPmCNYupSUTmIOC1LUgViEtX Mm0A== X-Gm-Message-State: AOAM530uOuk1QF6hClervx9PW3NRGFQ4FFxHFNyYAdT3TArnzQuXSIfA yV0MN/yxT1sk2nirfuiy4DOYRPUZ6/zcPA== X-Google-Smtp-Source: ABdhPJyl/Vla3g8aXpER6jdgmsjotDvxVFvgC2LjCGG4EcNpIR/tZ1Q5R8XjxAdNlnxTqzd10FIwpA== X-Received: by 2002:a19:4311:: with SMTP id q17mr11302687lfa.174.1630181254047; Sat, 28 Aug 2021 13:07:34 -0700 (PDT) Received: from smtpclient.apple (178-55-70-16.bb.dnainternet.fi. [178.55.70.16]) by smtp.gmail.com with ESMTPSA id b18sm1184971ljk.24.2021.08.28.13.07.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Aug 2021 13:07:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Jonathan Morton In-Reply-To: <4088.1630179385@localhost> Date: Sat, 28 Aug 2021 23:07:29 +0300 Cc: Kenneth Porter , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <810C04263C4D0099AD780B2F@[192.168.1.16]> <133F6C06-4354-4E84-8D7A-AED43E00126D@gmail.com> <4088.1630179385@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3654.100.0.2.22) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2021 20:07:35 -0000 > On 28 Aug, 2021, at 10:36 pm, Michael Richardson = wrote: >=20 > 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. >=20 > 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. >=20 > I thought that there were patches to RDP to make this better, but I = never > confirmed this. Funnily enough, I was actually in the VNC community for a while, having = written a functioning server for Classic MacOS, so I'm familiar with = this dilemma. Due to some quirks of Classic MacOS, it was often = necessary to do the screen-scraping, encoding and socket transmissions = at interrupt time, and I had to limit the amount of data generated at = any given time so that it didn't block on a full buffer - which could = lock *everything* up. My experience of modern browser rendering pipelines is that they do = everything in backbuffers, then blit them to the screen wholesale. This = *should* be quite efficient for an RDP to handle, so long as it excludes = areas that were unchanged on consecutive blits. But it's also possible = for it to pick up drawing to background tabs, and only after much CPU = effort determine that nothing visibly changed. At any rate, the original problem turned out to be something else = entirely. - Jonathan Morton=