Deploying to gh-pages from @ Klipper3d/klipper@28faf81414 🚀

CANBUS_Troubleshooting.html

@@ -1498,19 +1498,17 @@ transmit any messages) and is not directly related to Linux
 link show can0</code>. It should report a bunch of text including the
 snippet <code>qlen 128</code>. If one sees something like <code>qlen 10</code> then it
 indicates the CAN device has not been properly configured.</p>
-<p>It is not recommended to use a <code>txqueuelen</code> significantly larger than</p>
-<ol>
-<li>A CAN bus running at a frequency of 1000000 will typically take
-around 120us to transmit a CAN packet. Thus a queue of 128 packets is
-likely to take around 15-20ms to drain. A substantially larger queue
-could cause excessive spikes in message round-trip-time which could
-lead to unrecoverable errors. Said another way, Klipper's application
-retransmit system is more robust if it does not have to wait for Linux
-to drain an excessively large queue of possibly stale data. This is
-analogous to the problem of
+<p>It is not recommended to use a <code>txqueuelen</code> significantly larger
+than 128. A CAN bus running at a frequency of 1000000 will typically
+take around 120us to transmit a CAN packet. Thus a queue of 128
+packets is likely to take around 15-20ms to drain. A substantially
+larger queue could cause excessive spikes in message round-trip-time
+which could lead to unrecoverable errors. Said another way, Klipper's
+application retransmit system is more robust if it does not have to
+wait for Linux to drain an excessively large queue of possibly stale
+data. This is analogous to the problem of
 <a href="https://en.wikipedia.org/wiki/Bufferbloat">bufferbloat</a> on internet
-routers.</li>
-</ol>
+routers.</p>
 <p>Under normal circumstances Klipper may utilize ~25 queue slots per
 MCU - typically only utilizing more slots during retransmits.
 (Specifically, the Klipper host may transmit up to 192 bytes to each