High res timer

[Jon Slaughter]

Is it possible to have a synchronous thread... actually a timer that is
beyond the 1khz/1ms resolution that .NET offers?

I want to poll the parallel port at rates beyond 1khz... about 10 to 100
times that rate if possible.

Essnetially I want to monitor the parallel port for data and display it but
I need a fast but somewhat precise way of knowing the sample rate.

Doing some tests on just a simple thread I can get speeds at around 150mhz
or so with a normal priority System.Thread. I figure that since I just need
about 1/1000 of that it shouldn't be that big a deal.

Is this possible in C#.NET? If not, is it possible to write a simple driver
in unmanaged C++ that either polls the port or hooks onto an
interrupt(synced) to get the data to a C# app?

Thanks,
Jon

 

[Jon Slaughter]

To be honest, I guess I really need a high res timer becaues I also want to
send data. The data doesn't have to be syncronized though as the pc will be
a "master". Although I will need to send the data to the port in a timely
fashion at some configurable rate from 1khz to 100khz(the faster the
better). (jitter is not a huge concern though)

I figure that if I time a thread that, say, runs at 150mhz, I can setup a
delay to lock in on a specific rate. But in this case I'm wasting a lot of
cycles delaying the thread. If I had a Thread.Sleep that was more accurate
than 1ms then it would be a piece of cake. (I understand that theres a lot
of task switching invovled and stuff but I'm not looking for the optimal
method but something that works and doesn't bring the system to a screaching
halt).

 

[Doug Semler]

To be honest, I guess I really need a high res timer becaues I also want to
send data. The data doesn't have to be syncronized though as the pc will be
a "master". Although I will need to send the data to the port in a timely
fashion at some configurable rate from 1khz to 100khz(the faster the
better). (jitter is not a huge concern though)

I figure that if I time a thread that, say, runs at 150mhz, I can setup a
delay to lock in on a specific rate. But in this case I'm wasting a lot of
cycles delaying the thread. If I had a Thread.Sleep that was more accurate
than 1ms then it would be a piece of cake. (I understand that theres a lot
of task switching invovled and stuff but I'm not looking for the optimal
method but something that works and doesn't bring the system to a screaching
halt).

First off, the windows timer has a resolution of something like 15-45
ms (depending on the OS). Sleep(1) can last 15 ms. That's just the
way it is.

You could potentially use QueryPerformanceCounter in some sort of spin
loop to get the resolution you want (i.e. call it multiple times and
break out of the loop when you find that you've gone beyond the time
span). Problem is you have to give up timeslices back to the OS to
keep your spin loop from grabbing all the cycles. Issue is the same
as above, sleep(0) can give up more than just the time slice to the
OS. I think there is also a Multimedia counter somewhere but IIRC,
the resolution is only 1 ms

You really should consider allowing the port to signal you when you
receive data rather than polling the port to see if there is data.

 

[Jon Slaughter]

First off, the windows timer has a resolution of something like 15-45
ms (depending on the OS). Sleep(1) can last 15 ms. That's just the
way it is.

You could potentially use QueryPerformanceCounter in some sort of spin
loop to get the resolution you want (i.e. call it multiple times and
break out of the loop when you find that you've gone beyond the time
span). Problem is you have to give up timeslices back to the OS to
keep your spin loop from grabbing all the cycles. Issue is the same
as above, sleep(0) can give up more than just the time slice to the
OS. I think there is also a Multimedia counter somewhere but IIRC,
the resolution is only 1 ms

You really should consider allowing the port to signal you when you
receive data rather than polling the port to see if there is data.

And how would I do this? It would require an interrupt or polling. In each
case there are issues.

Now the interrupt method might be the best if there is no way to do high
resolution polling but does require an external clock and some way to hook
the interrupt for the port. Unfortunately then its very difficult to vary
the clock speed(I suppose its not all that difficult but does require much
more hardware than it should) and requires the use of one of the pins.

Surely what I want to do is not impossible. After all, its done all the time
such as with USB, ethernet, RS-232, parallel port, etc... Its quite simple
to do in DOS but I'd rather do it in windows and use .NET.

