Clock rate changes with speedstep about freepie HOT 8 CLOSED

The default rate is 64hz not including the overhead of the script it self. And you must take into account hat windows is not a real time system.

Timing in FreePIE is not easy, we cant just let the script have all CPU time it can get because then we will throttle that Core and you will run into performance problem. So we have a pattern for timing the script cycle. Default we use the system clock which is at 64hz. You can override this using system.setThreadTiming and system.threadExecutionInterval

We have some different strategies for timing, if you know C# you can check them out here

https://github.com/AndersMalmgren/FreePIE/tree/master/FreePIE.Core/ScriptEngine/ThreadTiming

If you want the most accurate one (If we ignore that Windows is not a real time system and that FreePIE is managed code) you should use TimingTypes.ThreadYieldMicroSeconds. It will however eat more resources than for example TimingTypes.HighresSystemTimer

from freepie.

Also,

    diagnostics.watch(prevTime)
    diagnostics.watch(now)
    diagnostics.watch(fps)

will real time update UI, this will impact performance (While UI is in focus)

from freepie.

Thanks that's helpful, looks like some of the other timing strategies should solve the problem.

I still don't understand why the timing changes though, even with the default timing strategy. How does it end up at 1000Hz?!

from freepie.

From what I can work out:

• SystemTimer sleeps for ThreadExecutionInterval milliseconds, without regard for how long the script took
• ThreadYield repeatedly yields in a spin loop until enough time has passed (I think it takes account of script time but not entirely sure)
• ThreadYieldMicroSeconds same as above
• HighresSystemTimer (BeginPeriodSystemTimerStrategy) - I don't understand what this is doing

Is there not just a simple timer that calls Thread.Sleep for the right amount of time, taking into account how much time the script took?

Also, the default ThreadExecutionInterval is 1, which would mean a default rate of 1000Hz. Where does the 64Hz come from? My suspicion at the moment is that this is not really defined properly, and is instead just rate limited by the thread scheduler or something.

from freepie.

None of the strategies take into account the time taken for the script sadly. Shouldn't be a problem in normal cases though since the overhead in the script should be minimal. The system clock runs at 64hz, so you can't sleep shorter than 16ms (1000/64). Really strange that you get 1000hz, do you have another program that changes the speed of the system clock? That's how the Highres strategy work, it changes the system clock from 64hz to 1000hz

from freepie.

Sorry, the yield strategies do take into account the time of the script :)

from freepie.

Ok. May I suggest that the default threadExecutionInterval be set to 16 then? That would avoid the confusing behaviour in the case that the clock rate isn't 64Hz for some reason! :)

from freepie.

Could have side effects on systems that override default clock speeds.
edit: Basicly Thread.Sleep(1) means that you sleep as short time as the OS lets you.

from freepie.