Yes, that would work, but ticks are also used when timesync is not active to show how much cycles dosbox executed. The number of cycles would ofcourse fall when cycles is set too high so you can get a feeling of overcycling even when timesync is not active. Perhaps rdtsc could be used instead of GetTicks() to speed things up...

Well it was more for how to locate the bottleneck

when tymesync is not used i'm not sure how much value you should have for that executed amount of cycles.

Here's a little Update on my activities. I've tried to write my own timesync variant, thereby finding out what the bottleneck could be - as Qbix already suspected, perhaps the frequent calling of GetTicks or something. After several tries, I've finally taken the approach to modify CPU_CycleMax only once every 16 seconds by at most 100 (up or down).

The funny thing is: even when using such a non-intrusive, gradual adaption, the number of missed ticks (as measured by my little patch) stays above 2%, no matter how low the cycles get - this is also audible (sound dropouts). using a fixed setting of 5000 cycles, I get <1% missed ticks, and sound is noticeably better (though not perfect, 5000 is the upper limit on my machine)

I get the impression that programs with their own timing loop (in this case it was the Frontier: First Encounters intro) don't like machines changing their speed. Some kind of feedback loop of the two timing mechanisms or something.

P.S.: As I also found out, updating the titlebar text is horribly slow - don't do that.

I did some tests, by changing the getTicks() call to be there only when timesync is enabled (I also disabled the cycles=0 statement, so both modes were actually "not-timesynced"). The difference in cpu usage was 1-2% at best (Athlon 2200+). But then again, gaining those few % is what this thread is all about, and loosing them for some useless statistics is...well, rather dumb 😁. I don't think updating the title bar once or twice a sec should be a problem...it should even be disabled in fullscreen.
As for the timesync mode itself, yes I did observe something similar as `Moe`. To get maximum performance out, it is best to run in normal mode, with cycles right below maximum (here is where showing the real cycles number in the titlebar should help finding that optimal point, at least I find it useful a lot). But for the games which require much less cpu (or perhaps a part of the game requiring less cpu - my previous tie fighter example), timesync mode is much more convenient.

Hehe, see that's the point. As you may or may not know, I'm running dosbox on a 333MHz P-II 😎 so my machine is always maxed out. If I have spare cycles, I lower frameskip (at 10 most of the time) or increase sound quality (11025kHz usually).

So, here is what I use to measure performance:

In file src/hardware/pic.cpp, after

1void TIMER_AddTick(void) {
2        /* Setup new amount of cycles for PIC */
3        PIC_Ticks++;

add these lines:

1        if ((PIC_Ticks&0x3fff) == 0) {
2                static unsigned long PIC_benchstart = 0;
3                static unsigned long PIC_tickstart = 0;
4                unsigned long ticks = GetTicks();
5                int delta = (PIC_Ticks-PIC_tickstart)*10000/(ticks-PIC_benchstart)+5;
6                LOG_MSG("DOSBox Time: %d.%d of real time",delta/100,(delta/10)%10);
7                PIC_benchstart = ticks;
8                PIC_tickstart = PIC_Ticks;
9        }

It shows the percentage at which the dosbox internal clock runs, compared to real time. (99.9 means dosbox is 0.1% slower than real time, or lost 1 out of 1000 timer ticks; DOS programs saw 999 ticks while the host OS saw 1000). To get a decent average (important!), it is only calculated/printed about every 16 seconds. My experience shows that all is well when dosbox runs at 99.0% or above. Losing more means slower emulation and stuttering sound. It seems to be impossible to get 100% (continuously).

To help finding the optimum number of cycles, after all these tests and ideas, I suggest the following:

Implement some way of measuring dosbox efficiency, but with more averaging and sending the output somewhere not so obvious, like stderr. This way, people are not bothered by the numbers when playing - usually you need the stats only when creating a dosbox.conf for a new game.

Maybe there could be a way to turn that particular cycling display on and off.
Which would require a lot of recoding of the titlebar display methods I bet.
Like a hide on/off switch but it switches between a normal titlebar and the Cycling titlebar.

Yes, I thought of that already. I think dosbox should have some kind of a performance monitor. I for example run a cpu usage monitor in the systray all the time, but I believe most of the users don't. And if you're new to dosbox it's kinda hard to tell if it's under or overcycled. I also don't believe in 1 conf for each game - it should be more like 1 conf for every game, with some tweaks changed at runtime. Timesync mode comes quite close to this, if you have the cpu power for some additional overhead...A cycle monitor also helps to find best (fastest) display mode without monitoring cpu usage every step. Also, I wouldn't want to fill stderr with statistics, as I've said, an infrequent titlebar change shouldn't be a performance problem...

It is. Machines running at their limit are very sensitive to seldom used code paths. A titlebar change is horrible, as it activates two new processes (x-server and window manager). Each time the title bar text changes, sound has dropouts.

I noticed that as well under linux.
if I would correct the changes 20 times a second the updating of the title bar would take half the processing power.

hmmm...now, I'd say that's more a linux problem 😁 (don't get me wrong, linux is a fantastic piece of software...but I don't feel it's quite there yet for desktop use). Measuring with rdtsc updating titlebar in windows xp takes about 2.2M clock cycles. Doing that once per sec is a little over 0.1% on a 2GHz machine. Doing it 20 times a sec is still only 2.5% of processing power...

Indeed, this may well be a linux-specific issue. This is by design, however, as the system separates applications and the window manager. The question why this is so is beyond the topic of this thread, but this behaviour probably won't change in the future, which means the title bar is not an adequate place for frequently changing information.

Three words: On Screen Display 😁