ijor wrote: 15 Dec 2022 19:35
It doesn't synchronize to VBL at all. It is actually not feasible to synchronize to both interrupts at the same time because they are asynchronous one from the other.
I will see if I can find the original emails where we was discussing it. I think he waited for the vbl and the next time a tick as the reference point but this is going back some years to don't exactly remember. I do remember during development it was tested both ways and did not seem to make any difference. I thought that code was left in place.
I don't think there is much to do. It might be possible to implement some very minor improvements in terms of accuracy. But again, a benchmarking tool needs to be flexible more than being 100% accurate. Or otherwise you might get compatibility problems.
I wasn't criticizing GB at all. I think it is a great tool. I was just elaborating about why occasionally you get a 1% score variation.
Indeed it I did not take that as a criticism. It just somewhat puzzled me over your comments. As sounded like you was referring to GB4, which does not make any attempt to sync or turn off interrupts IIRC.
So this looks like some of the original notes
@dml sent me. I know this is getting slightly off topic but anyway..
I cannot specifically find anything mentioning the VBL in relating to start time.. But might be the "sync-lock" which is mentioned. But so many emails over the years.. I don't know if
@dml Remember anything about it after all these years ? I know we spent a lot of time discussing ways to improve its accuracy.
sys_sleep replaces the TOS VBL (50hz display refresh) interrupt and the TimerC (200Hz timer) interrupt with a dummy one that simply returns immediately. This eliminates the cost of both of those interrupts - since they are not free and steal a few % CPU each, all the time. So turning them off gains you a few % CPU plus increased short-term timing stability.
However turning off these timers is probably not wise when running AES/VDI tests because those systems may actually wait on one or both timers in some areas of their code. If some VDI/AES benchmarks seem to freeze with sys_sleep in use, that'll be why. It was provided mainly for getting accurate times on low-level processes like RAM tests and integer/float calculations....
sys_acia_off disables the intelligent keyboard device, which listens for hardware mouse and keyboard events. It does this by writing commands to the IKBD processor via one of the two 6850 ACIAs. The commands are in small tables, and can be found in any book on the Atari ST covering IKBD functions.
sys_acia_off, sys_acia_reset, sys_acia_on are more or less identical functions but they write different data - there's one table for each of them.
When you use sys_acia_off, you must restore the system later with sys_acia_on (it may be best to issue a sys_acia_reset before turning back on but its probably not required). Failing to turn the IKBD back on with sys_acia_on means no more mouse or keyboard input until you power cycle the machine ;)
These functions were provided to stop accidental mouse movements from throwing benchmark timings out, by up to 5%.
Forgot to add, for the 'hardware' side of things:
sys_sleep only interacts with the CPU & MFP exception vectors, which are all stored at low addresses $8-$200 or thereabouts. These are also stored in normal ram - so I can't imagine writing them (as this function does) would fail at 16mhz, as its no different from writing any other RAM location.
It does not interact at all with the MFP's hardware register address space. So I can't see how it would lead to problems with the MFP itself. It continues doing what it was doing before - the only difference is the CPU responds by calling different code, when an MFP interrupt calls the TimerC/$114 interrupt vector.
The VBL interrupt vector ($70) isn't even managed by the MFP - it's a CPU autovector IIRC, so the signal goes direct from the shifter to the CPU. And its not disturbed by this function - it continues to do that, but the CPU calls a different interrupt routine in response.
sys_acia_off is a bit different - it's writing commands to the 6850 ACIA through its control/data ports - these are 8-bit memory-mapped ports in the hardware register address space $FFFF8C00, $FFFF8C02. Communication with this chip is slow and probably asynchronous - the device is fed by a 500KHz clock (IIRC?) which is divided off the system clock by the GLUE/MMU. So an overclocked machine might have issues talking to that chip reliably and the consequence would be unreliable or no keyboard/mouse function, even when reset/restored properly.
The 99% issue can still be rounding-related. Its more likely to happen on wobbly tests such as VDI,AES which is big and complex with unclear initial conditions. The asm tests are less likely to flake but still could, if rounding downwards without an offset.
> my_timer&=SPEEKL(&h4ba)
Yes this should *probably* be done in asm because it is time-critical -. If we can fix sys_tstart and sys_tstop to return the time properly, it should work ok. However I suspect rounding will be the main source of wobbly numbers.
You want to do the sync-lock before recording the start time, and before calling the test.
You don't want to do it after the test, as it would just add 0.005s guaranteed.
However regardless of this, it's not the only source of wobble or imprecision - rounding could be more of an issue overall.
This was basically using the assembly to start and stop the timer..
I do recommend though that if you decide to stick with the BASIC version, make sure you do the sync-lock (i.e. wait for counter to change) before recording the start time and calling the test. It makes the difference of up to 0.005 secs (1/200th sec).
Yes if you look at the ASM code right near the bottom sys_tstart - it reads the $4D2 timer/counter address and waits for it to change - then it saves the timer value and returns immediately. Same as you described in your email below.
The sys_tstop call just recovers the new $4D2 counter and subtracts the start counter, to get the delta - stuffs it in the params field, and returns. This is all done very quickly.
You can do this in BASIC and it will probably be ok - but there is some small delay involved. I can't guess what it is or whether it will affect you or not. I provided the ASM versions in case they improve precision but you can ignore if the BASIC version is fine and stable.
I don't quite understand your *5 correction calculation there but I can explain what I do in my own benchmark program to get accurate results. It should translate to BASIC without hassles. You just need the TimerC counter delta and a bit of arithmetic....
The *5 is "result&=SPEEKL(&h4ba)*5&" Though it does /1000 to get the seconds for GB6 results. I don't know if there is a better way of doing that calculation.
So basically this.. Where result& is reported from sys_tstop. FORMATS$ is just a function to format the seconds.
I don't know what effect the *5 would have on the overall accuracy of the calculation
Indeed if you have any suggestions for improvement for any of these loops then I can add that into GB7 and trial.
But getting slightly back onto topic I have been testing all day various things in GB6.
The overall trend seems to be with the blitter off, tests more than likely show 100%. But this could literally be because the tests take twice as long so the " margin for error" is significantly less.
With the Blitter ON (2.2k) the trend seems to be "justified text" test seems to be the most likely to hit 99%.
With the blitter ON (1K) the trend seems to be "text effects" Hitting 99% more often.
Probably meaningless information but as I spent all day testing this anyway :)
EDIT:
Found another email.
* if you're going to use the extra timing functions I suggest this pattern:
sys_sleep
sys_tstart
<test>
sys_tstop <- returns elapsed 200Hz ticks in the 'params' field i.e. where you passed the loopcount for the call
sys_wake
...and if you have any problems with sys_sleep/wake, just take them out and let me know. It should be fine for the ASM tests but you might have problems with lockups if you use them with the AES/VDI. mileage may vary!
* sys_tstart performs a synchronize with TimerC before starting the test. this involves an artificial delay (it waits until the counter changes once before proceeding to get a sync-lock), so don't use it if you're doing your own timing around it. Use sys_tstart/tstop OR use your own timer, not both together - or results will be skewed by a random short delay. One thing I'm not very sure about is the latency time for SUPEXEC() calls from BASIC, to start/stop the timer.... I'm assuming its negligible but if not, we can bake the timing calls around the tests directly and skip that whole issue.
* make sure you know how your BASIC language is rounding floating point / mixed numbers. usually they round downwards (to zero), not to nearest or to negative. (subtle difference between rounding to 0 and rounding to negative - the former rounds negative numbers upwards, the latter rounds them downwards! but in your case with +ve numbers you only care about round-to-nearest vs any other).
* Once you know for sure what rounding scheme you are using, you need to deal with the rounding of your %age timing before displaying results. e.g. with round-to-zero/-to-negative, the result 99.999999 will still round to 99% - which you don't want. So you need to add effective 0.5% before rounding this way (for no decimal places - a smaller offset is needed for more decimal places).
* IMO you're far better avoiding calculations using %age ranges completely and work with unit range displaced by digits needed e.g. 10000(.0) = 5 digits = 100.00%, which makes rounding safe & natural when you convert to percent for the final figure. This is far less confusing to work with than messing with percentages in calculations - not least because %age has potentially two different meanings when multiplied... easy to make mistakes with it. Moreso if you're trying to deal with rounding in the same calculations.
* IMO you need at least 2 hidden digits which are never shown, to allow rounding to work properly at all. So for a value of 100.00% represented, you'd best use a range of 100[00].00 in calculations (if you have floating point) or 100[00]00 (if you only have integers to work with). The final 2 digits help with rounding and are thrown away for the final result.
EDIT2:
VDI TEXT test results.
14.605 100% -2921 ticks
14.610 100% - 2922 ticks
14.615 99% - 2923 ticks
Added raw timer ticks out of interest.
Only thing I could think of really doing is just rounding the number up or down. So 2920-2925 becomes 2920. Thus anything over 2925 becomes 2930.