Resend Ratio - What does this refer to?

Get Help
#1

What is the problem?

Unsure on what the Resend Ratio is referring to? Is it network related in regards to packets to the Pi? Or is it referring to and from Pi to the Printer?

On my last print, a simple tower test, I recieved over 30k resend rate. Is this bad?

What did you already try to solve it?
I have re-installed my OctoPrint via the OctoPi Image and changed the cable from my printer to my Pi with still the same results. Only a small variation in quality between printing from the SD from printing via Octoprint.

Have you tried running in safe mode?
No

Did running in safe mode solve the problem?
N/A

Additional information about your setup
OctoPrint version: 1.5.2
OctoPi version: 0.17.0
Printer:Ender 3 Pro
Main Board: BigTreeTex SKR Mini 3 v1.2
Firmware: Marlin 2.0
Browser: Safari
Operating system: OSX Big Sur

#2

It is between OctoPrint and the printer. 30k is quite high, but then it would be better to look at the percentage. Also check 30k was not the total number of lines sent, resend ratio is like this

resends/total lines (%rate) in the UI.

1 Like
#3

Thank you for the crazy quick response! Proving once again the 3D print community is the friendliest on the web.

Okay that makes a bit more sense. I believe then I mis-read it, it showed 0/32k 0%.
So as you explained that would mean that there was no re-sends and there is a good connection between printer and Pi.

1 Like
#4

I believe I am experiencing similar issues. This is my first print after upgrading to OctoPrint 1.5.2 last night. I'm not as savvy as most on here, but I'll try to provide the information I think is pertinent. I have a 0% resend ratio but I can't recognize any communication issues. I can send gcode commands and receive the expected responses. My print failed last night after what appears to be a timeout (the error message asked if my printer was still alive). I power-cycled my octopi and printer and edited my gcode to pick up where it left off. It restarted printing and then the printer stalled later after another communication style time out (still 0% resend). I've disconnected octopi and am printing caveman style from an SD card.

I am using a stock Creality CR-10 from ~5 years ago
Version 0.17.0, running on Raspberry Pi 3 Model B Rev 1.2

Things that have changed since the last time I used the printer:
I upgraded octopi to 1.5.2 ( I don't know what I was on previous to this, it's been almost a year since I've used my printer)
I am using the "TSD" App: Access Anywhere - The Spaghetti Detective : 1.4.7

#5

If you have 0%, this means you have no issue, not a similar one :slightly_smiling_face:

It is a percentage of total lines, showing how many are bad vs how many succeeded. 0% bad commands works. New feature in 1.5.x to display communication issues that might have been hidden. If you've got timeout issues, they are completely unrelated to resend requests.

#6

At least I lead in with "not being savvy".
Thanks for the quick response. I'll dig deeper and start a separate topic when I have more information. Sorry for the derail.

1 Like
#7

I was able to get my resend ratio down to 4% by replacing the basic power strip that both my Ender 3 Pro and my Rasberry Pi power supply were plugged into, by a more expensive one that has surge protection and more importantly an EMI filter.

Before that, I was constantly above 15% and Octoprint was basically unusable for me. I hope to get resend ratio down still from 4% to 0% as I am currently using a basic USB cable and have a shielded one with ferrite cores on order.
That should hopefully take care of the last little issues because my prints are no longer crashing but the printer still seems to sometimes pause for no reason so I get little blobs of filament there.

This is the extension socket I bought: Premium-Line 30.000A extension socket with surge protection 6-way black 3m H05VV-F 3G1,5 | brennenstuhl®

#8

Update, even though I did get resend ratio down to below 1% with the filtered extension socket and shielded USB cable with ferrite cores for the serial connection, I am still getting a lot of print artifacts and even failed prints.

Some further investigation showed me I am experiencing the same kind of issues that @koreth reported in https://community.octoprint.org/t/ender-3-v2-pi3b-or-pi4-lot-of-unknown-commmand-and-utf8-chars-electro-magnetic-interferences/24633/4 and I can trigger the garbled send/receive to occur in the same way by sending M17 / M18 commands.

I tried grounding the Raspberry Pi to the same ground as the printer internals by connecting GPIO39 (GND) to pin 2 (GND) on one of the unused connectors on my LCD display but that did not change anything unfortunately. Next step I will try is powering the Pi from the Ender 3 PSU, hopefully that will resolve the issue same way as it did for @koreth

#9

Oddly enough, switching from the stock Marlin firmware to Klipper seems to have taken care of my retransmission issues entirely.
Either that, or Klipper simply is not reporting on them. In any case, I have (touch wood) not seen any printing artifacts since changing to Klipper, so firmware is also potentially something one might want to look at.
For what it's worth, I am on an Ender 3 Pro with a 4.2.2 mainboard (aka the Ender 3 pro "1.5")

#10

I don't think Klipper will report resends to OctoPrint, since the resend would now happen between Klipper and the Klipper on the mainboard side, rather than between OctoPrint and the printer mainboard. It's highly unlikely that the communication between Klipper and OctoPrint would have to have resends.

But that's not to say it didn't solve the issue - the firmware absolutely could have been the issue, and the different implementation of Klipper resolved the artifact issue.

1 Like
#11

Thanks Charlie, I figured that's what might be going on.

Looking at /tmp/klippy.log it does seem to be showing some bytes retransmitted still but very very minimal, and this number seems to have been at 9 bytes from the moment the connection was first established (so not rising while I print)

Stats 6751.9: gcodein=3533617 mcu: mcu_awake=0.007 mcu_task_avg=0.000034 mcu_task_stddev=0.000041 bytes_write=16383893 bytes_read=2169649 bytes_retransmit=9 bytes_invalid=0 send_seq=284125 receive_seq=284125 retransmit_seq=2 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=72000353 heater_bed: target=50 temp=50.0 pwm=0.141 print_time=6782.238 buffer_time=2.242 print_stall=2 extruder: target=220 temp=219.9 pwm=0.742 sysload=0.16 cputime=271.281 memavail=3583668

Octoprint is remaining at 0 resend, so I'm going to conclude that the issue is gone and the 9 bytes retransmitted are just a remnant of the serial connection being established when the printer was first powered on.

I still plan to power the Pi from the Meanwell PSU via an LM2596 buck converter, if only to have everything powered from a single lead instead of still having the separate power adapter for the Raspberry Pi.

1 Like