Alert thread lagging behind about pigpio HOT 15 CLOSED

The main thread, alert thread, pipe thread, and socket thread should be running in separate cores on the Pi2. Nothing special needs to be done.

I'll have a look at the alert thread as I periodically try to tune the way it works. Perhaps I have broken something.

Which pigpio version are you using (pigpio.h PIGPIO_VERSION)?

from pigpio.

We are using version 42.
There are also some other threads/processes running on the system, could they have an impact? Also, do the socket and pipe threads need to be in real-time? I'd normally give IO threads a much lower priority...

from pigpio.

Nothing obvious.

Before I spend any more time on this could you confirm the data rates you are talking about, i.e. how many alert function calls are made per second. Also confirm that the processing required can keep up with that data rate.

from pigpio.

The data rate depends on the motor speed, so providing exact values is difficult. In the normal operation range we got about 6500 alert calls. I also did a quick test using a free motor and spinning it up to maximum speed, there we got 22000 alert calls per second. These test runs worked flawlessly, so I would conclude that the processing can indeed keep up.

from pigpio.

Okay. There shouldn't be any problem at those rates. I'll have a closer look. It might take several days depending on what else I need to do. If you have a cut down program which exhibits the problem it would be useful. I can simulate the inputs.

from pigpio.

Thank you for your help. A testcase program would be a bit difficult as the error doesn't occur deterministically, but I'll see what I can do.

from pigpio.

Here is a shrunk-down program that should be able to reproduce the error:
https://www.dropbox.com/s/girq48d7mwqpan4/motorcontrol_test.zip?dl=0

from pigpio.

Just a note to say I haven't forgotten this issue. Just busier with other things at the moment.

from pigpio.

We now switched to using software polling for the gpios we're interested in, and so far we didn't get any problems. However, the software polling has a big impact on the overall cpu usage, so if there was a solution for this, I'd greatly appreciate.

from pigpio.

I have tried to separate out the GPIO sampling from the issuing of reports in V44. Could you see if you still have problems (or if I've introduced new ones).

from pigpio.

In the absence of further information I'm going to close this as an issue.

from pigpio.

I see the same bursting behavior in my application. I read pulses from a powermeter (S0 Interface) 90ms duration one pulse.
each burst you see in the graph is about 50 minutes long, then for 10 minutes almost no callbacks.
I run a standard raspberian debian version 9.4.
I am still trying to isolate the problem. I keep you posted

from pigpio.

pigpio version? C? Python? Code to simulate the problem?

from pigpio.

dpkg -s pigpio | grep Version
Version: 1.64-1
C/C++ Code
Working on isolating the problem. Once done I will post the code.
Thanks for your fast reply.
Michael

from pigpio.

It was my silly mistake, sorry for bothering. In one area of the code I used a tick count with a simple isGreater compare which caused the clause to missfunction when the tick counter wrapped. In all other cases I used your proposed code to compare tick counts.
Thanks for this great support and pigpio.

from pigpio.