[Bloat] DSLReports Speed Test doesn't like Remote Desktop

[Bloat] DSLReports Speed Test doesn't like Remote Desktop

[Kenneth Porter]

The DSLReports speed test gives me <5 Mbps download speed when used over a 
Remote Desktop connection. The same test gives me around 200 Mbps when run 
on my machine connected to my display. The Waveform test shows 200 Mbps 
from the remote machine. All are done with Chrome. Bunch of tabs open on 
both, similar sets of extensions.

I'm testing my Comcast XB3 modem + OpenWrt router before upgrading it to 
XB7.

I use two computers, both Win10-x64. One's a half-height with a bit better 
CPU and memory that I use for development and web/mail, while the other has 
a full-height tower chassis so it has my good video card for gaming. I have 
my big 43" display hooked to the latter and I remote to the short machine 
for "business" use.

https://www.waveform.com/tools/bufferbloat?test-id=62b54f0c-eb3e-40c8-ab99-4f2105f39525

This one looks very poor, 4 Mbps:

http://www.dslreports.com/speedtest/69341504

Much better, direct instead of through RDP:

http://www.dslreports.com/speedtest/69341657

Re: [Bloat] DSLReports Speed Test doesn't like Remote Desktop

[Jonathan Morton]

> On 27 Aug, 2021, at 2:25 am, Kenneth Porter <shiva@sewingwitch.com> wrote:
> 
> The DSLReports speed test gives me <5 Mbps download speed when used over a Remote Desktop connection. The same test gives me around 200 Mbps when run on my machine connected to my display. The Waveform test shows 200 Mbps from the remote machine. All are done with Chrome. Bunch of tabs open on both, similar sets of extensions.
> 
> I'm testing my Comcast XB3 modem + OpenWrt router before upgrading it to XB7.
> 
> I use two computers, both Win10-x64. One's a half-height with a bit better CPU and memory that I use for development and web/mail, while the other has a full-height tower chassis so it has my good video card for gaming. I have my big 43" display hooked to the latter and I remote to the short machine for "business" use.
> 
> https://www.waveform.com/tools/bufferbloat?test-id=62b54f0c-eb3e-40c8-ab99-4f2105f39525
> 
> This one looks very poor, 4 Mbps:
> 
> http://www.dslreports.com/speedtest/69341504
> 
> Much better, direct instead of through RDP:
> 
> http://www.dslreports.com/speedtest/69341657

A browser-based speed test like DSLreports depends heavily on the responsiveness of the browser itself.  It would appear that RDP interferes with that quite spectacularly, although I'm unsure exactly why.  The only advice I can give is "don't do that, then".

 - Jonathan Morton

Re: [Bloat] DSLReports Speed Test doesn't like Remote Desktop

[Kenneth Porter]

--On Friday, August 27, 2021 2:18 PM +0300 Jonathan Morton 
<chromatix99@gmail.com> wrote:

> A browser-based speed test like DSLreports depends heavily on the
> responsiveness of the browser itself.  It would appear that RDP
> interferes with that quite spectacularly, although I'm unsure exactly
> why.  The only advice I can give is "don't do that, then".

I've gotten good numbers from Xfinity's own speed test, and the Waveform 
test shows what I expect. I'm pretty sure I've gotten reasonable numbers 
from DSLReports in the past year, so this week's DSLReports test was quite 
surprising in sucking so badly. I did check the "low-fi" option to disable 
browser animations (and yet still got animations) so maybe DSLReports broke 
that and is trying to do browser animations in the same thread as the speed 
test.

I almost never have a problem with app responsiveness over the RDP 
connection, including Youtube on my 4k screen at 60 Hz. The one thing I 
don't virtualize is 3D stuff, notably gaming. It's actually impressive just 
how much stuff "just works" over RDP. (The two boxes ARE connected by only 
a 1 Gbit switch.)

Re: [Bloat] DSLReports Speed Test doesn't like Remote Desktop

[Kenneth Porter]

Mea culpa! PEBCAK.

I forgot that I had one PC manually configured to use a different router 
and modem. I've got a cheap service on the other one as a backup in case my 
high speed Comcast goes down. (Usually because someone hits a pole between 
here and the CMTS.) I switched to the good router and now I'm seeing good 
numbers from DSLReports:

<http://www.dslreports.com/speedtest/69350624>

<https://www.waveform.com/tools/bufferbloat?test-id=efdee441-ff50-4da3-b1aa-aacbc289c558>

This is through an XB3 modem and Zyxel running OpenWrt with cake.

With SQM disabled (and hence no speed cap):

<http://www.dslreports.com/speedtest/69350679>

<https://www.waveform.com/tools/bufferbloat?test-id=7d1774d6-2739-4043-bb4b-fef8d65e1f5c>

Both grant an A for bufferbloat. It looks like my service improved since 
the last time I tuned cake, when I set the cap to 170 Mbps. The new modem, 
an XB7, should make the SQM in the router unnecessary. (I might still need 
the router to shield my LAN from the modem's DHCP server, if it can't be 
disabled. I want my clients to use my own DNS server and static DHCP 
configurations.)

Re: [Bloat] DSLReports Speed Test doesn't like Remote Desktop

[Michael Richardson]

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.

Re: [Bloat] DSLReports Speed Test doesn't like Remote Desktop

[Jonathan Morton]

> On 28 Aug, 2021, at 10:36 pm, Michael Richardson <mcr@sandelman.ca> wrote:
> 
> 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.

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