0
\$\begingroup\$

I have a Ubuntu 16.04 machine talking to a Uno board. This arduino board is sending 100 chars of line at baud rate of 115200 as fast as possible. Usually I get a line every 7ms to 10 ms (I am going to call this value DT). Let's say, on a good day, when I start my trial at time 0. I receive lines at 0, 0+DT, 0+2DT etc. But on not so rate bad days, I receive lines at 0+DT+t, 0+2DT+t, ... where t is the lag.

This lag can be quite large sometime (upto 200 ms). This lag remains consistent (not surprising). I am suspecting that running firefox/imagej during the trial on the same system might have caused this lag.

But I am not sure. Any pointer on specification/documentation on how kernel handle serial communication would be appreciated. Essentially the question I am looking for: Can other heavy processes cause lag in serial port communication?

\$\endgroup\$
3
\$\begingroup\$

Even though things seems to look like they run in parallel. They do not. Each CPU can do only one thread at once, and your thread is one of those.

If more threads require CPU, then other threads have to wait. How long this wait takes depends on the quantum time of the kernel, and how nice your thread is.

So, it depends on your scheduler configuration.

To keep it simple:
The kernel handles serial communication via the driver. The driver has access to interrupts. This is to read data from the hardware immediately before the buffers overflow.
The driver then moves the data to a stream, this signals any threads waiting for this stream. And the kernel acts on these signals to give the threads some CPU to handle this data.

If you require low latency serial access you could make your thread less nice, giving it a higher priority over other threads. Biasing the scheduler to preempt other thread to run your thread when data is available.
Or write your own driver.

In any case, a desktop operating system is not intended to be immediate. That's a real-time kernel task. Which is what you will need when you are interfacing hardware that requires low latency software control on a higher end platform.

\$\endgroup\$
  • \$\begingroup\$ Thanks @Jeroen3. This is very informative. I've no experience developing in RTOS . In the future, I can move my experimental setups to a dedicated RasberryPi and get rid or Arduino to avoid serial communication. But I am not sure if implementation would be as easy as on Debian with some RTOS (I looked at FreeRTOS just now; does not look like there is Raspberry PI version). Thanks again. For now, I will use nice when I launch my pipeline. \$\endgroup\$ – Dilawar Jul 22 at 6:49
  • \$\begingroup\$ @Dilawar Realtime on x86 is not easy. Check for real-time kernel version of linux first. There are also real time operating systems for ATmega, but this is not what you asked about. \$\endgroup\$ – Jeroen3 Jul 22 at 6:56
  • \$\begingroup\$ @Dilawar This sort of optimization lies on Kernel level like Jeroen3 has stated. You may write your own kernel drivers under a very lightweight distribution in order to have the highest interrupt priority for whatever communication you are doing. This is particularly interesting for very high frequency sensors where you don't want to lose information. \$\endgroup\$ – lucasgcb Jul 22 at 12:01
2
\$\begingroup\$

In short, yes, running programs will keep the CPU busy elsewhere until it runs your serial program. That is why serial drivers buffer data so it is not lost when it is not immediately read. Also remember that you get the timestamp of when your program reads the data, not when it arrived in the buffer.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.