[BUG] Slow Upload speed on MK4 firmware 5.0.0

[jeromeajot]

Please, before you create a new bug report, please make sure you searched in open and closed issues and couldn't find anything that matches.

Printer type - Original Prusa MK4

Printer firmware version - 5.0.0+12061

Original or Custom firmware - Original

Optional upgrades - None

USB drive or USB/Octoprint USB Flash Drive / Upload via PrusaSlicer 2.6.1

Describe the bug Uploading gcode from PrusaSlicer take a long time. The MK4 is ethernet wired. On 4.7.2, it was already slow to send gcode but it was manageable. On 5.0.0, it became worse. Averaging at 40-50 kB/s, it makes this capability useless. A 60 MB G-code took more than 22 minutes to upload.

How to reproduce Upload gcode to the MK4 using 5.0.0 firmware.

Expected behavior Due to questionable hardware choices, 8 MB/s. As a customer, I expect 110 MB/s upload speed.

G-code Any G-code.

Crash dump file N/A

Video N/A

Additional Notes The MK4 is using a HR911105A RJ45 connector, which is a 10/100base-T, this explains why my switch was blinking orange, detecting it as 100base-T. I think that this is a design flaw to have selected, in 2023, a slow connector, when the intent of this connection is to transfer large G-code files. When someone advertises "Ethernet and Wi-fi connection", I expect a wired gig transfer rate, not a 1995 hardware spec delivering 1980s speed.

[tkircher]

Yes, the ethernet and wifi are only technically true. There's a real ethernet PHY and wifi radio but they both interface to the microcontroller through a slow serial connection. There is no way to fix this, it is already as fast as possible.

One solution, which many people have posted about elsewhere, is to use a SBC like a Raspberry Pi to simulate a USB drive using OTG. Then you have real ethernet and wifi, and the printer will see the files over the USB interface which is relatively faster; the hardware only supports 12Mbit USB, but because the gcode is read a bit at a time, the USB speed matters less. You can transfer arbitrarily large files instantly to your SBC, it will show up on the virtual USB drive, making them available to print using the built-in Prusa web interface or the console.

The advantage to doing it this way is that Octoprint is not currently functional enough to use by itself. Reportedly, Prusa has made supporting it a priority and will include all the necessary basic functionality in firmware 5.1, and I think that's probably true because they seem to have realized they made a mistake.

[arekm]

OTG is not a solution for some cases because you loose "Power panic" feature. Are you sure ethernet PHY is connected via serial and not directly (so DMAble) ? Didn't seem so when looking at firmware source code.

[tkircher]

You don't lose the power panic feature, unless your SBC blinks out before the printer does. Use a UPS like most of us and it's fine.

The STM32F427 in the MK4 does have DMA, but it doesn't matter. See the reference manual for details.

[arekm]

Without UPS. With UPS there is no need for power panic feature. Thanks for useless "see (1751 pages) manual".

[tkircher]

There's basically no need for power panic in general. There's another discussion thread here on how to disable it without making the printer complain. With a proper UPS you can even detect (with Octoprint) whether a print will finish in time, and if the power stays out for too long and the UPS battery goes too low you can save state. If your power is poor enough that you have regular glitches that the printer can't handle, your electronics will end up destroyed anyway if you don't have a UPS.

The STM32F4 manual I linked is organized into sections, look at the index on the left. Scroll down to the section heading that says Ethernet and DMA. The open TCP/IP implementation that Prusa decided to use is called LwIP, which you can find referenced in the firmware code. It uses DMA and zero-copy RX and is not too bad. From the commit logs it looks like Prusa has optimized it for their specific use, and yet it's still slow due partly to hardware and partly to unavoidable architectural issues with the firmware, none of which is practically fixable.

[arekm]

I repeat again: without UPS.

Electronics won't be destroyed if "glitches" equals power missing sometimes (and no overvoltage spikes).

Anyway back to main question - where is that information about "ethernet PHY ... interface to the microcontroller through a slow serial connection" ? I don't see that in mentioned section of manual (or any other section).

[vgroenewold]

I was surprised by this as well, I specifically bought an ethernet cable to upload from my PC, but now resorted to manually delivering the USB drive. That is about 20x faster. :) If this is due to the hardware, then that's a pitty, though Prusalink still works fast enough.

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[github-actions[bot]]

This issue has been closed due to lack of recent activity. Please consider opening a new one if needed.