I was running Octoprint 0.9 for about 3 years with these settings:
Communication timeout: 15 s
Connection timeout: 8 s
Autodetection timeout: 4 s
(It wasn't much documented so I increased all of them)
I recently changed to the latest version. It already has higher values than these by default (except for autodetection timeout). I still doubled them for good measure 
But these linuxcnc machines are not running marlin on atmega chips, right?
neither is klipper. linuxcnc machine will send data trough isa/pci/usb/ethernet/serial to external stepper generator (e.g. mesa card) so all the calculation is done on a linux box by linuxcnc and step generator is done by external card. mach3/4 for e.g. also can talk to external step generators via modbus or rs485 or usb so you have calculation done by windows box and steps being generated by external devices... klipper is doing same thing, it runs calculation on any linux box (e.g. rpi or opi or something stronger if you like) and it uses external stepper generator via usb, what's interesting about klipper is that they have firmware (not marlin, not even close to marlin) for external stepper generator for your regular atmega boards... so you can convert your ramps, melzi... 8bit atmega board into simple step generator (you put the firmware designed by klipper crew) and you use klipper on the rpi to do the calculation and send step generator instructions...
8bit atmega is more than capable of being a step generator for speeds we use in 3d printing 
so no worries there 
you'll love it .. just make sure about 2 things
Some control boards can be mounted as a USB mass storage device. One way around the problem with performance of Upload to SD is to use the file system rather than a serial transfer to the printer. This should be easy to achieve my Re-ARM board running Marlin 2.0. Send G22 to release the SD card, mount the USB mass storage device, transfer the file, then send a G21 to initialize the SD card within Marlin.
@dmulligan That's awfully hacky when you could just do what I do for the same effect, with higher speeds and far fewer steps:
I run them on all my printers, using a microSD <-> SD adapter for boards that can only use microSD (CR-10S, for a modern example). I have a static DHCP assignment for their MACs (and another for the Pis that run their associated OctoPrint instances), set them up a single time and plug them in, and then that's it...I can simply mount them via WebDAV on boot, slice directly to the SD card over WiFi, and kick off and monitor an SD card print via OctoPrint.
The only real issues are with machines running firmware that doesn't give good status updates to OctoPrint during the print or that can't be interrupted by OctoPrint, both of which can be addressed by other methods (often suboptimally, but come on...people have been making machines that can burn your house down while leaving out basic safety features like watchdog timers, thermal runaway protection, and stall detection for years).
@supertaz It is not hacky at all. Only one OS can access a block device, such as a SD card, at a time. M21 and M22 can be thought as unmount and mount device commands from the point of view of Octoprint.
I have experienced this issue. Here is the same print over USB(top) and direct from SD card(bottom).
The USB print was frozen/non-functional and shows blobbing/zitting. It also took almost two hours longer than the estimated print time. The second print from the SD Card yielded a noticeably better/functional result which completed at the estimated time. Furthermore the print head movement was much smoother.
I'm not positive that the Raspberry Pi is not also contributing to the issue. At the time of the printing, MJP-stream was also running. It's possible that the Pi was just swamped. I intend re-test with OctoPrint running on better hardware but, given what I have seen online so far, my results seem to support the USB data transfer limitation.
The weakness of printing via USB is that gcode with many short segments can overwhelm the "serial over USB" interface. This looks like one of those cases.
The major bottleneck is from the ping pong approach. Usb adds latencies in the serial communication. A bulk/interrupt transfer is for full speed usb only scheduled every 1ms, meaning we get 2ms turnarround time at least to get an OK reply back.
This can be seen when e.g. Replacing the usb to serial with a native serial port from raspberry - I don't get any blobs anymore.
An improvement to get arround those latencies also for usb 2 serial converters would be to support the ADVANCED_OK feature of Marlin, this one prints the internal buffer status, so that the host know how much it can still feed the buffer until it oberflows.
Reporting of the availability of this feature is also done via M115.
Are there any plans to support advanced ok in future?
Still the major cause of all issues are the "interesting" choices of the communication protocol on Marlin. Instead of using one of the normal serial handshaking mechanisms, a new "ok" ping pong scheme was invented, making life much more difficult.
A nice rts/cts or xon/xoff scheme would have prevented such issues.
Best regards,
Kai
Found this here:
Is this integrated in any available version of Octoprint? E. G. one of the release candidates?
I will get my pandaPi board very soon it is a shield for the pi.
With it you can run Marlin 2.0 and octoprint directly on the pi.
Lets see if it is better ...
No, the PR is still working and has been marked to "needs more work": https://github.com/foosel/OctoPrint/pull/3209
Thanks, so I stick to my native UART approach. Btw. It is feasible to access hw wise on a raspberry pi 3 the 2 UARTs at the same time, as long as you don't require Bluetooth. The 2nd UART gpios are not accessible on pin headers, but with some reverse engineering involving raspi-gpio and a scope they can be found easily and made available with a small patchwire.
Now, that I have 2 uarts working, I don't require advanced communication anymore 
Best regards,
Kai
Does this mean that if I connect raspi directly to SKR 1.3 using RX/TX pins on both then there will be no bottleneck and quality from OctoPrint would be identical to that from SD?
It's not the connection: It's the transfer protocol and the 8-bit processor power of the printer boards that is driven at it's edge.
USB alone is fast enough and with a 32-bit board it should work quite well.
AFAIK there are not enough tests made with 32-bit boards concerning this problem (less quality when printing over USB).
I print for years on 32bit boards and never had this problem
Great to know! And you are using standard USB connection?
Yes, usb is indeed itself fast enough in terms of transfer speed, but has no low enough latency. Speed and latency is a major difference. Due to the fact that we are not writing a stream of data, but have interruptions by the ping pong approach these latencies matter a lot and get dominant, if short line segments are part of the print.
Latency is the time between the raspberry starts a serial write towards when the serial data comes out of the port.
For full speed usb this will take arround 1ms, for high speed usb (usually 3d printer devices are full speed) 1/8ms.
Those latencies are inherent to the USB standards and cannot be made smaller.
As there is also a phase of read you'll get those latencies twice. Here it also matters which polling interval is setup in the cdc interrupt endpoint - it can in total even be more than 2ms of "pause" in the communication.
With a local serial port those latencies are much lower. You will get a few microseconds likely.
Yes, you can directly use a PI serial port and you will get much better results. Have improved 2 printers with this. They prints now like from sd card.
Developed a lot custom usb devices and usb stacks in the past, but it is up to you to trust this or not. I think we all agree to, that using a local uart will not hurt for cases, where just an ftdi or ch340 or similar usb uart is used on the orinters board.
yes, smoothieware on smoothieboard, smoothieware on teartime modded to run it ... normal usb connection from both rpi and opi sbm
