File-Tunnel

mirror of https://github.com/fiddyschmitt/File-Tunnel.git synced 2026-10-21 13:52:05 +00:00

History

fiddyschmitt fd4b7d397b Lab: run RunRemote, and so ft, at normal priority on the Windows VMs RunRemote is a scheduled task, and a task's default priority (7) is below normal, with low I/O and memory priority as well. Everything it starts inherits that, ft included: measured on ft-win11-1, server.exe and its children ran at base priority 6, I/O priority 1 and page priority 2, where Explorer and sshd run at 8, 2 and 5. A user's ft runs at normal priority. The SOCKS stress rows showed what that costs. Each time the tests' SSH sessions started PowerShell to run curl, both vCPUs went to those processes, at normal priority, and ft got no CPU at all for about 6 s, with up to ten threads ready to run (sampled every 250 ms). Every Windows ft log of those rows had that 6-7 s gap in its once-a-second status line. On 2026-10-16 it ran past the 10 s tunnel timeout, the Linux end went offline, and the -R proxy the Windows end had asked for never came back. A later commit fixes that part in ft. The task now runs at priority 4 (normal), and provisioning restarts a running server whose priority isn't normal. The smoke test checks it. Afterwards the longest stretch ft spent runnable but without CPU fell from 6.2 s to 1.3 s (.83) and from 5.7 s to 0.5 s (.88), and the status-line gaps are gone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SjajJ7d3BhSZGfsMrGRS5S	2026-10-17 22:37:08 +10:00
..
provision.ps1	Lab: run RunRemote, and so ft, at normal priority on the Windows VMs	2026-10-17 22:37:08 +10:00
smoke-test.ps1	Lab: run RunRemote, and so ft, at normal priority on the Windows VMs	2026-10-17 22:37:08 +10:00

fiddyschmitt fd4b7d397b Lab: run RunRemote, and so ft, at normal priority on the Windows VMs

RunRemote is a scheduled task, and a task's default priority (7) is below
normal, with low I/O and memory priority as well. Everything it starts
inherits that, ft included: measured on ft-win11-1, server.exe and its
children ran at base priority 6, I/O priority 1 and page priority 2, where
Explorer and sshd run at 8, 2 and 5. A user's ft runs at normal priority.

The SOCKS stress rows showed what that costs. Each time the tests' SSH
sessions started PowerShell to run curl, both vCPUs went to those
processes, at normal priority, and ft got no CPU at all for about 6 s,
with up to ten threads ready to run (sampled every 250 ms). Every Windows
ft log of those rows had that 6-7 s gap in its once-a-second status line.
On 2026-10-16 it ran past the 10 s tunnel timeout, the Linux end went
offline, and the -R proxy the Windows end had asked for never came back.
A later commit fixes that part in ft.

The task now runs at priority 4 (normal), and provisioning restarts a
running server whose priority isn't normal. The smoke test checks it.
Afterwards the longest stretch ft spent runnable but without CPU fell from
6.2 s to 1.3 s (.83) and from 5.7 s to 0.5 s (.88), and the status-line
gaps are gone.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SjajJ7d3BhSZGfsMrGRS5S

2026-10-17 22:37:08 +10:00

provision.ps1

Lab: run RunRemote, and so ft, at normal priority on the Windows VMs

2026-10-17 22:37:08 +10:00

smoke-test.ps1

Lab: run RunRemote, and so ft, at normal priority on the Windows VMs

2026-10-17 22:37:08 +10:00