Klipper: Can the comms 'buffer' size be increased?

[ProfEngr]

I figured it would be better if I created a new 'issue' instead of commenting on the closed one about nozzle stuttering under Octoprint. It's a known issue that Octoprint doesn't handle comms to Klipper any better than it does with Marlin. However, with Marlin there's a buffer that can be increased to help smooth out the hesitation in the gcode stream from Octo.

Is there a similar feature in Klipper that could be adjusted to perform the same function as in Marlin? It seems so strange that stuff like this is even an issue to contend with these days. I can throw more horsepower (a NUC) at Octo, but I don't know if that'll make any difference.

[klipper-gitissuebot]

Hi @ProfEngr,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[DeviousPenguin]

I have experienced this buffer underrun occasionally, and in fact you can already workaround this in Klipper by using the 'virtual SD card' feature. However if you use this you lose quite a few octoprint features, it would be nice to have a better fix.

[ProfEngr]

That was my point. I know about the SD option, but don't want to lose Octo functions.
And wake up ya dumb gitissuebot, there's no need for a log file. It's a simple question for the dev if an option exists.
Maybe I should ask the discord instead?

[johngianni]

[printer]

buffer_time_high: 10

Try the above trick... Be prepared to have slower response to the Octoprint commands during prints (ie cancel print)

[ProfEngr]

[printer]

buffer_time_high: 10

Thanks. Will give it a go. I did a keyword search in the git files, but I must not have been in the right ones.

[ProfEngr]

That seems to have worked a treat, @johngianni

[lar3ry]

[printer]

buffer_time_high: 10

Try the above trick... Be prepared to have slower response to the Octoprint commands during prints (ie cancel print)

Any idea what the default is, if you don't override it?

[ld3300]

Looks like it is 2. toolhead.py

[lar3ry]

Looks like it is 2. toolhead.py

Spotted that after I posted this. I still wasn't sure. I'm not very conversane with Python.
Thanks for reponding.

[JohnEdwa]

It's a known issue that Octoprint doesn't handle comms to Klipper any better than it does with Marlin. However, with Marlin there's a buffer that can be increased to help smooth out the hesitation in the gcode stream from Octo.

It actually handles it much better, in a way. Octo -> Marlin has the issue that the ascii gcode is being transmitted through the actual physical serial connection from the raspi to the printer to be processed by Marlin, so that throughput is limited by what the printer MCU can actually receive. The Marlin buffer is there just to allow Octoprint to send commands in advance during slower sections so when the transmit rate isn't enough, there is, well, a buffer of commands.

But with Klipper, Octoprint sends that Gcode through a virtual port inside the raspi to the Klipper process, which then sends only the stepper motor timing pulses to the printer. IIRC that virtual serial port defaults to 250kbaud, but I don't see why it couldn't be greatly increased if needed.

[ProfEngr]

The thing is, when the nozzle pauses for this buffer underrun or whatever the root cause is, the Octo process peaks over 100% in top; python is always under 5%. The USB link was never the issue as even 115200bps can transfer far more data than most consumer printers can physically process. Octo seems to have issues processing the volume of gcode data for complex geometey at high speeds.

I tried printing the vase mode pyramid from thingiverse. Right before I canceled the print I was at an FR of 50% w/ a base slicer setting of 60mm/s and still getting frequent pauses.

[JohnEdwa]

The USB link was never the issue as even 115200bps can transfer far more data than most consumer printers can physically process

Not really, because the density of these commands varies by multiple orders of magnitude. Your first layer of "lines" skin feature is a single Gcode command that tells the printer "You are here, move 200mm there at 100mm/s" which takes 2 seconds to process this single command.
But anything round is "You are here, now move 0.1mm there, then 0.1mm there then .1mm there then 0.1mm there then 0.1mm there" over and over and over again. In that same 200mm length feature printing at 100mm/s, there is now suddenly 2000 Gcode commands to transmit and process in 2 seconds.

G1 X108.015 Y128.804 E2.91445 is 29 characters long, so 1000 of these is 29000 ascii characters to transmit in one second. If single byte takes a start bit, 8 bits of data and an end bit, that is 290000 bits of data in a single second. And that is completely ignoring that there are checksums, acnowledgements and so on.

[ProfEngr]

@JohnEdwa I sit corrected then. Thanks for crunching the numbers. 250kbps will be needed even with moderately sized buffers.

[GarthSnyder]

/tmp/printer is a pseudoterminal, so although it has the same API as a serial port and that API includes the ability to set a baud rate, I don't think the baud rate has any actual effect.

Do you have reason to believe there is in fact a bottleneck at the PTY, or is this concern hypothetical? If the former, it's likely got something to do with buffering. If the receiver (Klipper) isn't reading data fast enough, the sender's writes will eventually block.

[mental405]

Baud Rate between Octoprint to Klipper is really about how fast Octoprint can read gcode from a file and write it back to the virtual serial port. The virtual serial port, for all intents and purposes, is a file.
So when you hit the print button in Octoprint, it is reading the gcode file and then writing it out again.

Klipper on the other hand uses the serial connection between the board and the pi over the USB port, but it is not sending gcode. It is using its own protocol as described in the docs.

https://github.com/KevinOConnor/klipper/blob/master/docs/Protocol.md#message-blocks

Whereas GCODE is uncompressed ASCII text 1 character = 1 byte like JohnEdwa described, the Klipper protocol message size is typically much smaller as contents are encoded. When these commands are sent to the board, most everything that needs to be calculated has already been calculated.

The bottleneck is typically in Octoprint's inability to send gcode quickly enough. You can test this for yourself by enabling the Virtual SD Card feature which sounds complicated but all it does is just has klipper read the gcode directly from the file instead of the virtual serial port.

[JohnEdwa]

Baud Rate between Octoprint to Klipper is really about how fast Octoprint can read gcode from a file and write it back to the virtual serial port. The virtual serial port, for all intents and purposes, is a file.

But does Octoprint know and treat it as such?
Because from it's point of view it is connecting to a bog-standard serial port at 250kbaud, and as one important part of serial communication is that everything has be absolutely perfectly in sync as far as the speed goes, Octoprint would limit the rate it writes at that 250kbaud, right?

Because if the calculations I did above are correct, with fast enough speed (+100mm/s) combined with round features and the default precision of Cura (0.05mm), the result would be capable of saturating a connection limited to 250kbaud transfer rates, which would mean upping the virtual connection between Octo and Klipper to something higher could be beneficial.

[KevinOConnor]

Octoprint would limit the rate it writes at that 250kbaud, right?

No. The pseudo-tty has no speed limit, and OctoPrint does not pace writes. The only limitation is the CPU performance of OctoPrint, which is unfortunately a notable limitation. Basically, the printer moves faster than OctoPrint can send commands to Klipper.

-Kevin