It is currently Tue Aug 20, 2019 6:45 am



Reply to topic  [ 11 posts ] 
 Overclock FreePIE! 
Author Message
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
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:
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)

_________________
FreePIE
My blog


Mon Oct 07, 2013 11:48 am
Profile
Cross Eyed!

Joined: Tue Oct 09, 2012 2:36 pm
Posts: 119
Location: Ohio
Reply with quote
Awesome, I will need to try this out later :mrgreen:


Fri Oct 11, 2013 8:44 am
Profile WWW
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
Please, let me know how it goes! :D

_________________
FreePIE
My blog


Fri Oct 11, 2013 7:08 pm
Profile
Binocular Vision CONFIRMED!
User avatar

Joined: Mon Aug 06, 2012 9:26 pm
Posts: 295
Location: Sweden
Reply with quote
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! :D


Sat Feb 14, 2015 3:43 pm
Profile WWW
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
I dont quite follow you, you mean you ran into problems because FreePIE changed the system clock from 64 to 1000 hz?

_________________
FreePIE
My blog


Sun Feb 15, 2015 5:37 am
Profile
Binocular Vision CONFIRMED!
User avatar

Joined: Mon Aug 06, 2012 9:26 pm
Posts: 295
Location: Sweden
Reply with quote
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 :P


Sun Feb 15, 2015 8:29 am
Profile WWW
One Eyed Hopeful

Joined: Mon Jun 15, 2015 10:30 am
Posts: 19
Reply with quote
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


Thu Jun 18, 2015 3:22 pm
Profile
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
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

_________________
FreePIE
My blog


Fri Jun 19, 2015 3:53 am
Profile
One Eyed Hopeful

Joined: Mon Jun 15, 2015 10:30 am
Posts: 19
Reply with quote
Oooh C#, lovely! :)

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

Cheers


Tue Aug 18, 2015 3:23 pm
Profile
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
Yes FreePIE core is entirely written in C#
Some plugins use code written i C++ however

_________________
FreePIE
My blog


Tue Aug 18, 2015 3:56 pm
Profile
One Eyed Hopeful

Joined: Mon Jun 15, 2015 10:30 am
Posts: 19
Reply with quote
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:
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!


Tue Aug 18, 2015 4:15 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 11 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by STSoftware.