 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Timing Pitfalls and Solutions |
|
 |
RamboBones Member since: 9/23/2002 From: Blacktown, Australia |
|||
 Posted - 4/17/2004 2:11:13 AM |
||||
| A very interesting article. I don't see why you need so accurate a time source with absoulately no drfit from system time, but then again I didn't actually look at the link to the project you were working on. Overall however a good technical article on timers and very interesting to read  |
||||
|
||||
|
Jan Wassenberg Member since: 9/16/2002 From: Karlsruhe, Germany |
|||
 Posted - 4/17/2004 1:14:33 PM |
||||
| Thank you. The main purpose of the accuracy and precision requirements was synchronizing several machines for multiplayer mode. It's no longer necessary, but I figured it couldn't be that hard. Indeed, until my dying hard drive messed up measurements, the PLL worked very well. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 5/4/2004 7:06:56 PM |
||||
| Jan: I really enjoyed the article. It leaves me with a few questions: a friend of mine is co developing a system with me, and hes using an athlon 64 bit processor. for some reason, the code we use to determine frame rates provides drastically different results for him then it does for me. I'm running an Athlon 2400 and hes running a much better video card then I am with a lot more memory, yet hes seeing frame rates 2-3 times slower than what I'm seeing...It leads me to believe that rthe timing code is the culprit, especially since neither of us are experiencing poor preformance from our system. We use QPC exclusively, and we both run windows xp. Do you know of any issues with QPC on athlon 64, or of any other timing issues that might cause this? would we be better off using a tsc, and if so, where can I find a good example or good documents on writing one that describes step by step what needs to be done? Any info you could provide would be most appreciated! thank you! neko |
||||
|
||||
|
Jan Wassenberg Member since: 9/16/2002 From: Karlsruhe, Germany |
|||
 Posted - 5/7/2004 10:50:04 AM |
||||
| Thanks. Sorry, I have no experience with AMD64, nor any idea what could be causing a 3x (!) framerate difference. Yes, you're likely better off using the TSC, regardless: less timing overhead, higher resolution, fewer bugs. Here's a good introduction from Intel. // edit: hmm, why is the o_O icon showing up? [edited by - Jan Wassenberg on May 7, 2004 10:51:12 AM] |
||||
|
||||
 |
Shannon Barber Moderator Member since: 6/23/2000 From: Westland, MI, United States |
|||
 Posted - 12/1/2004 10:31:30 AM |
||||
| Window's isn't an RTOS so you can't really use the PLL/PID with great confidence. If you set the thread priority /and/ process both to "realtime", you would probably obtain better results, but then it's important that you set all the other thread's priority to idle. WinAmp probably would not perturb the timer then. |
||||
|
||||
|
Jan Wassenberg Member since: 9/16/2002 From: Karlsruhe, Germany |
|||
|
Posted - 9/6/2005 6:06:24 PM |
||||
Quote: Oops, I haven't looked at this thread in a while :) Sorry. Yes, the thread is at max priority (31). What was confounding me is that Winamp did not previously affect results. This is explained by increased seek error in a dying HD; its driver was apparently spending lots of time retrying at high IRQL. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
