fiq design

General discussion about anything related to Ultibo.
mark
Posts: 1325
Joined: Mon Oct 03, 2016 2:12 am
Location: Indianapolis, US

Re: fiq design

Postby mark » Wed Apr 05, 2017 4:57 pm

Thanks for the great support. I put in my $79 monthly sponsorship for forum support for Apr 2017. Mark.
rvanspaa
Posts: 28
Joined: Sat Nov 11, 2017 3:04 am

Re: fiq design

Postby rvanspaa » Wed Jul 10, 2019 4:07 am

Ultibo wrote:
Ultibo wrote:I can recheck my results and confirm just to be sure

I promised to recheck these results so here it was I got,

200MHz timer with 1000 tick interval - CPU0 = 1% (approx)
300MHz timer with 1000 tick interval - CPU0 = 10% (approx)
400MHz timer with 1000 tick interval - CPU0 = 15% (approx)
400MHz timer with 500 tick interval - CPU0 = 21% (approx)

These results are all from a Pi3B, the results differ on a 2B of course. The highest that I can get the counters on screen to increment at is around 350,000 per second so that seems to be where my code runs out of steam.


Hi,

I modified your code a little (see comments in attached), and am processing about 1.2 million interrupts/second on an RPi B+, using a recent version of Ultibo.
Attachments
FIQTest.zip
(1.58 KiB) Downloaded 155 times
User avatar
Ultibo
Site Admin
Posts: 2308
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: fiq design

Postby Ultibo » Wed Jul 10, 2019 11:32 pm

rvanspaa wrote:I modified your code a little (see comments in attached), and am processing about 1.2 million interrupts/second on an RPi B+, using a recent version of Ultibo.

That's a very interesting result especially given it is a RPi B+, thanks for the information.

I'm not sure if you are in a position to test but I wonder if the results would be higher or lower on a RPi 3B instead, it's feasible that the overhead of sharing the cache and memory with the other CPUs could actually make the number lower in spite of the higher clock speed.
Ultibo.org | Make something amazing
https://ultibo.org
rvanspaa
Posts: 28
Joined: Sat Nov 11, 2017 3:04 am

Re: fiq design

Postby rvanspaa » Thu Jul 11, 2019 12:29 am

Hi,

Ultibo wrote:
rvanspaa wrote:I modified your code a little (see comments in attached), and am processing about 1.2 million interrupts/second on an RPi B+, using a recent version of Ultibo.

That's a very interesting result especially given it is a RPi B+, thanks for the information.

I'm not sure if you are in a position to test but I wonder if the results would be higher or lower on a RPi 3B instead, it's feasible that the overhead of sharing the cache and memory with the other CPUs could actually make the number lower in spite of the higher clock speed.


The result I obtained was based on PBCM2708ARMTimer(TimerDeviceGetDefault).InterruptCount, not on CallbackCounter. When modified to use the latter, it froze with an interval of 125, and I had to increase the interval again to 250. Nevertheless, this still allowed an interrupt rate of about 980000 per second. Of course other things run really slowly at that rate, i.e. painting text on the display goes really sloooowly. ;)

Sorry, I only have the RPi B+. It's all I would need for the application I have in mind, which involves interrupts to GPIO pins, where the interrupt IS the data. One of these interrupts would come from a Geiger counter.

BTW the application involved uses either GPIODeviceInputEvent or BCM2708GPIOInputEvent to set up the interrupt, which, for testing purposes I trigger with a GPIO clock signal on e.g. GPIO pin 43. However the best I can achieve is about 65000 interrupts/second. Trying to wade through the code, I have the feeling that the scheduler is being called during each interrupt, because PBCM2708GPIODevice(GPIODevice)^.InterruptCount gets updated.
I'm not sure exactly which path is being followed, and why it so much slower than the path taken when updating PBCM2708ARMTimer(TimerDeviceGetDefault).InterruptCount.
I'm fairly sure it's using FIQ, but even if it weren't, the difference shouldn't be that large i.e. a factor of about 15 (980000/65000).

BTW2 If sharing the memory is the problem, then it should be possible to get similar results on RPi 3B by restricting it to use just one CPU.
User avatar
Ultibo
Site Admin
Posts: 2308
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: fiq design

Postby Ultibo » Thu Jul 11, 2019 3:01 am

rvanspaa wrote:BTW the application involved uses either GPIODeviceInputEvent or BCM2708GPIOInputEvent to set up the interrupt, which, for testing purposes I trigger with a GPIO clock signal on e.g. GPIO pin 43. However the best I can achieve is about 65000 interrupts/second. Trying to wade through the code, I have the feeling that the scheduler is being called during each interrupt, because PBCM2708GPIODevice(GPIODevice)^.InterruptCount gets updated.
I'm not sure exactly which path is being followed, and why it so much slower than the path taken when updating PBCM2708ARMTimer(TimerDeviceGetDefault).InterruptCount.
I'm fairly sure it's using FIQ, but even if it weren't, the difference shouldn't be that large i.e. a factor of about 15 (980000/65000).

Remember that the GPIO is a device with its own clock and its own behavior so the results can be very different from a timer device.

As long as you are using GPIO_EVENT_FLAG_INTERRUPT then there is no reason the scheduler should be involved, since the scheduler interrupt rate is 2000 per second then you would probably be getting much lower results than you are if that was the case.

I don't have and haven't seen any empirical evidence of what the real interrupt rate that is achievable from the GPIO should be so it's hard to say if 65000 is low or about right.

