By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,885 Members | 1,499 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,885 IT Pros & Developers. It's quick & easy.

High res timer

P: n/a
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
Sep 6 '07 #1
Share this Question
Share on Google+
19 Replies


P: n/a

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

Sep 6 '07 #2

P: n/a
On Sep 6, 3:46 pm, "Jon Slaughter" <Jon_Slaugh...@Hotmail.comwrote:
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.

Sep 6 '07 #3

P: n/a

"Doug Semler" <do********@gmail.comwrote in message
news:11**********************@d55g2000hsg.googlegr oups.com...
On Sep 6, 3:46 pm, "Jon Slaughter" <Jon_Slaugh...@Hotmail.comwrote:
>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.
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
Sep 6 '07 #4

P: n/a

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
Sep 6 '07 #5

P: n/a

"Jon Slaughter" <Jo***********@Hotmail.comwrote in message
news:Pk******************@newssvr11.news.prodigy.n et...
>
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.
Sep 6 '07 #6

P: n/a
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.comwrote in message
news:mG****************@newssvr22.news.prodigy.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(synced) to get the data to a C# app?

Thanks,
Jon

Sep 6 '07 #7

P: n/a
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.comwrote in message
news:mG****************@newssvr22.news.prodigy.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(synced) to get the data to a C# app?

Thanks,
Jon

Sep 6 '07 #8

P: n/a
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


Sep 7 '07 #9

P: n/a

"Chris Mullins [MVP]" <cm******@yahoo.comwrote in message
news:eZ****************@TK2MSFTNGP05.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(atleast I can move on to main part of the project).

Thanks,
Jon
Sep 7 '07 #10

P: n/a
"Jon Slaughter" <Jo***********@Hotmail.comwrote in message
news:Eo******************@newssvr11.news.prodigy.n et...
>
"Jon Slaughter" <Jo***********@Hotmail.comwrote in message
news:Pk******************@newssvr11.news.prodigy.n et...
>>
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);

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?

Sep 7 '07 #11

P: n/a

"Doug Semler" <do********@gmail.comwrote in message
news:%2******************@TK2MSFTNGP02.phx.gbl...
"Jon Slaughter" <Jo***********@Hotmail.comwrote in message
news:Eo******************@newssvr11.news.prodigy.n et...
>>
"Jon Slaughter" <Jo***********@Hotmail.comwrote in message
news:Pk******************@newssvr11.news.prodigy. 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 [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
Sep 7 '07 #12

P: n/a
On Sep 7, 12:52 am, "Jon Slaughter" <Jon_Slaugh...@Hotmail.comwrote:
"Doug Semler" <dougsem...@gmail.comwrote in message
>
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?
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

Sep 7 '07 #13

P: n/a
Jon,

this may also help to reach 1 ms resolution:

http://www.codeproject.com/csharp/hi...timercshar.asp

Best regards,
Janos

Sep 7 '07 #14

P: n/a
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.comwrote in message
news:VF****************@newssvr19.news.prodigy.net ...
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


Sep 7 '07 #15

P: n/a
Lit

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

Lit
"Jon Slaughter" <Jo***********@Hotmail.comwrote in message
news:AN****************@nlpi068.nbdc.sbc.com...
>
"Doug Semler" <do********@gmail.comwrote in message
news:%2******************@TK2MSFTNGP02.phx.gbl...
>"Jon Slaughter" <Jo***********@Hotmail.comwrote in message
news:Eo******************@newssvr11.news.prodigy. net...
>>>
"Jon Slaughter" <Jo***********@Hotmail.comwrote in message
news:Pk******************@newssvr11.news.prodigy .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 [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

Sep 7 '07 #16

P: n/a

"Doug Semler" <do********@gmail.comwrote in message
news:11**********************@50g2000hsm.googlegro ups.com...
On Sep 7, 12:52 am, "Jon Slaughter" <Jon_Slaugh...@Hotmail.comwrote:
>"Doug Semler" <dougsem...@gmail.comwrote in message
>>
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?

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
Sep 9 '07 #17

P: n/a

"Chris Mullins [MVP]" <cm******@yahoo.comwrote in message
news:e2**************@TK2MSFTNGP02.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
Sep 9 '07 #18

P: n/a

"Lit" <sq**********@hotmail.comwrote in message
news:eA*************@TK2MSFTNGP06.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
Sep 9 '07 #19

P: n/a
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)
better:

long ticksToWait = StopWatch.Frequency * requiredTimeToWaitInSeconds;
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?

Sep 10 '07 #20

This discussion thread is closed

Replies have been disabled for this discussion.