86Box
Serial port passthrough with certain USB-serial adapters slows VM speed to a crawl
Checklist
- [x] I have searched the issue tracker and was unable to find an open or closed issue matching what I'm seeing.
- [x] I have verified that the issue is happening in the latest nightly build, or the latest commit, if building from source.
What happened?
When enabling the serial port passthrough feature configured to use a host COM port provided by certain USB-serial adapters, I have found that it can make 86Box emulation speed extremely slow. In the worst case, I have seen the speed indicator at the top-right of the window going as low as 7%. Unsurprisingly, this renders emulation almost completely unusable.
I discovered that whether and to what extent 86Box's emulation speed is affected appears to be dependent on what exact USB-serial adapter is being used. I was able to test with the following ones:
- SiLabs CP2102N - Bad (7%) [Driver: Silicon Laboratories Inc, version 11.2.0.167, 2022-04-10]
- FTDI FT2232H - OK (66%) [Driver: FTDI, version 2.12.36.20, 2024-10-28]
- WCH CH340 - Good (100%) [Driver: wch.cn, version 3.9.2024.9, 2024-09-16]
- Generic CDC - Good (100%) [Driver: Microsoft, version 10.0.26100.2454, 2006-06-21]
Stated speed for each measured with VM idling at MS-DOS 6.22 command prompt. Serial port passthrough was configured for 1200 baud, 8 data bits, 1 stop bit.
The slowdown happens at all times (i.e. right from VM start), regardless of whether the virtual serial port is actively in use or not. It doesn't appear to be due to anything bottlenecking 86Box execution, as 86Box process CPU usage barely goes above 1-2%. The slowdown also doesn't appear to cause any malfunction in the way the serial port passthrough works; but of course the VM running at a crawl renders it very difficult to use it in any reasonable manner.
Configuration file
[General]
emu_build_num = 8132
host_cpu = AMD Ryzen 7 9800X3D 8-Core Processor
scale = 2
uuid = c10d3efa-3cf0-5700-918f-7310cfa2acab
vid_renderer = qt_software
[Machine]
cpu_family = pentium2_deschutes
cpu_multi = 4.5
cpu_speed = 450000000
cpu_use_dynarec = 1
fpu_type = internal
machine = p2bls
mem_size = 131072
[Video]
gfxcard = mystique_220
[Input devices]
keyboard_type = keyboard_ps2
mouse_type = none
[Network]
net_01_link = 0
net_02_link = 0
net_03_link = 0
net_04_link = 0
[Storage controllers]
fdc = none
hdc_1 = ide_pci_2ch
[Floppy and CD-ROM drives]
cdrom_01_ide_channel = 1:0
cdrom_01_parameters = 1, atapi
cdrom_01_speed = 36
fdd_01_turbo = 1
fdd_01_type = 35_2hd
fdd_02_type = none
[Ports (COM & LPT)]
serial1_passthrough_enabled = 1
serial2_enabled = 0
[Hard disks]
hdd_01_fn = <exe_path>/MS-DOS 6.22 Installation.img
hdd_01_ide_channel = 0:0
hdd_01_parameters = 63, 16, 1040, 0, ide
hdd_01_speed = ramdisk
[PS/2 Mouse]
buttons = 3
[Serial Passthrough Device #1]
mode = 4
host_serial_path = \\.\COM8
data_bits = 8
stop_bits = 1
baudrate = 1200
named_pipe = \\.\pipe\86Box\test
[Microsoft Serial Mouse]
port = 0
buttons = 2
Operating system
Windows 11 24H2 26100.7462
86Box version
v5.3 build 8132
Build architecture
Windows - x64 (64-bit)
Build type
- [ ] New recompiler
- [ ] Debug build
Additional context
No response
The % goes down because serial passthrough is consuming time but does not subtract an adequate number of emulated CPU cycles to account for it.
Also, this is going to be hard for any of us to reproduce because I don't think any of us has those offending USB serial chips. I may have a FTDI one somewhere, but that's about it.
Is there anything I can do to help diagnose the issue? Logging? Debug settings?
Tried already the --debug and --logfile command-line options, but nothing apart from some header info gets logged. Does this only give output on a debug build? If so, where can I get one?
The % goes down because serial passthrough is consuming time but does not subtract an adequate number of emulated CPU cycles to account for it.
Forgive me, but I don't really understand what this means. I'm not familiar with the internals of 86Box. Are you saying that the serial passthrough is taking too much time (for whatever reason) but other things are, incorrectly, not compensating for that?
I noticed I was not running the latest CP2102N driver. Just in case that had something to do with it, updated to version 11.4.0.393 (13/11/2024), but no change.