For reference the PBCM2708GPIODevice(GPIODevice).InterruptCount is updated directly by the BCM2708GPIOInterruptHandler() function which is called directly from the interrupt dispatcher code (as discussed in another post) so no scheduler involved there.
Ultibo.org | Make something amazing
https://ultibo.org
rvanspaa
Posts: 28
Joined: Sat Nov 11, 2017 3:04 am

Re: fiq design

Postby rvanspaa » Thu Jul 11, 2019 3:18 am

Ultibo wrote:Remember that the GPIO is a device with its own clock and its own behavior so the results can be very different from a timer device.

As long as you are using GPIO_EVENT_FLAG_INTERRUPT then there is no reason the scheduler should be involved, since the scheduler interrupt rate is 2000 per second then you would probably be getting much lower results than you are if that was the case.

I don't have and haven't seen any empirical evidence of what the real interrupt rate that is achievable from the GPIO should be so it's hard to say if 65000 is low or about right.

For reference the PBCM2708GPIODevice(GPIODevice).InterruptCount is updated directly by the BCM2708GPIOInterruptHandler() function which is called directly from the interrupt dispatcher code (as discussed in another post) so no scheduler involved there.


I am using GPIO_EVENT_FLAG_INTERRUPT and as mentioned in the source comments, I have previously seen up to 4.5 million interrupts/second from this hardware using GPIO clock interrupts on a pin, so the use of pins per se is not a reason why it should be slower.
User avatar
Ultibo
Site Admin
Posts: 2308
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: fiq design

Postby Ultibo » Thu Jul 11, 2019 3:39 am

rvanspaa wrote:as mentioned in the source comments, I have previously seen up to 4.5 million interrupts/second from this hardware using GPIO clock interrupts on a pin, so the use of pins per se is not a reason why it should be slower.

I had noticed that comment in the source but I also noticed that it said:
with a very small assembler code fast interrupt handler

which would likely make a significant difference overall. Ultibo isn't really able to provide highly optimized ultra fast implementations of all of these things because we are trying to make something that has a much broader range of possible uses and therefore the overall functionality is as important as performance and a trade off of functionality versus performance has to be made in certain places.

On the other hand what we have done is make it possible to replace the default code with your own whenever you need more than what we provide, in this case you could call VectorTableSetEntry with the value VECTOR_TABLE_ENTRY_ARM_FIQ and pass the address of your own optimized FIQ handler which will be called directly by the CPU when an FIQ occurs (no Ultibo code in the path at all). That should allow you to optimize the handling as far as you need to go.
Ultibo.org | Make something amazing
https://ultibo.org
rvanspaa
Posts: 28
Joined: Sat Nov 11, 2017 3:04 am

Re: fiq design

Postby rvanspaa » Thu Jul 11, 2019 3:56 am

Ultibo wrote:I had noticed that comment in the source but I also noticed that it said:
with a very small assembler code fast interrupt handler

which would likely make a significant difference overall. Ultibo isn't really able to provide highly optimized ultra fast implementations of all of these things because we are trying to make something that has a much broader range of possible uses and therefore the overall functionality is as important as performance and a trade off of functionality versus performance has to be made in certain places.

On the other hand what we have done is make it possible to replace the default code with your own whenever you need more than what we provide, in this case you could call VectorTableSetEntry with the value VECTOR_TABLE_ENTRY_ARM_FIQ and pass the address of your own optimized FIQ handler which will be called directly by the CPU when an FIQ occurs (no Ultibo code in the path at all). That should allow you to optimize the handling as far as you need to go.


Thanks I may try that, just to see how much difference it makes, however the timer interrupt speed would be more than adequate for my needs, and I would prefer to keep things standard as much as possible, so I would still like to understand where the huge difference is coming from.
User avatar
Ultibo
Site Admin
Posts: 2308
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: fiq design

Postby Ultibo » Thu Jul 11, 2019 7:56 am

rvanspaa wrote:Thanks I may try that, just to see how much difference it makes, however the timer interrupt speed would be more than adequate for my needs, and I would prefer to keep things standard as much as possible, so I would still like to understand where the huge difference is coming from.

The difference will be between BCM2708GPIOInterruptHandler and BCM2708ARMTimerInterruptHandler, everything else in the path will be the same.

While BCM2708GPIOInterruptHandler is not a lot more complex than BCM2708ARMTimerInterruptHandler it does contain some things that could add a little overhead such as a try/finally block and a SpinLock/SpinUnlock call. It might be worth experimenting to see if you can improve it.
Ultibo.org | Make something amazing
https://ultibo.org
rvanspaa
Posts: 28
Joined: Sat Nov 11, 2017 3:04 am

Re: fiq design

Postby rvanspaa » Sat Jul 13, 2019 7:11 am

Ultibo wrote:The difference will be between BCM2708GPIOInterruptHandler and BCM2708ARMTimerInterruptHandler, everything else in the path will be the same.

While BCM2708GPIOInterruptHandler is not a lot more complex than BCM2708ARMTimerInterruptHandler it does contain some things that could add a little overhead such as a try/finally block and a SpinLock/SpinUnlock call. It might be worth experimenting to see if you can improve it.


Thanks. I tried commenting out the spinlock/spinunlock & recompiled ultibo, but it made no difference. BTW is there a simple way to just recompile one unit of Ultibo, without recompiling the whole thing?

Return to “Discussion”

Who is online

Users browsing this forum: No registered users and 112 guests