Discussion:
mintty slow refresh rate over RDP
(too old to reply)
David Dombrowsky
2018-11-26 18:16:29 UTC
Permalink
I might the only one in the world to run into this, but it happens so
often that I need to ask the question.

I connect over a LAN to a windows box from my linux machine using
`rdesktop`. I then launch a cygwin terminal window using the normal
shortcut, which launches mintty.exe. If I then run a build of
something, which scrolls a reasonable amount of data to the screen,
rdesktop then freaks out for a while trying to constantly redraw the
mintty window. Sometimes I have to wait for the build to finish before
I can even minimize the window.

Anyone know which part is messing up here? This doesn't happen playing
videos or other graphically intensive programs. Only the cygwin
terminal. Anyone have any ideas?
--
David Dombrowsky, Software Engineer
***@6thstreetradio.org | 518-374-3204
https://www.linkedin.com/in/david-dombrowsky-94334415

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Stefan Baur
2018-11-26 18:25:08 UTC
Permalink
Post by David Dombrowsky
Anyone know which part is messing up here? This doesn't happen playing
videos or other graphically intensive programs. Only the cygwin
terminal. Anyone have any ideas?
As far as I know, rdesktop still uses an older version of the RDP
protocol, so you might want to try FreeRDP (xfreerdp on most Linuxes I
know) and take a good look at the options it supports for speeding up
the screen updates.

Kind Regards,
Stefan Baur
--
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
David Dombrowsky
2018-11-26 20:20:47 UTC
Permalink
Post by Stefan Baur
Post by David Dombrowsky
Anyone know which part is messing up here? This doesn't happen playing
videos or other graphically intensive programs. Only the cygwin
terminal. Anyone have any ideas?
As far as I know, rdesktop still uses an older version of the RDP
protocol, so you might want to try FreeRDP (xfreerdp on most Linuxes I
know) and take a good look at the options it supports for speeding up
the screen updates.
You are correct. There are different results using different clients.
All of them present some level of the issue, though.

mintty is the only non-X11 terminal emulator in the stack, correct?
--
David Dombrowsky, Software Engineer
***@6thstreetradio.org | 518-374-3204
https://www.linkedin.com/in/david-dombrowsky-94334415

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Thomas Wolff
2018-11-26 23:34:55 UTC
Permalink
---
    I find best results hosting the GUI (the window of
the TTY) on the local machine, and only transfering the data
(the txt of the ssh session).
    On of the features you might want to use for your situation,
though, is make sure "jump-scroll" is turned on if it is not.
Otherwise any terminal program might take a very long time to catch
up.  It really is an expensive operation to scroll text on a remote
machine.  Early HW terminals and PC screens used special hardware
to perform scrolling at fast speed.  Performing a smooth scroll
via bit-moves of memory would be VERY painful on older machines
or current machines using a slow-enough remote interface.
Mintty does not support smooth scrolling. (I gave it a try once but
there is no complete implementation.)
    Try running xterm locally and make sure TERM is set correctly on
the remote machine and I think you may be happier
with the performance and "feel"...
A good suggestion anyway.
However, if you provide instructions on how to reproduce the issue, I
may find time to check out whether there is some improvement potential.
Thomas

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Brian Inglis
2018-11-27 16:37:56 UTC
Permalink
    I find best results hosting the GUI (the window of
the TTY) on the local machine, and only transfering the data
(the txt of the ssh session).
    On of the features you might want to use for your situation,
though, is make sure "jump-scroll" is turned on if it is not.
Otherwise any terminal program might take a very long time to catch
up.  It really is an expensive operation to scroll text on a remote
machine.  Early HW terminals and PC screens used special hardware
to perform scrolling at fast speed.  Performing a smooth scroll
via bit-moves of memory would be VERY painful on older machines
or current machines using a slow-enough remote interface.
Glass ttys needed special hardware because the early uP chips running at low
speeds with small ROMs could not do much between displaying lines.
VT100 smooth scroll with No Scroll key toggle was like having more/less built in
to the terminal; VT52 had a Scroll key which supported something similar.
Mintty does not support smooth scrolling. (I gave it a try once but there is no
complete implementation.)
Smooth scroll is a screen update after each scan line instead of each char line
so displays about eight times slower than jump scroll.
    Try running xterm locally and make sure TERM is set correctly on the