The reason I think polling is the easiest is that its very simple to do. The
main issue is that if I use Sleep(1) then I get something like a 250hz rate
and if I don't then its up to 150mhz. Seems kinda moronic that I can get
anything inbetween.

Jon

 

[Doug Semler]

And how would I do this? It would require an interrupt or polling. In each
case there are issues.

Ya, and it's up to you to decide which one to use. The way I see it,
you can:
1) Write a device driver that talks to the port hardware directly
and provides methods for the application. Read data would be handled
by interrupt whenever a character is ready and write data would drive
the busy line low and strobe the characters out the port...
2) Poll the port at sleep(1) speed. Depending on the OS, you can
see anywhere from 25 to 100 Hz
3) Use a spin loop to get faster polls. You'll still have to
sleep(0) to give up the time slice, and that still has "hiccups" in it
(your time slice may be 15 ms long).

Now the interrupt method might be the best if there is no way to do high
resolution polling but does require an external clock and some way to hook
the interrupt for the port. Unfortunately then its very difficult to vary
the clock speed(I suppose its not all that difficult but does require much
more hardware than it should) and requires the use of one of the pins.

Well since I don't know exactly what you are doing with the port I
couldn't tell ya. I was referring to a kernel mode driver that sat on
top of the parallel driver to actually talk back and forth with the
port. You (IIRC) can then hook into the interrupt that is provided by
the parallel driver, i thought...

Surely what I want to do is not impossible. After all, its done all the time
such as with USB, ethernet, RS-232, parallel port, etc... Its quite simple
to do in DOS but I'd rather do it in windows and use .NET.

Yup. They use interrupts to inform the OS when there is data to be
read. in the case of RS232, the OS driver puts the data into a buffer
which can be read using a file handle. I haven't done parallel port

The reason I think polling is the easiest is that its very simple to do. The
main issue is that if I use Sleep(1) then I get something like a 250hz rate
and if I don't then its up to 150mhz. Seems kinda moronic that I can get
anything inbetween.

You're on a prememptive multitasking OS....them's the breaks <g>

 

[Jon Slaughter]

Ya, and it's up to you to decide which one to use. The way I see it,
you can:
1) Write a device driver that talks to the port hardware directly
and provides methods for the application. Read data would be handled
by interrupt whenever a character is ready and write data would drive
the busy line low and strobe the characters out the port...
2) Poll the port at sleep(1) speed. Depending on the OS, you can
see anywhere from 25 to 100 Hz
3) Use a spin loop to get faster polls. You'll still have to
sleep(0) to give up the time slice, and that still has "hiccups" in it
(your time slice may be 15 ms long).

Right now I'm using a kernal mode driver that simulates out and in to send
and recieve the port values. I'm not sure if I can modify it to hook an
interrupt. (Not really sure how windows works at that low of a level)

Can you explain what a spin loop is?

Well since I don't know exactly what you are doing with the port I
couldn't tell ya. I was referring to a kernel mode driver that sat on
top of the parallel driver to actually talk back and forth with the
port. You (IIRC) can then hook into the interrupt that is provided by
the parallel driver, i thought...

The main thing I'm trying to do is just monitor and transmitt information on
the parallel port. Its very simple. Now in actuallity I'll be doing
synchronous communications and the pc will be a master that always controlls
the clock so I do not have to worry to much about speed in this specific
case. But in general I want to be able to monitor it and transmit at a
specific rate because to fast and the external device attached to the port
might not be able handle it and to slow could end up taking for ever to send
data.

Yup. They use interrupts to inform the OS when there is data to be
read. in the case of RS232, the OS driver puts the data into a buffer
which can be read using a file handle. I haven't done parallel port
work in years, since they are rather obsolete <g>

Well, they are obsolete but just what I need Technically I could use the
serial port for my specific application but I want something that I can use
in the future for other things.

You're on a prememptive multitasking OS....them's the breaks <g>

Yes, but even then I think theres gotta be something inbetween. We know that
the pc has a timer that can be configured for us timing and which triggers
and interrupt. I'm sure with task switching that it could eat of a
significant portion of the cpu but hell, I've got 2000mhz to spare. I also
won't be doing anything complex in the interrupt except copying data from
the port to a buffer... just a few cycles... So there should be plenty of
cpu left for other processes.

