recently I read this article here: https://discourse.octoprint.org/t/the-ongoing-usb-conspiracy-theory/6341/65
I see these type of problems when using octoprint on a fine mesh typically. The printer slows down and cannot work fast further as the internal buffer is almost empty. OK, this is not intended, all right.
The reason for the low level buffer can be either the octoprint server is not capable to deliver sufficient many lines of g code in a given time period (i.e. the CPU/IO scheduler of the RPI is overloaded) or the problem is the communication itself (i.e. the USB line is the bottle neck).
In the above mentioned link the main reason for these type of errors are assumed to be of the way of transport. So the educated guess in this topic (I just call it like this, no offence) is that the USB is not capable of transferring sufficiently data over the line.
In my setup I see quite some load on the small RPI. It gets laggy while printing etc. When monitoring the RPI's health state, I would assume problems with real-time processes anyway. However I am not perfectly sure, if this is true.
As I play with the idea to upgrade the hardware (either orangepi or even a small i386 based solution), I would like to know if the problem is of computational nature (the RPI is simply too weak) or a problem of the USB connection. In the latter case, the upgrade might be useless.
To get a reliable statement, I would like to measure some timings. How many bytes are transmitted per second (to compare with the baud rate)? How long does octoprint wait for confirmation by the printer's firmware? How long does the transmission itself take (compared to the overall transmission-waiting-confirmation cycle)?
Do you have any idea to get a bit more insight here?