свой GetCount на rdtsc

[Ulex]

Хочу посчитать количество тактов процессора в 1 ms и далее на этой базе засекать временные интервалы в цикле. (Redrow)
Есть вот такой код:

.code
GetTimeConst	proc uses ebx edi esi
	LOCAL	IGTC_LOC:DWORD
	LOCAL	JGTC_LOC:DWORD
	LOCAL	KGTC_LOC:DWORD

	mov	[IGTC_LOC], 20
	mov	[JGTC_LOC], 20
GetTimeConst1:
	cmp	[JGTC_LOC], 0
	je	GetTimeConst_endZ
	rdtsc
	mov	[KGTC_LOC], eax
	invoke	Sleep, 8
	rdtsc
	sub	eax, [KGTC_LOC]
	shr	eax, 3
	add	[IGTC_LOC], eax
	dec	[JGTC_LOC]
	jmp	GetTimeConst1
GetTimeConst_endZ:
	xor	edx, edx
	mov	eax, [IGTC_LOC]
	mov	ecx, 20
	div	ecx
	ret
GetTimeConst	endp

GetStepTime	proc uses ebx edi esi, GLOBLOW_EXT:DWORD, GLOBHIGH_EXT:DWORD, \
		TAKTINMS_EXT:DWORD

	LOCAL	I_tempGST_LOC:DWORD
	
	mov	edx, [GLOBHIGH_EXT]
	mov	ebx, dword ptr [edx]
	mov	edx, [GLOBLOW_EXT]
	mov	ecx, dword ptr [edx]
	rdtsc
	sub	eax, ecx
	sbb	edx, ebx
	add	ecx, eax
	adc	ebx, edx
	mov	edx, [GLOBHIGH_EXT]
	mov	dword ptr [edx], ebx
	mov	edx, [GLOBLOW_EXT]
	mov	dword ptr [edx], ecx
	
	mov	[I_tempGST_LOC], eax
	fild	[I_tempGST_LOC]
	fidiv	[GLOBHIGH_EXT]
	fstp	[I_tempGST_LOC]
	mov	eax, [I_tempGST_LOC]

	ret
GetStepTime	endp

Две функции- первая вычисляет количество тактов за 1 ms, вторая - значение в
ms с последнего вызова GetStepTime (в формате float).
Всё вроде-бы здорово, но при работе в одном "бесконечном" цикле результаты
расходятся со значениями, полученными GetTickCount (сильно расходятся, раза в 1,5)


Цикл Redrow:

	invoke	GetStepTime, addr [TaktCntLOW], addr [TaktCntHIGH], [TaktInMS]
	mov	[I_temp_LOC], eax
	fld	[I_temp_LOC]
	fistp	[I_temp_LOC]
	invoke	zifra_to_screen, 300, 403, [I_temp_LOC], 10, 0	
	inc	[for_fps1]
	invoke	GetTickCount
	sub	eax, global_timer
	mov	[step_time], eax
	add	global_timer, eax

TaktInMS - значение, полученное функцией GetTimeConst
На экран вывожу значения [I_temp_LOC] и [step_time]. Вот собственно и не понимаю,
почему между ними такая большая разница и кому больше верить.

[rpy3uH]

т.е. проблема в том что значения расходятся?
в принципе не надо верить ни тому, ни тому! потому что когда ты вызываешь, к примеру Sleep(1000), то не факт что программа будет спать ровно 1 секунду, ведь в этот промежуток процессор может занять поток с высоким приоритетом и не отпускать его в течении 2-3 секунд. Поэтому в Windows, НЕЛЬЗЯ утверждать что прошла именно 1 секунда. Да и вообще любое измерение времени (вернее задержка) в Windows будет не точно, как и в любой системе с использованием планирования потоков с учётом приоритетов.

[Ulex]

Но, что характерно, значения полученные моим GetTimeConst достаточно стабильны для одного и того же процессора (к примеру у меня это примерно 3.500.000 тактов в мс, на полноценном двухядернике ~5.100.000 тактов). К тому же я там считаю среднее арифметическое из 20-ти измерений.

В архиве исходники и *.exe
сверху вниз:
первое значение - полученное моим GetTimeConst (типа кол-во тактов в мс)
второе значение - то, что возвращает rdtsc в eax
третье значение - то, что возвращает rdtsc в edx
четвёртое значение - засекаемое моим GetStepTime
пятое значение - засекаемое GetTickCount

[Ulex]

Вот всё-таки чем хорош ассемблер, виноват всегда САМ.
Нашёл ошибку в функции GetStepTime
fidiv [GLOBHIGH_EXT], а надо fidiv[TAKTINMS_EXT].
Сейчас получилось ~11.4 мс/кадр (колышется от 11.3 до 11.4), что примерно и соответствует 85 кадрам в секунду (хотя всё-таки чуть больше). Но зато гораздо стабильнее, нежели значение, получаемое от GetTickCount.

Если кому не лень, погоняйте пожалуйста вот этот вариант на разных частотах кадровой развёртки (обязательно со включенной принудительно вертикальной синхронизацией). То что посередине беленьким шрифтом рисуется - это период м/у кадрами (в мс), посчитанный моими функциями. Поидее, если поделить 1000 на это значение, то должна получиться частота вертикальной развёртки.
Если кто займётся, напишите мне пожалуйста - чего из этого получилось.
Заранее Спасибо.