Bart wrote:Running two instances connected across different machines?
Running two instances on same machine, or on different machines.... same behaviour in all scenarios...

Machine #1: Ryzen 9 3950X / GeForce RTX 2070 / Win 10 - precompiled r803 version linked earlier in this thread. [Windows Firewall off for this test]
Machine #2: Ryzen 5 3600 / Radeon 550XT / Ubuntu 20.0.4 LTS. - built today from latest SVN sources...
Both machines are capable of simultaneously running 4 or more [non-networked] instances @ 60 fps @ 720p resolution, so it's not a CPU/GPU horsepower problem.
LAN connection is via 10GbE local network; both machines directly into a 10GbE switch via 1 meter DAC cables, so I don't think it's a networking problem..

When I try two networked instances [same machine or across network], the frame rate lowers to about 40 fps in the initial boot screens, and then drop to low 30s as the game proper starts [and stays in the low 30s, sometimes dropping to low 20s].
It's not stuttering/frame drops per se, the game is actually running twice [or 3x] as slowly; in Scud Race it's obvious during the "3...2...1" countdown at the start, and in the gameplay.... which is basically unplayable/in slo-mo.
And it's not the host machine CPU/GPU getting bogged down... I can run a third, non-networked instance at 60 fps at the same time on the same machine struggling with the two networked instances at 30 fps...
-----------------------------
BTW, wanted to say that I'm really in awe and gratitude for everything you guys have done on this over the years, and would love to help in any way I can. Being able to play Scud Race, arcade perfect at home, is a dream come true - because of your efforts - and networked multiplayer would be the icing on the cake...

I have a clean install of PopOS! 20.04 on the 3950x / RTX 2070 machine, so I'm going to build again from source on that machine and see if anything behaves differently, and I'll report back.
Also, I read Ian's comment above [July 14th] about the 16 ms delay, and see the line [#93] in TCReceive.cpp that "sleeps" the listener thread for 16 ms [not sure if they are related?]
Just to see what happened, and because it was quick, I changed that to 1ms [instead of 16ms] and recompiled, but it didn't seem to make any difference...