btmon3.py waiting for blocking reads?
Posted: Tue Mar 19, 2024 4:58 pm
Hello,
I have just recently installed the btmon3.py in "server" mode on a local server with packet forwarding set up from my dashbox so that btmon3.py can provide a more frequent MQTT update than what the built-in MQTT module on the Dashbox provides. While the Dashbox is set to transmit real-time data to the IP address of the server hosting the btmon3.py script (every 5 seconds - and I can confirm that it's arriving every 5 seconds with tcpdump on that server), the btmon3.py seems to be stuck in blocking read mode twice: once the incoming data is received and again before processing the incoming data.
With two terminal windows open, one watching tcpdump to see the incoming packets every 5 seconds and the other watching the debug output from btmon3.py, the btmon3.py output only jumps in tandem with the incoming data. This suggests that it's getting stuck in a blocking read before continuing on to process incoming data.
It will start with "SOCKET: waiting for connection" and sits there until a packet comes in (this is fine). Once the packet arrives it will display "waiting for data from device" and "reading 1 of 1 packets" together and then just sits there stuck until the next packet arrives 5 seconds later. Once that arrives, it will send the data to the MQTTprocessor and the sit and wait with "SOCKET: waiting for connection" again. The next cycle has to wait 5 seconds for another packet to arrive, then 5 seconds for the packet to be read, then another 5 seconds to send it to processing to then start the cycle again. The effect is min 15 seconds between MQTT updates.
I would expect that once the data is received, the script should process it without delay and then sit and wait for data again. I am consistently missing two out of every three update packets sent by the dashbox. For my need, I was hoping to catch the updates every 5 seconds and send them to the MQTT server.
Would more familiar eyes on the btmon3.py script be able to pinpoint the bottleneck?
Thank you.
Shane.
I have just recently installed the btmon3.py in "server" mode on a local server with packet forwarding set up from my dashbox so that btmon3.py can provide a more frequent MQTT update than what the built-in MQTT module on the Dashbox provides. While the Dashbox is set to transmit real-time data to the IP address of the server hosting the btmon3.py script (every 5 seconds - and I can confirm that it's arriving every 5 seconds with tcpdump on that server), the btmon3.py seems to be stuck in blocking read mode twice: once the incoming data is received and again before processing the incoming data.
With two terminal windows open, one watching tcpdump to see the incoming packets every 5 seconds and the other watching the debug output from btmon3.py, the btmon3.py output only jumps in tandem with the incoming data. This suggests that it's getting stuck in a blocking read before continuing on to process incoming data.
It will start with "SOCKET: waiting for connection" and sits there until a packet comes in (this is fine). Once the packet arrives it will display "waiting for data from device" and "reading 1 of 1 packets" together and then just sits there stuck until the next packet arrives 5 seconds later. Once that arrives, it will send the data to the MQTTprocessor and the sit and wait with "SOCKET: waiting for connection" again. The next cycle has to wait 5 seconds for another packet to arrive, then 5 seconds for the packet to be read, then another 5 seconds to send it to processing to then start the cycle again. The effect is min 15 seconds between MQTT updates.
I would expect that once the data is received, the script should process it without delay and then sit and wait for data again. I am consistently missing two out of every three update packets sent by the dashbox. For my need, I was hoping to catch the updates every 5 seconds and send them to the MQTT server.
Would more familiar eyes on the btmon3.py script be able to pinpoint the bottleneck?
Thank you.
Shane.