Jon

 

[Jon Slaughter]

What I did was made an unmanaged C++ function that is a simple delay using n
nops. I figure I can profile some test code and get an average speed and
then use as a timer. I suppose it might work good enough.... or atleast
until I find a better method

Thanks,
Jon

 

[Jon Slaughter]

What I did was made an unmanaged C++ function that is a simple delay using
n nops. I figure I can profile some test code and get an average speed and
then use as a timer. I suppose it might work good enough.... or atleast
until I find a better method

Thanks,
Jon

Now I'm limited to about 100khz max. Just the act of inserting the a dll
call has made it 1000 times slower. I suppose this has something to do with
going from managed to unmanaged code. In any case I think it will be ok for
now.

 

[Chris Mullins [MVP]]

There are a number of high resolution timers you can play with. The magic
barrier seems to be in the 1ms range though, which may not be good enough
for you.

This article looked as if it would be a good starting point:
http://msdn.microsoft.com/msdnmag/issues/04/03/HighResolutionTimer/

 

[Chris Mullins [MVP]]

This MSDN article also seems to show a decent example in Managed Code:

http://msdn2.microsoft.com/en-us/library/aa964692.aspx

 

[Jon Slaughter]

Well guys, this is what I've done


static void counter()

{

long startCount = PerfCount.QueryPerformanceCounter();

double elapsedSeconds = 0;

double QPF = (double)PerfCount.QueryPerformanceFrequency();

while (true)

{

clicks++;

// Delay x seconds

/*

startCount = PerfCount.QueryPerformanceCounter();

do

{

Delayer(1);

elapsedSeconds = (PerfCount.QueryPerformanceCounter() - startCount)/QPF;

} while (elapsedSeconds < 0.0000001);

*/

Delayer(100000);

}

}

}



I have another thread that gathers how many clicks past

Starting Thread Profiling...
18436 clicks, 9.205 khz
36567 clicks, 9.129 khz
54224 clicks, 9.024 khz
71853 clicks, 8.969 khz
89471 clicks, 8.934 khz
106669 clicks, 8.876 khz
124794 clicks, 8.901 khz
142910 clicks, 8.919 khz
161026 clicks, 8.933 khz
179568 clicks, 8.943 khz
Total Time: 20.0789 secs, Average Freq: 8.983 khz, Std Dev: 0.1 khz
Standard Jitter: 1.119%
Press any key to continue . . .



using a Delayer(0) (1 nop) gives



Starting Thread Profiling...
20622424 clicks, 10.297 mhz
40389803 clicks, 10.083 mhz
57608071 clicks, 9.588 mhz
75853991 clicks, 9.468 mhz
95928456 clicks, 9.579 mhz
116091324 clicks, 9.66 mhz
136231241 clicks, 9.717 mhz
156395445 clicks, 9.761 mhz
176444567 clicks, 9.788 mhz
196572318 clicks, 9.81 mhz
Total Time: 20.0388 secs, Average Freq: 9.775 mhz, Std Dev: 0.235 mhz
Standard Jitter: 2.405%
Press any key to continue . . .


I can control the freq from 0 to around 10mhz on my machine with usually
about 1-2% standard jitter. It always executes faster at the start for some
reason(I guess the GC starts to get in the way or something else?).



In any case, it does seem to give me the ability to control the transmission
rate even though I'm wasting a lot of cycles I think it will work for now.
Of course it doesn't help that much with monitoring the port but maybe I can
work something out.



Thanks,

Jon

 

[Jon Slaughter]

There are a number of high resolution timers you can play with. The magic
barrier seems to be in the 1ms range though, which may not be good enough
for you.

Well, The high performance timers can get us resolution but the main issue
is that I have to end up wasting cycles if I want a better delay and I have
to content with a somewhat large amount of jitter(which I do not think will
be a huge issue for the most part).

I guess I don't have much of a choice with windows though. I'm sure it can
be done using low level drivers but at this point I think I've found my
solution(atleast I can move on to main part of the project).

Thanks,
Jon

 

