[Solved] [AD2PI] serialport.py using 100% cpu

[danimal1228]

When I run the example 'serialport.py' the cpu usage goes up to 100%. I imagine this is because in 'devices.py' the serial port is opened with "timeout=0" which makes the serial.read() non blocking. There is even a note in 'devices.py' that says "Timeout = non-blocking to match pyftdi"

Is there any reason that this is like this? If I set the timeout to "none" then the read() command blocks and the cpu usage drops to 0 and only goes up a bit when the ad2pi receives serial traffic. The only issue is that you have to force quit the python thread because the serial port will stay open forever waiting on data. This shouldn't be an issue because I will eventually be running a custom version of serialport.py as a daemon but it would be nice if it would quit pretty.

If I set timeout=5 then it appears to block for 5 seconds and then move on. The thread will also die pretty, after 5 seconds or so. I have run it like this for a while and haven't noticed any issues.

Would anyone like to chime in? Is it safe to set a timeout > 0 for a serialport device?

Thanks

[Scott]

I've never really been happy with that reader code. I believe the reasoning behind that comment was due to being forced into modeling everything after pyftdi's nonblocking reads, so we handle the timeout ourselves. Not sure about the cpu usage as I never noticed too much load, but then again I have a fairly beefy workstation, or perhaps the resolution on the reader thread's time.sleep is too small for your system for some reason.

As for changing the timeouts, I don't really see any issues, as long as everything's working for you. I imagine you'd be fine using less than 5 seconds, but None definitely breaks the ability to shutdown the thread. You could probably close the device and let the exception take care of it for you, though. That code was written at the very beginning and hasn't been exercised with timeouts other than zero, and frankly, may not even be needed. Let me know how things go for you and I'll see about doing a little more extensive testing and maybe rework that silly thread.

[danimal1228]

I will keep trying a few different settings to see how the whole thing behaves. Is there any reason why read() is used instead of readline()? I believe readline() will keep accepting serial input(blocking) until it receives a \n, but im no python expert. I am at work so I didn't have time to rewrite that portion of the code using readline instead of read.

My ad2pi is connected to a Raspberry pi, obviously, so that might be part of why the cpu use is so high also.

[mathewss]

At least from my experience reading char by char has the advantage of avoiding a deadlock waiting for a line terminator that may never arrive and that can happen in some cases with the AD2* specifically when waiting for input.

I think adding a small sleep 10 to 30ms between each loop will fix the problems and avoid the cpu overload.

Please post your findings and we can work on improving this part of the code.

Re
Sean M

[Scott]

Hey danimal,

Turns out I caused this bug when I was cleaning up the code for release. I pushed a fix up to github and it's behaving much nicer.

Thanks for the report!

[chrisinky]

Just wanted to say THANKS! This fix is working great. I'm using my AD2USB with my pi.

New to python but when I get my code cleaned up I'll share. I'm doing email based alerts, as well as using a JSON web service to talk to an android app I wrote that shows status and allows me to control the alarm.

I was at 100% cpu and just lived with it, but after reading this and updating the library it's running great!

Chris

[danimal1228]

Thanks for the update. CPU use dropped to almost nothing.

I am working on a logger w/ email alerts too. Ill post it once I test it a little more.

chrisinky, im interested to see how you implement the JSON interface.