Hy all,
i got this thread cause i'm interested in other's thoughts about timing machine independent.
i have seen a few timing stuff in this board and i think we should discuss things like this in this thread.
the first most easiest way is to use divided clock ticks from memory address
[0:46ch] - this is $1234DD Hz / 65536 < divisor
this produces ticks with frequency approximately 18.20649712 Hz
now, if u use ports 43h and 40h you can use pit directly
it is a very accurate timare until the windos - the cute thing
makes something like task switching or displaying to screen - then you can have the most accurate timer, you can do nothing accurate with it,
ill describe this a little clearer: you will not have the priority to see if pit have changed i even tried looping cli with my code but on windows, no use.
(however this does completely halt the system
loop123:
cli
jmp loop123)
who have any ideas/snipplets about timing methods ( not using nops in a loop like as some in microcontrollers with same clock rate ), should post it here.
MATRIX

Linux's time utility serves me good for simple benchmarks.
RDTSC is good for profiling your code within the code (Pentium 1 and up)

But if you want brute time? Your code simply doesn't work on linux. Not machine independant at all. Best way IMO is to link with clib and use time.

Say, if you have an AT class machine like a PC X86 your system must have the PIT = that is an oscillator on your mother-board, like ist in my tiny soic micronontrollers
their purpose is timing, for example dram timing is controlled by pit
if your timer variable is not present in the memory then u probably can't use that 18.2 ... Hz timer variable, but it is divided by the PIT, so you can still use PIT directly via port 43h and 40h < this is PIT 1st, and you can divide your timeslice in your variable.

RTC = Real time clock can be used for timing too, your PC i think has a Real time clock, however its resolution is Fairly limited - fore some critical operations like as i used to do - there has to be a resolution of a micro sec. if it doesn't then you should buy a computer.

well on my computer - Celeron II the RDTSC is present and is generating approximately 927 million ticks per second ( was measured via pit timer under dos : accuracy was about 0.0 ... Hz )
the only problem with it is you must wait a few seconds at startup to determine ( under windows - try to determine ) the accurate clock speed to divide with.
MATRIX

I know what the timers are. But i never been able to access them directly from user mode of neither linux nor window.

I think the RTC has a resolution of 8192 Hz (might be after "initalization", it might be 1024 Hz at startup? (I'm not sure)).
Also there is something known as HPET, not sure of the spects, but I think it's got a higher resolution than RTC and the 'old' PIT

>But i never been able to access them directly from user mode of neither linux nor window.
in linux: I think you'll simply have to check the premissions and if the kernel has support compiled in for it, and then rtfm
in windows: no clue, maybe write a KDM?

#2
I have removed this code, cause'
it was freezing under dos, look at my attachments instead.

MATRIX

Messing with the PIT in anything but DOS (or your own kernel) is a bad idea. Or perhaps I should say BAD idea. If you're on DOS or your own OS, you could also look into the APIC timers, on recent systems.

[0:46ch] is only for DOS, btw - it's where the DOS timer IRQ stores the timer value, and not something dictated by the hardware. This means you cannot depend on reading this value from anywhere else.

If you're working under some operating system, you should use the timing facilities the OS has available.. if those aren't good enough, you're probably using the wrong OS.

You didn't read my code, it uses ports, not dos timer,
however the version i have posted works only on win95 98, i will later post a professional version that won't 'mess' with the pit, cause' i have tried it on dos, and it hanged.
this was due to the lack documentation of the pit ports, now i seem to be getting it.

however i have discovered that windows is doing something while i make a cli, it seems like it reprograms the pit with a rate of some seconds.
someone correct me if i'm wrong

on the other hand i think PIT is exactly for timing, if you know what you're doing you can use it, having a resolution of $1234dd Hz, where RTC has amax. of 8192 Hz ( although PIT is updated from RTC regularily to be accurate, cause' on some systems RTC can differ 1 whole seconds from the PIT maintained dos time on older machines after a 1 day period ! )

MATRIX

Sorry, I commented on the the first most easiest way is to use divided clock ticks from memory address
[0:46ch] part, not the code

I haven't looked at windows timer reprogramming, thought it was only NT that did it.. dunno why it would do it, but I guess it would make sense to keep interrupt generation low as long as high accuracy isn't needed?


...which generally excludes messing with it under protected mode operating systems - unless you really know what you're doing, and how it will affect drivers, the scheduler, ...

It's not that you shouldn't play around with this and use it, it's just that it sucks when end-user applications do things that can cause compatibility issues, especially when those things aren't really necessary.

Hy again,
here i am
here it is, professional version ( measurement and port handling ), tested and working ok

should work on dos, win9x
( little modifications and from boot sector )
i didn't have time for verifying the fractionals' displaying, but the frequency in Hz is accurate

in my example adjust cx to be the count of measurement for demonstration purposes, accuracy means measuremet time in 65536/$1234dd second units ( ticks )

ps.: under dos, it was nearly generating the same values with accuracy of 72 , so the laast 3 digits varied, i think its nice

MATRIX

Good job Matrix it works just fine!!!

Thanx,
i apprechiate feed backs

MATRIX