>>15
"auto" cycles only swaps between "max" and a single fixed value, and doesn't even do that reliably in all cases, which is why I recommend not to use it if you can help it. The default value of 3000 when it doesn't auto-swap to max is approximately a 286... maybe. From what I gather there's no reliable 1:1 conversion of cycles value to CPU speed, which sucks.

The general good procedure for speed-sensitive games is to determine what type of CPU (and, if need be, accessory hardware) the game was ideally run on and making a config that sets cycles, and perhaps some other settings (e.g. core, cputype, possibly graphics and sound card settings) accordingly. Outside of very finicky games you should be able to get away with making a few configs that represent different emulated computers rather than having to make a unique config for every game (though that can have its advantages like a specific startup .BAT script) Useful reading:
https://www.dosbox.com/wiki/Configuration:CPU

DOSBox-staging is supposed to have steadier/more accurate cycles but I haven't yet experimented with it enough to vouch for that. I'm pretty wary of forked builds in general since in my experience they've tended to be no better/actually worse, but I'm basing that opinion primarily on Daum and X.

Ultimately, it's a problem in the first place due to a combination of programmers targeting their programs to an exact system build (which made sense on early microcomputers that were built to a single standard and didn't have clones or upgraded versions) and the fact that DOS computers, unlike the aforementioned early microcomputers, generally weren't built to a single standard but had clones and alternate hardware setups all over the place. There's room for improvement, but expecting DOSBox to "just work" on the same level as, say, a NES emulator where it just has to emulate a small set of standardized hardware is rather wishful.