Quote:Original post by Shannon Barber
[...]I have a computer that is 40x more powerful yet is 90% less precise.[...]

Your more powerful computer has more powerful hardware that can better perform many tasks, including more precise timers. If you want to take advantage of that increased functionality, you can't use functions created long ago with specifications based on the hardware of the time.

I'd think it very reasonable for a win32 Sleep() call to put the sleeping thread at the end of the scheduling queue (or, 'worse', put it at the end of the queue after the sleep duration has elapsed) since it indicated it wanted to stop processing for at least X amount of time. That could lead to any amount of delay if there were enough other equal-priority threads ready to run.

Is that quote from Jan Wassenberg something you found on the forums or was it a reply to a question you asked him directly? You might want to message/email him if you haven't, as last time I talked to him, he had an extended, updated, and refined version of his article that had not yet been posted publicly on the internet.

[Edited by - Extrarius on February 15, 2010 4:07:39 PM]

so precision is essential :P
I'm not serious (at least I tried not to be)

Anyway I will go the WM_TIMER way. Since it's based on milliseconds and I can measure absolute elapsed time, I can adjust the timer value every time to keep as precise as possible.

I mean, how else would you solve it in an event based application (please tell me the correct term for it)?

Quote:Original post by Rycross

Quote:Original post by Shannon Barber
It's always real-time and always a question of performance.

I don't think you understand what they meant by real-time. Real-time, in computer programming terms, means that you can make guarantees about how frequently and how long your processes are scheduled. There is a thing called a real-time OS, where if you programatically say "I want to wait for 50 ms before running again," the OS can guarantee that. Obligitory Wikipedia link.

Windows is not a real-time OS, and its not designed to be.

I understand your sentiment but I'm arguing a higher point; >everything< is real-time task because everything has a deadline - it is just a question of the performance needed.

If you clicked on 'Print' and it took 4 weeks for it to come out of the printer no one would accept "Well, Windows is not a real-time operating system" as an 'answer'.

When you dig into RTOS's it's all about their ability to minimize jitter and few jobs are true "hard real-time".
Most tasks can tolerate /some/ jitter and are so-called "soft real-time".
There is no good excuse for Windows to not be able to achieve 'soft real-time'. You literally cannot play music nor watch videos without this capability and to the extent Windows provides a multi-media API that includes functions to change how quickly it ticks tasks (down to a supposed 1ms and *it the past* you could sleep for 900us which worked "good enough", now you get ~1500us which is no longer "good enough").

[Edited by - Shannon Barber on February 17, 2010 3:45:49 PM]

Quote:Original post by KulSeran

Quote:
If you called Sleep(10) in your app and it slept for two minutes every time no one would accept that "it works to spec".

Sure they would! If I'm running a really low priority service, and I need to do stuff, then go idle. Sleep(10) could take minutes if there is a high priority task eating up 100% of the CPU. I already said i'm low priority, and I said I don't want to work more than once every 10ms. So the wait time is "to spec" because the user sees that their high priority task(like video encoding or something) isn't being interupted by all the hundreds of random threads on the machine. Waiting on a device is even better. My service will go to sleep till some random time in the future when there is data for me.

Windows only guarantees that I will eventually get time, and will eventually get my data if it exists. It isn't a realtime OS, so it doesn't guarantee it will do any of that in a timely manner.

Quote:
I have a computer that is 40x more powerful yet is 90% less precise.

Your computer is also 40x a powerful, but running 600x as many random tasks. Look back to dos, what did it have running? nothing. command.com that was it, and it was waiting for you to type things. You run another app? yeah it got 100% of the cpu to itself so it could be 100% accurate. You have to remember you are sharing the computer. If you don't have a a very good computer(like my old dual core), try running a high-def 1920x1200 movie and doing anything else. The movie player will be high priority, and everything else takes a back seat. Opening something like firefox(usually a sec or less) can take 15sec to a min, but your video keeps playing along nicely.

It's not running 600x more task I doubt it's even 10x more and we strip out all the unneeded services and the ones left are all idle and sleeping most of the time and we have 2/4/8 cores now so it's less likely that all the CPUs are 'too busy' and even if they are, we are the highest priority task on the system.
All of our processes and threads (where this timing matters) are set to Real-time process priority and real-time thread priority where they are trying for 1ms updates.
The computer hardware can handle the task we are asking for, it's the OS that is in the way.