[Doug Semler]

Now I'm limited to about 100khz max. Just the act of inserting the a dll
call has made it 1000 times slower. I suppose this has something to do
with going from managed to unmanaged code. In any case I think it will be
ok for now.

Tag your function with [SuppressUnmanagedCodeSecurity] in the p/invoke
declaration if you haven't already done so...

whan I'm talking about a spin loop I mean something like (now, don't forget
the overhead of actually making the function calls and doing the math <g>):
(you can dllimport the functions to C# too, declare the function as
[DllImport("kernel32.dll"), SuppressUnmanagedCodeSecurity]
[return: MarshalAs(UnmanagedType.Bool)]
bool QueryPerformanceCounter(out long count);

double requiredTimeToWaitInSeconds = 0.00001; // ten microseconds
QueryPerformanceFrequency(&freq);
QueryPerformanceCounter(&start);
do
{
QueryPerformanceCounter(&end);
if (((end.QuadPart - start.QuadPart) / (double)freq.QuadPart) >
requiredTimeToWaitInSeconds)
break;
Sleep(0); // Give up time slice
} while(true);

In fact, I'm wondering if you can't use the new StopWatch class which uses
QueryPerformanceCounter internally): Something like:

Stopwatch s = Stopwatch.StartNew();
while (s.ElapsedTicks / StopWatch.Frequency < requiredTimeToWaitInSeconds)
// Fastest way to get elapsed time is ElapsedTicks
Threading.Sleep(0);

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

 

[Jon Slaughter]

Now I'm limited to about 100khz max. Just the act of inserting the a dll
call has made it 1000 times slower. I suppose this has something to do
with going from managed to unmanaged code. In any case I think it will be
ok for now.

Tag your function with [SuppressUnmanagedCodeSecurity] in the p/invoke
declaration if you haven't already done so...

whan I'm talking about a spin loop I mean something like (now, don't
forget the overhead of actually making the function calls and doing the
math <g>):
(you can dllimport the functions to C# too, declare the function as
[DllImport("kernel32.dll"), SuppressUnmanagedCodeSecurity]
[return: MarshalAs(UnmanagedType.Bool)]
bool QueryPerformanceCounter(out long count);

double requiredTimeToWaitInSeconds = 0.00001; // ten microseconds
QueryPerformanceFrequency(&freq);
QueryPerformanceCounter(&start);
do
{
QueryPerformanceCounter(&end);
if (((end.QuadPart - start.QuadPart) / (double)freq.QuadPart) >
requiredTimeToWaitInSeconds)
break;
Sleep(0); // Give up time slice
} while(true);

Yes, this was essentially what I was doing... I didn't know it was called as
spinloop. I also found out that System.Threads has a Thread.SpinWait(n)
which, I suppose, does exactly what my delay does but seems to do it a
little more efficiently(I a better spread with it atleast).

If I understand correctly though then the SpinWait will not be interrupted
and not only burn cycles but prevent other threads from running? I guess
this won't be a problem except if I use it for very large times.

In reality I think any of these methods will work because I will not be
using the thread all that often; just to send commands back and form to the
device on the parallel port. In this case I can just sleep after a few
commands are send and so will only be spin looping for a fraction of a ms.

The main issue is if the thread gets interrupted in the middle of a command
by a process that takes very long.

In fact, I'm wondering if you can't use the new StopWatch class which uses
QueryPerformanceCounter internally): Something like:

Stopwatch s = Stopwatch.StartNew();
while (s.ElapsedTicks / StopWatch.Frequency < requiredTimeToWaitInSeconds)
// Fastest way to get elapsed time is ElapsedTicks
Threading.Sleep(0);

This seems like it cannot be any faster than calling PerformanceCounter
directly?

I'm going to go ahead and use Thread.SpinWait, unless I find some reasons
not too, and see what happens. I think everything will be ok.

Thanks,
Jon

 

[Doug Semler]

This seems like it cannot be any faster than calling PerformanceCounter
directly?

No. It's not. But it's cleaner to look at. The stopwatch loop is
(almost) functionally equivilent to the direct performance counter
loop I gave you

