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(synce d) 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]

On Sep 6, 3:46 pm, "Jon Slaughter" <Jon_Slaugh...@ Hotmail.comwrot e:

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 QueryPerformanc eCounter 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]

"Doug Semler" <do********@gma il.comwrote in message
news:11******** **************@ d55g2000hsg.goo glegroups.com.. .

On Sep 6, 3:46 pm, "Jon Slaughter" <Jon_Slaugh...@ Hotmail.comwrot e:

>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 QueryPerformanc eCounter 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

[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]

"Jon Slaughter" <Jo***********@ Hotmail.comwrot e in message
news:Pk******** **********@news svr11.news.prod igy.net...

>
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/is...solutionTimer/

--
Chris Mullins, MCSD.NET, MCPD:Enterprise , Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"Jon Slaughter" <Jo***********@ Hotmail.comwrot e in message
news:mG******** ********@newssv r22.news.prodig y.net...

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(synce d) to get the data to a C# app?

Thanks,
Jon

[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

--
Chris Mullins, MCSD.NET, MCPD:Enterprise , Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"Jon Slaughter" <Jo***********@ Hotmail.comwrot e in message
news:mG******** ********@newssv r22.news.prodig y.net...

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(synce d) to get the data to a C# app?

Thanks,
Jon

[Jon Slaughter]

Well guys, this is what I've done
static void counter()

{

long startCount = PerfCount.Query PerformanceCoun ter();

double elapsedSeconds = 0;

double QPF = (double)PerfCou nt.QueryPerform anceFrequency() ;

while (true)

{

clicks++;

// Delay x seconds

/*

startCount = PerfCount.Query PerformanceCoun ter();

do

{

Delayer(1);

elapsedSeconds = (PerfCount.Quer yPerformanceCou nter() - 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]

"Chris Mullins [MVP]" <cm******@yahoo .comwrote in message
news:eZ******** ********@TK2MSF TNGP05.phx.gbl. ..

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(atleas t I can move on to main part of the project).

Thanks,
Jon