I did the 1 second timer just to drive home how crappy they are, off by 14% with an virtual eternity between ticks.

If you really do need a precise 1ms update rate, then perhaps you shouldn't be trying to run on a general-purpose operating system. It may be that it's "worse" than it was in previous versions of the operating system, but I'm quite sure Microsoft didn't just change the rules for the sake of it. More than likely they've adjusted the scheduler to make the system fairer in the general case. The general case does not require clock-tick precise timing. Multimedia applications do not require precise timing, within 15-20ms (and maybe more) is good enough to avoid jitter.

I'd say that if you've got unusual requirements (and, to be honest, your requirements are unusual) then you're probably not best served running on a general purpose OS. You're probably better off looking into Linux and customizing the kernel for your particular needs.

If you really need to run on Windows, then you're kind of out of luck... you'll just have to figure out a way around the OS's design. I realise your post is more of a rant than anything, but what did you expect? There's not much we can do to help you, since we've got as much input into the design of the Windows scheduler as you do: none at all [wink]

Quote:Original post by Codeka
If you really do need a precise 1ms update rate, then perhaps you shouldn't be trying to run on a general-purpose operating system. It may be that it's "worse" than it was in previous versions of the operating system, but I'm quite sure Microsoft didn't just change the rules for the sake of it. More than likely they've adjusted the scheduler to make the system fairer in the general case. The general case does not require clock-tick precise timing. Multimedia applications do not require precise timing, within 15-20ms (and maybe more) is good enough to avoid jitter.

I'd say that if you've got unusual requirements (and, to be honest, your requirements are unusual) then you're probably not best served running on a general purpose OS. You're probably better off looking into Linux and customizing the kernel for your particular needs.

If you really need to run on Windows, then you're kind of out of luck... you'll just have to figure out a way around the OS's design. I realise your post is more of a rant than anything, but what did you expect? There's not much we can do to help you, since we've got as much input into the design of the Windows scheduler as you do: none at all [wink]

Touche, but there *is* something better to be done.
My rant was specifically why the performance of Sleep has gotten /worse/ over the years - as the NT kernel has been updated and substantially improved in many, many ways from NT 3.5 to 7 why on Earth would the performance of Sleep degrade? It doesn't make sense and there actually *is* a reason!
There's a new feature called 'Timer Coalescing' the deliberately bunches timer expirations together (designed to minimize power consumption.)

Our software simulates and tests the software that runs vehicle ECUs (electronic control units). Primarily automotive but some military controllers as well.
Our 'software-in-the-loop' solution can run at "warp speed" and runs much faster than real-time (which is useful for getting 4 hours of testing done in 20 minutes).
Now given that we can do that... why is it so freaking hard to *slow it down* to real-time?
You can then interface a mix of real-hardware and virtualized hardware with a DAQ (analog IO, digital IO, maybe some counter/timers) and a CAN network device (CAN is most common type of network that runs [most] vehicles.)
i.e. The "vision" we sell is full-vehicle virtualization at the onset of the project and as hardware becomes available the virtual ECUs are replaced by real-ones and the same set of automated regression tests run on both the SIL & HIL environment.

Generally vehicles ECUs periodically tick from 1 to 10 ms. If one tick is 900us and the next is 1100us that is OK for simulation purposes as long as the over-all average is roughly 1000Hz. +/- 10% is tolerable and even an occasional delay spike is undesirable but again tolerable as long as it nominally runs at 1000Hz.

We can also "co-simulate" between disparate software development systems. The most pointed example is we can make a Statemate model "talk" to a Simulink model running on virtual ECUs. [This is "exciting" to companies using Statemate since it's a dead product and we give them a path forward to Simulink.]

So right now we burn up a core spinning hard calling QPC and it signals an event at a nominal rate of 1000Hz. What a terrible waste of 3GHz.

All of the "timing problems and issues" you have with SIL to HIL and between multiple virtualization computers are /same problems/ you have in the vehicle with multiple ECUs each having their own free-wheeling (unsynchronized) clocks so that aspect of timing is not a "problem" for us since it reflects 'real world behavior' anyway.

As mentioned, "Linux can do it", "BSD can do it", dunno if OSX can or not, and with some fancy tricks (e.g. RTX) you can do it with Windows. But there really is no good reason to have a modern OS devoid of a high-precision timer event.