DISKIO uses a TIMER in order to track the duration of various data xfer events.
More specifically, provisions were made in the old code to account for an incorrectly working high-resolution timer on SMP machines.
Subsequently right at the start of DISKIO a call is made to determine which TIMER should be used by examining the CPU core count, and if >1 than we force the use of "standard MS counter":
Original Code
// init flHiresTmr flag
// note: DosTmrQueryTime() API not works on OS/2 SMP as designed (thanks scott),
// so on SMP systems we must use other timer - standart MS counter.
void init_timer (void)
{
int nCPUs = 0;
if (DosQuerySysInfo (QSV_NUMPROCESSORS,
QSV_NUMPROCESSORS,
&nCPUs,
sizeof(nCPUs)) == NO_ERROR)
{
if (nCPUs > 1) flHiresTmr = 0;
}
}
My udpated code
// init flHiresTmr flag
// note: DosTmrQueryTime() API does not work on OS/2 SMP as designed (thanks scott),
// so on SMP systems we must use other timer - standart MS counter.
void init_timer (void)
{
//int iCPUs = 0; //moved this to a GLOBAL variable in diskio.h, v1.26
if (DosQuerySysInfo (QSV_NUMPROCESSORS, /* ordinal of first system variable */
QSV_NUMPROCESSORS, /* ordinal of the last system variable */
&iCPUs, /* address of output data buffer */
sizeof(iCPUs)) /* size of output data buffer */
== NO_ERROR)
{
if (iCPUs > 1)
flHiresTmr = 1;
}
#ifdef DEBUG
printf("\n DEBUG => CPU cores detected is: %d\n", iCPUs);
printf(" DEBUG => flHiresTmr is: %d\n", flHiresTmr);
#endif /* DEBUG */
} // end of init_timer
...where I basically ignore that original comment and force flHiresTmr = 1, which also means that throughout DISKIO's execution I will always use the hi-res TIMER, that being through DosTmrQueryTime API.
OK, so when I had initially encountered this I thought to myself: umm, I recall we had some troubles in the past with the hi-res stuff being spotty. Firefox had encountered some of this, heck we even made use of the 'SET NSPR_OS2_NO_HIRES_TIMER=1' flag. But digging into this further, by all accounts today that no longer appears to be the case. My FF install no longer uses this, I have several other apps that use the hi-res TIMER, and I believe some work was done in the ACPI codebase to manage this better, although some opinions remainder for a while as to whether these changes were working or not.
Needless to say, my testing here appears to be showing correct results as the results match what the original DISKO logic was showing.
Here is a more specific example of code (API comments have been added by me, as well as some variable name changes) that relies on previous determination of what TIMER should be used:
// use MS counter timer for SMP systems and HiRes Timer for any other
int start_timer (TIMER *tStart)
{
if (flHiresTmr)
{
if (DosTmrQueryTime (tStart) != NO_ERROR)
{
printf("Timer error.\n");
return (-1);
}
}
else
{
tStart->ulHi = 0;
if (DosQuerySysInfo (QSV_MS_COUNT, /* ordinal of first system variable */
QSV_MS_COUNT,/* ordinal of the last system variable */
tStart, /* address of output data buffer */
sizeof(tStart)) /* size of output data buffer */
!= NO_ERROR)
{
printf("Timer error.\n");
return (-1);
}
}
return (0);
} // end of start_timer
My question to you all is: should we be still concerned about this?
I feel like simplifying the codebase is a good pursuit and if the hi-res TIMER works (which I understand to be the more precise one given that at the standard frequency the PIT chip runs at (roughly) 1.193182 MHz, so that gives us a microsecond precision as opposed to the ms stuff that DosQuerySysInfo is capable of), we should use it.