tick values in notifications about pigpio HOT 8 CLOSED

That's one of the reasons I do not recommend 1µs sampling.

A little background.

pigpio samples the GPIO in batches of 25. Every 25 samples the system microsecond clock is read and used to timestamp the first sample in the batch. The next 24 samples are assumed to be one sample period later. The system microsecond clock is then read again. The expected time is compared to the actual time and an internal statistic showing the deviation from expected time is updated. These statistics can be viewed at the end of the run by a variety of methods. The simplest is to issue the command pigs csi 512 and then cat /dev/pigerr&. Then kill the pigpio daemon or your C program if linked to the C library.

You will see there are deviations from the expected results. They are rare and the last time I tested (at a 5µs sampling rate) mainly happen at defined time intervals like every 2.5 seconds. I assume there is something being triggered at that rate which temporarily mucks up DMA.

This shows the interval between sampling errors over several hours. Up is the interval in seconds. Along is the number of times that gap was detected between successive sampling errors.

For sample rates of 2µs or higher I auto correct the sample times. When the expected differs by more than one microsecond from the actual I go through and adjust the 24 estimated sample times to be equally spaced in the sample period.

There is a dilemma at a 1 µs sampling rate. If the expected is 100 (first of the batch timestamped at 75) but the actual is 95 what can you do? I suppose the best option would be to give successive samples the same tick.

Here are some statistics I collected on a Pi Zero in a slightly different way. I ran a Python program to generate 1245 µs pulses and recorded the reported length for a couple of hours. I used PWM at 800Hz to generate the pulses. The first column is the number of times the time in the second column was seen.

      1 1225
      2 1226
      2 1227
      3 1228
      5 1229
     15 1230
      8 1231
      5 1232
     18 1233
     14 1234
      9 1235
     12 1236
     25 1237
     21 1238
     11 1239
      1 124
     17 1240
     16 1241
     21 1242
     21 1243
 262563 1244
4481614 1245
 278673 1246
     32 1247
     18 1248
     22 1249
     17 1250
     16 1251
     12 1252
     22 1253
     22 1254
     12 1255
      9 1256
     17 1257
     16 1258
      6 1259
      7 1260
     16 1261
      5 1262
      2 1263
      2 1264
      2 1265
      1 1266

from pigpio.

I'm beginning to understand things better now.

These are the effects that were observed:

• The tick field in the first notification received can be greater than the tick field in the second notification received by a small number of microseconds. Typically 1 to 3 microseconds.
• The tick field in two consecutive notifications can have the same value.
• The tick field in two consecutive notifications can differ by up to 23µs.

To summarize, these effects can be explained by the sample rate of 1µs, the fact that the GPIO is sampled in batches of 25, the auto correction of sample times, and something that temporarily mucks up DMA every 2.5 seconds. Software using notifications will need to take such deviations from the expected results into account. Is this correct?

Also, I'm a little envious of the fact that you already have a Pi Zero and I don't :).

from pigpio.

Firstly, as far as I am aware this is currently only a potential problem if you choose a sample rate of 1 µs. For the other sample rates the sample ticks are corrected to be monotonically increasing if a deviation between expected and actual is found.

For the problem to be seen you would have to be

1. sampling at 1µs and
2. be trying to time level transitions in the region of 50 µs
3. and be unlucky enough to have your event happen at the same time as an aberration

I have done some initial tests with auto-correcting 1µs samples. The best I can do is ensure that later ticks are greater than or equal to the previous tick.

I expected auto-correction to add quite a load but to my surprise it doesn't seem to make any difference (given that 1µs sampling uses circa 24% of base CPU).

I'll be running a test of load for an earlier non-correcting version and a new correcting version. As long as the initial figures are confirmed I'll make the change.

That will remove the worst effect of having ticks appearing out of sequence.

One odd thing I have noticed is that successive batches usually cancel each other out, e.g. one batch will be x micros too long but the very next is x micros too short. I'm not sure what is happening to cause that. Of course it may be an artefact caused by the printfs added to monitor the code.

from pigpio.

I have added code to auto-correct 1µs sampling in V42. Because of the issues mentioned above the best I can do for short (in time batches) is give successive samples the same tick.

It should remove the wilder swings reported by your software when sampling at 1µs.

from pigpio.

Thank you very much (again.) I'll give it a try asap.

from pigpio.

I ran your code, slightly modified to record the difference between successive ticks, for about 70 minutes on a Pi2B.

In a perfect world you'd expect 400000 readings per second each with a gap of 2.5 µs.

I got these results, first figure is microseconds, second figure is how often that gap was detected. The results are actually a lot better than I expected for 1 µs sampling. 99.67% 2 or 3 µs as expected, and 99.9967% between 1 and 4 µs.

0 9501
1 2793342
2 869121761
3 873712019
4 1315345
5 41833
6 4405
7 521
8 132
9 388
10 661
11 83
12 7

Total 1746999998 samples (the first gap discarded).

from pigpio.

Very nice, very nice indeed.

The best I can do is ensure that later ticks are greater than or equal to the previous tick.

It looks like you've done more than this. The tick field in two successive notifications differed by up to 23µs when tested with V41. The biggest different I've seen with the same test using V42 is 11µs, and I only saw that 8 times in 1,000,000,000 samples.

Once again, excellent job, and thank you very much.

from pigpio.

Everything is also looking good when pigpio is used from JavaScript. The figures are very similar. I just performed a test with 1e9 samples at 300,000 level changes per second. To the best of my knowledge every single level change was detected.

from pigpio.