I'm going to go ahead and use Thread.SpinWait, unless I find some reasons
not too, and see what happens. I think everything will be ok.

Warning: SpinWait timings depend on the frequency of the processor...
(i believe spinwait does something very similar to:

for (int i = 1; i < n; i++)
nop

 

[Janos]

Jon,

this may also help to reach 1 ms resolution:

http://www.codeproject.com/csharp/highperformancetimercshar.asp

Best regards,
Janos

 

[Chris Mullins [MVP]]

You might want to replace your "clicks++" with a Thread.SpinWait.

Joe Duffy has a number of articles on this that all show up in Google.

 

[Lit]

Just wondering does the counters acts as a Timer Interrupt ( old assembly )?

Lit

What I did was made an unmanaged C++ function that is a simple delay
using n nops. I figure I can profile some test code and get an average
speed and then use as a timer. I suppose it might work good enough....
or atleast until I find a better method

Thanks,
Jon

Now I'm limited to about 100khz max. Just the act of inserting the a dll
call has made it 1000 times slower. I suppose this has something to do
with going from managed to unmanaged code. In any case I think it will
be ok for now.

Tag your function with [SuppressUnmanagedCodeSecurity] in the p/invoke
declaration if you haven't already done so...

whan I'm talking about a spin loop I mean something like (now, don't
forget the overhead of actually making the function calls and doing the
math <g>):
(you can dllimport the functions to C# too, declare the function as
[DllImport("kernel32.dll"), SuppressUnmanagedCodeSecurity]
[return: MarshalAs(UnmanagedType.Bool)]
bool QueryPerformanceCounter(out long count);

double requiredTimeToWaitInSeconds = 0.00001; // ten microseconds
QueryPerformanceFrequency(&freq);
QueryPerformanceCounter(&start);
do
{
QueryPerformanceCounter(&end);
if (((end.QuadPart - start.QuadPart) / (double)freq.QuadPart) >
requiredTimeToWaitInSeconds)
break;
Sleep(0); // Give up time slice
} while(true);

Yes, this was essentially what I was doing... I didn't know it was called
as spinloop. I also found out that System.Threads has a Thread.SpinWait(n)
which, I suppose, does exactly what my delay does but seems to do it a
little more efficiently(I a better spread with it atleast).

If I understand correctly though then the SpinWait will not be interrupted
and not only burn cycles but prevent other threads from running? I guess
this won't be a problem except if I use it for very large times.

In reality I think any of these methods will work because I will not be
using the thread all that often; just to send commands back and form to
the device on the parallel port. In this case I can just sleep after a
few commands are send and so will only be spin looping for a fraction of a
ms.

The main issue is if the thread gets interrupted in the middle of a
command by a process that takes very long.

In fact, I'm wondering if you can't use the new StopWatch class which
uses QueryPerformanceCounter internally): Something like:

Stopwatch s = Stopwatch.StartNew();
while (s.ElapsedTicks / StopWatch.Frequency <
requiredTimeToWaitInSeconds) // Fastest way to get elapsed time is
ElapsedTicks
Threading.Sleep(0);

This seems like it cannot be any faster than calling PerformanceCounter
directly?

I'm going to go ahead and use Thread.SpinWait, unless I find some reasons
not too, and see what happens. I think everything will be ok.

Thanks,
Jon

 

[Jon Slaughter]

No. It's not. But it's cleaner to look at. The stopwatch loop is
(almost) functionally equivilent to the direct performance counter
loop I gave you


Warning: SpinWait timings depend on the frequency of the processor...
(i believe spinwait does something very similar to:

for (int i = 1; i < n; i++)
nop

Well, thats what my delayer is... I'm computing the freqencies and I'll
either use that to base how much to delay or use some adapative algorithm(if
it works well).

Thanks,
Jon

 

[Jon Slaughter]

You might want to replace your "clicks++" with a Thread.SpinWait.

Joe Duffy has a number of articles on this that all show up in Google.

clicks++ is there to count how fast the thread is operating. The delayer or
SpinWait is there to control the frequency at which the clicks happen. So
both are needed... See my latest thread for issues with SpinWait(I like it
but causing a problem stopping the thread).

Thanks,
Jon