Overclock FreePIE!

[CyberVillain]

There is a new cool feature in FreePIE 1.3.422

By default FreePIE runs at 64hz which is the system clock speed

This is fine for most cases but sometimes you want more, for example sensor fusion can work better at higher speeds.
Another example is Wiimote.

To get both Motionplus and Nuncuck output at the same time the script engine needs to poll the wiimote exactly at 500hz

You can now choose from 3 different strategies to time FreePIE, SystemTimer, ThreadYield and HighresSystemTimer

Systemtimer

• The default one and the one that leaves no side effects on the system, however if you choose this timing you cant go below 16ms delay (64hz).

ThreadYield

• This strategy uses the highres timer in the OS, to get below 16ms it yields the script thread, this means that FrePIE will use all resources from a single CPU core but yield if other processes need CPU time on that core. This can lead to side effects if you play a game which needs a lot of threads

HighresSystemTimer

• This strategy changes the the system clock to 1000hz instead of 64hz. This can lead to side effects with programs that rely on that all timer < 16ms = 16ms

To change FreePIE's default timer do

Code: Select all

if starting:
	system.setThreadTiming(TimingTypes.HighresSystemTimer)
	system.threadExecutionInterval = 2

Above code will choose the HighresSystemTimer strategy and set it to run at 500hz (2ms between script executions)

[RoadKillGrill]

Awesome, I will need to try this out later

[CyberVillain]

Please, let me know how it goes!

[BOLL]

This is a while ago now but turns up in google for me all the time xD

Randomness, wanted to up my clock, added this, it was halfed. Apparently the base clock is at 1 kHz now, doh!

[CyberVillain]

I dont quite follow you, you mean you ran into problems because FreePIE changed the system clock from 64 to 1000 hz?

[BOLL]

Nah it was just unexpected, I had made assumptions of it running at 64 Hz as I had read this thread but was getting weird results, so I figured I would try this... and blammo, of course it acted up as the real Hz was 1000

[HarvesteR]

I've found that by setting the threadInterval to zero, the script will run as fast as a single core will allow it. I think the final update frequency then would depend quite a lot on the computational cost of the script itself, but in my test here, I've seen it run as fast as 32khz.

I was wondering then, if there isn't a way to set the thread interval to a sub-millisecond value. The interval variable expects an Int32 type, so 1ms (and 1000hz) is the minimum before opening the 'flood gates'... But would it somehow be possible to set a thread interval using µSecs instead?

Cheers

[CyberVillain]

We use Thread.Sleep under the hood and it only allows milliseconds. Maybe there is a kernel level function we could use that will allow this, dont know and haven't investigated it. If you investigate I would love to help you implement it in FreePIE.

The relevant code

https://github.com/AndersMalmgren/FreeP ... egy.cs#L10

[HarvesteR]

Oooh C#, lovely!

I'll have a poke here then, if I may.

Cheers

[CyberVillain]

Yes FreePIE core is entirely written in C#
Some plugins use code written i C++ however

[HarvesteR]

Welp, I believe I've solved it then

Props to Ken Loveday's MicroTimer Lib, and of course, to your very nicely set up project btw!

I created a new timer strategy called MicroTimerStrategy:Timing, and added the corresponding enum value to the timing attrib. Using MicroTimerStrategy, the threadExecutionInterval is assumed to be in microseconds, so a value of 500 would be equivalent to 0.5ms on other strategies.

I just did a quick test here, and I've got the script to report running at sub-ms intervals, over 1000hz. For instance, with a thread interval of 250µs, I clocked the test script (which is nothing more than a timing watch) at 4000hz, and for 100µs, it clocked in at 10khz.

Performance-wise, it's not eating nearly as much CPU core as it was when I let loose with 0 thread interval. I'm using the same approach as with ThreadYield, so I didn't have to resort to spinwaiting. The MicroTimer lib states that the execution calls aren't guaranteed to be 100% evenly spaced, due to limitations of Windows and its NRTOS-ness, but for the purposes of overclocking FreePIE scripts, it should do very well.

I'll push the changes I did as a fork to the repo. Feel free to use or modify as needed.

Also, here is the benchmark script I used:

Code: Select all

import time


if starting:
	system.setThreadTiming(TimingTypes.MicroTimer)
	system.threadExecutionInterval = 100 # in µseconds
	global tLast
	tLast = 0
	
Hz = 1 / (time.clock() - tLast)
tLast = time.clock()


diagnostics.watch(Hz)

Also, many, many thanks for creating this awesome app!

Cheers


EDIT:

Submitted a pull request on GH with the changes.

Cheers!

[kanecharles]

I've found that by setting the threadInterval to zero, the script will run as fast as a single core will allow it. I think the final update frequency then would depend quite a lot on the computational cost of the script itself, but in my test here, I've seen it run as fast as 32khz.

I was wondering then, if there isn't a way to set the thread interval to a sub-millisecond value. The interval variable expects an Int32 type, so 1ms (and 1000hz) is the minimum before opening the 'flood gates'... But would it somehow be possible to set a thread interval using µSecs instead?

Cheers

Currently, in FreePIE you can only set a minimum threadInterval value of 1ms (equivalent to 1000hz). There is no way to set thread interval in µSecs (microseconds).

time calculator