remote machine and I think you may be happier
with the performance and "feel"...
Connect using ssh (-Y or with appropriate session settings in ~/.ssh/config) to
Windows/Cygwin bash from your Linux console/term/tmux/screen session like you
would to any other Unix system.
A good suggestion anyway.
However, if you provide instructions on how to reproduce the issue, I may find
time to check out whether there is some improvement potential.
Sounds like the issue is sending images of fast scrolling text over early RDP
protocol sessions which can probably only be improved by not updating the screen
as much when running under a remote session using an early protocol.
Perhaps more recent RDP protocol sessions recognized and transmitted the text
updates rather than image updates, less frequent image updates, or used some
terminal display optimizations developed over the decades since glass ttys were
replaced by term emulators.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
R0b0t1
2018-11-27 18:14:03 UTC
Permalink
On Tue, Nov 27, 2018 at 5:38 PM Brian Inglis
Post by Brian Inglis
I find best results hosting the GUI (the window of
the TTY) on the local machine, and only transfering the data
(the txt of the ssh session).
On of the features you might want to use for your situation,
though, is make sure "jump-scroll" is turned on if it is not.
Otherwise any terminal program might take a very long time to catch
up. It really is an expensive operation to scroll text on a remote
machine. Early HW terminals and PC screens used special hardware
to perform scrolling at fast speed. Performing a smooth scroll
via bit-moves of memory would be VERY painful on older machines
or current machines using a slow-enough remote interface.
Glass ttys needed special hardware because the early uP chips running at low
speeds with small ROMs could not do much between displaying lines.
VT100 smooth scroll with No Scroll key toggle was like having more/less built in
to the terminal; VT52 had a Scroll key which supported something similar.
Mintty does not support smooth scrolling. (I gave it a try once but there is no
complete implementation.)
Smooth scroll is a screen update after each scan line instead of each char line
so displays about eight times slower than jump scroll.
Try running xterm locally and make sure TERM is set correctly on the
remote machine and I think you may be happier
with the performance and "feel"...
Connect using ssh (-Y or with appropriate session settings in ~/.ssh/config) to
Windows/Cygwin bash from your Linux console/term/tmux/screen session like you
would to any other Unix system.
While this workaround may work here, all current (2018Q4) SSH
implementations do not implement Window's permission model properly
and may not ever do so. Microsoft has their own port of OpenSSH and is
having trouble doing this. There are some programs that will not run
under SSH as it exists now, or even as packaged by Bitvise.
Post by Brian Inglis
A good suggestion anyway.
However, if you provide instructions on how to reproduce the issue, I may find
time to check out whether there is some improvement potential.
Sounds like the issue is sending images of fast scrolling text over early RDP
protocol sessions which can probably only be improved by not updating the screen
as much when running under a remote session using an early protocol.
Perhaps more recent RDP protocol sessions recognized and transmitted the text
updates rather than image updates, less frequent image updates, or used some
terminal display optimizations developed over the decades since glass ttys were
replaced by term emulators.
More recent RDP sessions should fix this. They do not send GDI calls
and instead capture the screen at intervals and compress it. There
should be no traffic generated by frequent screen updates.

Cheers,
R0b0t1

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
David Dombrowsky
2018-11-27 19:23:26 UTC
Permalink
Post by R0b0t1
Post by Brian Inglis
Glass ttys needed special hardware because the early uP chips running at low
speeds with small ROMs could not do much between displaying lines.
VT100 smooth scroll with No Scroll key toggle was like having more/less built in
to the terminal; VT52 had a Scroll key which supported something similar.
NOW you're bringing me back to freshman year :)

I remember building a system from scratch and having no "less" or "more"
tool, and the only way I could find a build error before it scrolled by
was to turn on the "smooth scroll" button.
Post by R0b0t1
Post by Brian Inglis
Post by Thomas Wolff
A good suggestion anyway.
However, if you provide instructions on how to reproduce the issue, I may find
time to check out whether there is some improvement potential.
My use case:
1) run windows 7 in a VM
2) use rdesktop (ubuntu xenial, rdesktop Version 1.8.3) to connect to
the windows box's desktop (used to run visual studio, etc.)
3) launch mintty, maximize the window
4) run a build that spits out a lot of logging. This can be simulated
with "od /dev/urandom".

On my machine, it will lock up the desktop for a while, until I can
switch desktops, ssh into the windows box, and kill the offending process.

This is certainly multiple bugs, since X11 shouldn't lock up in any
case. However, I can play fullscreen video over rdesktop without an
issue, so I'm not sure why the console is so graphically intensive.
Post by R0b0t1
More recent RDP sessions should fix this. They do not send GDI calls
and instead capture the screen at intervals and compress it.
This is true. Unfortunately, none of them have made it into distros
yet. A local build of xfreerdp 2.0 will work fine, BUT that version
removes a few features I use [insert oblig XKCD here]. So *shrug*.
--
David Dombrowsky, Software Engineer
***@6thstreetradio.org | 518-374-3204
https://www.linkedin.com/in/david-dombrowsky-94334415

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Loading...