2

I am using servoblaster to control ESC with the Raspberry Pi. I am using the kernel module with default config and write to servoblaster's device file up to 50 times per second. I am using c and the POSIX functions to open and write to servoblaster's device file. It usually takes 0.6 milliseconds to write, but sometimes, for a few seconds, the writes take up to 10 milliseconds. What could be the reason for this behaviour?

2 Answers2

0

It usually takes 0.6 milliseconds to write, but sometimes, for a few seconds, the writes take up to 10 milliseconds. What could be the reason for this behaviour?

It is a multi-tasking system, and a bit of latency is possible. You could try upping the priority of the process (see man nice), and trying to keep the system as inactive as possible otherwise.

The latency may be slipping in where you are coming in and out of system calls. E.g.:

while (1) {
    write(...);
    // do some calculations in userspace
}

I'm presuming you are just trying to do this as fast as possible, and you aren't using any kind of (passive) delay. If so, don't do this with a granularity finer than 10 ms because you will not get predictable results otherwise. The issue is that during the sleep the scheduler may run something else, and a normal kernel can't prevent that from taking <= 10 ms (as in, it may be less, but it won't be more).1

If you are not using a delay, try combining your writes together. Userspace <-> kernel space context switches are expensive.

1 That's a number I've seen repeated but can't find any current references to. If you do some tests with timing timers (e.g., by using gettimeofday() to check how much time has actually passed), you'll probably notice pauses with a granularity of 10 ms are accurate to the millsecond, but finer ones aren't. I.e., a sleep of 10 ms will be 10 ms, but a sleep of 5 ms may be 7 or 9, etc.

Busy looping (e.g., by just polling gettimeofday()) might improve upon that, but it means your program will max the processor, which makes it kind of infeasible for most things.

goldilocks
  • 58,859
  • 17
  • 112
  • 227
  • Thank you for the answer! But does this explain the huge (!) time difference between 0.6ms and 10ms for a write? Most of the time, it goes well, and suddenly, writes take 10ms and get gradual faster, like a jam which gets resolved.I tested the same code with the difference that I write to a normal file instead of the device file. Writes took 1ms, but the write time was stable. Also, I set the thread priority to SCHED_FIFO via POSIX functions, but it doesn't help. –  Oct 26 '13 at 14:08
  • You're right, it doesn't really explain it. If it persists no matter what you do with priorities and optimizing the writes, I'd presume it is a delay from somewhere low down -- either the driver for the device is glitchy, or the device itself (or the pi / the interface on the pi). – goldilocks Oct 26 '13 at 14:27
0

I am now using servoblaster's user space implementation which seems to be more stable than the older kernel driver.