Horrible title, so let me explain - I think this must be a very basic statistical problem, but I don't remember what little statistics I once knew.
I'm writing a low-level emulator of an old IBM CPU. Each machine instruction of the IBM1620 was accomplished by a sequence of various "machine cycles". On the original machine, each cycle took exactly 20 microseconds. I'm emulating the various cycles with subroutines; they are much faster than 20 microseconds, and they do not all take the same amount of time to execute.
The 1620 had a magnificent light console that constantly showed the state of over 100 internal bits (data, registers, control switches) as the machine ran. I'm emulating that, too. Unlike the 1620, I can't manage to update my Java GUI 50000 times per second, as repainting after every 20 microsecond "cycle" would require. But I get a fine visual approximation simply by repainting the GUI every N cycles. [We can assume that repainting the GUI takes constant time.]
Without repainting the GUI at all, the emulator runs much too fast; repainting after every cycle makes it run much too slow. The graphical repainting is the ideal "friction" to apply to the emulator, to get it to approximate the true speed of the machine. The question is, what is N?
I have probes to count cycles and sample the system clock. The problem is that, due to several factors, the most important of which is that my emulations of the various "cycles" do not take equal time, the number of cycles in a measurement interval can vary a good deal, depending on the nature of the instructions the CPU was carrying out at that time.
I'd like, over time, to be able to converge on a "good" value of N, using some sort of method that can somewhat overlook anomalous readings. "Good"? "Anomalous"? I don't know how to define them. But if anyone can give guidance, even along the lines of "oh! you should check the Wikipedia article for The Backwards Freight Train Problem" [I'm making that up, of course], I'd appreciate it.
EDIT: to illustrate the problem, I'm appending some measurements. Here are a series of measurement intervals, each lasting 10000 cycles, showing:
- interval time in microseconds (usecs),
- the number of cycles executed between redrawing the updated GUI (cycs/redraw=51), currently constant,
- the average GUI redraws per second (redraws/sec),
- the cycles per second, expressed as a percentage of a real IBM1620, which was always exactly 50000 cycles per second.
And the question is: how might one vary cycs/redraw to bring Rate closer to 100%? Especially given that, as is obvious below, emulated cycles vary in duration.
CPU: Interval: Cycles=10000; usecs=174595; cycs/redraw= 51; redraws/sec:1123. Rate:114% CPU: Interval: Cycles=10000; usecs=197842; cycs/redraw= 51; redraws/sec: 991. Rate:101% CPU: Interval: Cycles=10000; usecs=179968; cycs/redraw= 51; redraws/sec:1089. Rate:111% CPU: Interval: Cycles=10000; usecs=157880; cycs/redraw= 51; redraws/sec:1241. Rate:126% CPU: Interval: Cycles=10000; usecs=151724; cycs/redraw= 51; redraws/sec:1292. Rate:131% CPU: Interval: Cycles=10000; usecs=150892; cycs/redraw= 51; redraws/sec:1299. Rate:132% CPU: Interval: Cycles=10000; usecs=151908; cycs/redraw= 51; redraws/sec:1290. Rate:131% CPU: Interval: Cycles=10000; usecs=172101; cycs/redraw= 51; redraws/sec:1139. Rate:116% CPU: Interval: Cycles=10000; usecs=159090; cycs/redraw= 51; redraws/sec:1232. Rate:125% CPU: Interval: Cycles=10000; usecs=165604; cycs/redraw= 51; redraws/sec:1184. Rate:120% CPU: Interval: Cycles=10000; usecs=135410; cycs/redraw= 51; redraws/sec:1448. Rate:147% CPU: Interval: Cycles=10000; usecs=130933; cycs/redraw= 51; redraws/sec:1497. Rate:152%