Extraordinarily sluggish response to input over busy ssh session #4422

Closed
opened 2026-01-30 23:47:25 +00:00 by claunia · 4 comments
Owner

Originally created by @hwinkler on GitHub (Oct 12, 2019).

Originally assigned to: @zadjii-msft on GitHub.

Environment

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]

`Microsoft Windows [Version 10.0.18999.1]`

Windows Terminal version (if applicable):
`0.5.2762.0`

Any other software? 
`ssh`, `cmd`

Steps to reproduce

  1. ssh to an Ubuntu 18.04 host; log in to bash session.
  2. start byobu
  3. run command
    $ while :; do echo 'All work and no play makes Jack a dull boy.'; done
  4. press F2 key to create new byobu window
  5. press F3 and F4 to toggle screens back and forth several times

Expected behavior

Steps 4 and 5 respond quickly.

Actual behavior

Steps 4 and 5 can take very long times to process the keystroke and respond.
Sometimes 10, 20, 30 seconds, sometimes immediate.

Compare to doing the same process from cmd.exe (in its native window), which responds immediately as expected.

Ctrl-C also is sluggish.

[edited to correct EB and AB and add Ctrl-C comment]

Originally created by @hwinkler on GitHub (Oct 12, 2019). Originally assigned to: @zadjii-msft on GitHub. <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd] `Microsoft Windows [Version 10.0.18999.1]` Windows Terminal version (if applicable): `0.5.2762.0` Any other software? `ssh`, `cmd` ``` # Steps to reproduce 1. ssh to an Ubuntu 18.04 host; log in to `bash` session. 2. start `byobu` 2. run command ```$ while :; do echo 'All work and no play makes Jack a dull boy.'; done``` 3. press `F2` key to create new `byobu` window 4. press `F3` and `F4` to toggle screens back and forth several times # Expected behavior Steps 4 and 5 respond quickly. <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> # Actual behavior Steps 4 and 5 can take very long times to process the keystroke and respond. Sometimes 10, 20, 30 seconds, sometimes immediate. <!-- What's actually happening? --> Compare to doing the same process from `cmd.exe` (in its native window), which responds immediately as expected. Ctrl-C also is sluggish. [edited to correct EB and AB and add Ctrl-C comment]
Author
Owner

@ZimGil commented on GitHub (Jan 29, 2020):

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.592]
Windows Terminal version (if applicable): 0.8.10261.0

I feel the same sluggish response to ssh Connection to <IP> closed by remote host that will also not be solved by Ctrl-C
Maybe related...?

@ZimGil commented on GitHub (Jan 29, 2020): # Environment ```none Windows build number: Microsoft Windows [Version 10.0.18363.592] Windows Terminal version (if applicable): 0.8.10261.0 ``` I feel the same sluggish response to ssh `Connection to <IP> closed by remote host` that will also not be solved by Ctrl-C Maybe related...?
Author
Owner

@hwinkler commented on GitHub (Jan 31, 2020):

Just a note for context:

The purpose of running the shell script infinite loop is to force the remote session to spew a torrent of text. Consuming the torrent seems to block Terminal from prompt handling of control sequences. There are probably simpler ways to repro. But the repro I described still clearly demonstrates the behavior on Terminal 0.8.10261.0

Also, I omitted in the original description to say I am running a wsl Ubuntu session locally, and from that I am ssh-ing to a remote host to run byobu and the infinite loop script.

@hwinkler commented on GitHub (Jan 31, 2020): Just a note for context: The purpose of running the shell script infinite loop is to force the remote session to spew a torrent of text. Consuming the torrent seems to block Terminal from prompt handling of control sequences. There are probably simpler ways to repro. But the repro I described still clearly demonstrates the behavior on Terminal 0.8.10261.0 Also, I omitted in the original description to say I am running a `wsl` Ubuntu session locally, and from that I am ssh-ing to a remote host to run `byobu` and the infinite loop script.
Author
Owner

@zadjii-msft commented on GitHub (Apr 13, 2020):

@hwinkler Are you using ssh.exe that comes with Windows, or the ssh from your linux distro?

Are you possibly using "experimental.retroTerminalEffect": true in your profiles.json?

Does this repro without ssh? or does it require ssh to be in the middle? I'm trying this locally w/o ssh in the middle and I can't seem to get it to repro at all.

Maybe this just got resolved on it's own in the last few releases?

EDIT: @ future me: #1311 specifically mentions being under CPU load. Lets try that.

@zadjii-msft commented on GitHub (Apr 13, 2020): @hwinkler Are you using `ssh.exe` that comes with Windows, or the `ssh` from your linux distro? Are you possibly using `"experimental.retroTerminalEffect": true` in your `profiles.json`? Does this repro _without_ `ssh`? or does it require `ssh` to be in the middle? I'm trying this locally w/o `ssh` in the middle and I can't seem to get it to repro at all. Maybe this just got resolved on it's own in the last few releases? EDIT: @ future me: #1311 specifically mentions being under CPU load. Lets try that.
Author
Owner

@ghost commented on GitHub (Apr 19, 2020):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Apr 19, 2020): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#4422