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

[Doug Semler]

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

>
"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.

Tag your function with [SuppressUnmanag edCodeSecurity] 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("kern el32.dll"), SuppressUnmanag edCodeSecurity]
[return: MarshalAs(Unman agedType.Bool)]
bool QueryPerformanc eCounter(out long count);

double requiredTimeToW aitInSeconds = 0.00001; // ten microseconds
QueryPerformanc eFrequency(&fre q);
QueryPerformanc eCounter(&start );
do
{
QueryPerformanc eCounter(&end);
if (((end.QuadPart - start.QuadPart) / (double)freq.Qu adPart) >
requiredTimeToW aitInSeconds)
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
QueryPerformanc eCounter internally): Something like:

Stopwatch s = Stopwatch.Start New();
while (s.ElapsedTicks / StopWatch.Frequ ency < requiredTimeToW aitInSeconds)
// 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]

"Doug Semler" <do********@gma il.comwrote in message
news:%2******** **********@TK2M SFTNGP02.phx.gb l...

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

>>
"Jon Slaughter" <Jo***********@ Hotmail.comwrot e in message
news:Pk******* ***********@new ssvr11.news.pro digy.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.

Tag your function with [SuppressUnmanag edCodeSecurity] 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("kern el32.dll"), SuppressUnmanag edCodeSecurity]
[return: MarshalAs(Unman agedType.Bool)]
bool QueryPerformanc eCounter(out long count);

double requiredTimeToW aitInSeconds = 0.00001; // ten microseconds
QueryPerformanc eFrequency(&fre q);
QueryPerformanc eCounter(&start );
do
{
QueryPerformanc eCounter(&end);
if (((end.QuadPart - start.QuadPart) / (double)freq.Qu adPart) >
requiredTimeToW aitInSeconds)
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
QueryPerformanc eCounter internally): Something like:

Stopwatch s = Stopwatch.Start New();
while (s.ElapsedTicks / StopWatch.Frequ ency < requiredTimeToW aitInSeconds)
// Fastest way to get elapsed time is ElapsedTicks
Threading.Sleep (0);

This seems like it cannot be any faster than calling PerformanceCoun ter
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]

On Sep 7, 12:52 am, "Jon Slaughter" <Jon_Slaugh...@ Hotmail.comwrot e:

"Doug Semler" <dougsem...@gma il.comwrote in message

>

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

Stopwatch s = Stopwatch.Start New();
while (s.ElapsedTicks / StopWatch.Frequ ency < requiredTimeToW aitInSeconds)
// Fastest way to get elapsed time is ElapsedTicks
Threading.Sleep (0);

This seems like it cannot be any faster than calling PerformanceCoun ter
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/hi...timercshar.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.

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

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

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

[Lit]

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

Lit
"Jon Slaughter" <Jo***********@ Hotmail.comwrot e in message
news:AN******** ********@nlpi06 8.nbdc.sbc.com. ..

>
"Doug Semler" <do********@gma il.comwrote in message
news:%2******** **********@TK2M SFTNGP02.phx.gb l...

>"Jon Slaughter" <Jo***********@ Hotmail.comwrot e in message
news:Eo******* ***********@new ssvr11.news.pro digy.net...

>>>
"Jon Slaughter" <Jo***********@ Hotmail.comwrot e in message
news:Pk****** ************@ne wssvr11.news.pr odigy.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.

Tag your function with [SuppressUnmanag edCodeSecurity] 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("kern el32.dll"), SuppressUnmanag edCodeSecurity]
[return: MarshalAs(Unman agedType.Bool)]
bool QueryPerformanc eCounter(out long count);

double requiredTimeToW aitInSeconds = 0.00001; // ten microseconds
QueryPerforman ceFrequency(&fr eq);
QueryPerforman ceCounter(&star t);
do
{
QueryPerformanc eCounter(&end);
if (((end.QuadPart - start.QuadPart) / (double)freq.Qu adPart) >
requiredTimeTo WaitInSeconds)
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 QueryPerformanc eCounter internally): Something like:

Stopwatch s = Stopwatch.Start New();
while (s.ElapsedTicks / StopWatch.Frequ ency <
requiredTimeTo WaitInSeconds) // Fastest way to get elapsed time is
ElapsedTicks
Threading.Sleep (0);

This seems like it cannot be any faster than calling PerformanceCoun ter
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]

"Doug Semler" <do********@gma il.comwrote in message
news:11******** **************@ 50g2000hsm.goog legroups.com...

On Sep 7, 12:52 am, "Jon Slaughter" <Jon_Slaugh...@ Hotmail.comwrot e:

>"Doug Semler" <dougsem...@gma il.comwrote in message

>>

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

Stopwatch s = Stopwatch.Start New();
while (s.ElapsedTicks / StopWatch.Frequ ency <
requiredTimeToW aitInSeconds)
// Fastest way to get elapsed time is ElapsedTicks
Threading.Sleep (0);

This seems like it cannot be any faster than calling PerformanceCoun ter
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

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]

"Chris Mullins [MVP]" <cm******@yahoo .comwrote in message
news:e2******** ******@TK2MSFTN GP02.phx.gbl...

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

[Jon Slaughter]

"Lit" <sq**********@h otmail.comwrote in message
news:eA******** *****@TK2MSFTNG P06.phx.gbl...

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

Lit

I'm not sure what you mean but essentially the counter function is suppose
to act sorta like a timer that has better than millisecond accuracy.

Essentially what I do is time how fast the thread is able to count. So if it
counts N in 3 seconds then obviously N/3 is the frequency at which the
thread is running and 3/N is how fast it was able to count up to that point.

The delayer part is to slow down the counter to get an adjustable frequency.

The issues are obviously that you are wasting cpu and that the counter isn't
very stable in some cases. But for my app its not all that serious because
I'll only be using the thread for very short periods of time.

Jon

[Ben Voigt [C++ MVP]]

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

Stopwatch s = Stopwatch.Start New();
while (s.ElapsedTicks / StopWatch.Frequ ency < requiredTimeToW aitInSeconds)

better:

long ticksToWait = StopWatch.Frequ ency * requiredTimeToW aitInSeconds;
while (s.ElapsedTicks < ticksToWait)

Never divide when you can multiply :)

// 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?