Deploying to gh-pages from @ Klipper3d/klipper@383b83d788 🚀

zh/CANBUS_Troubleshooting.html

@@ -1280,8 +1280,8 @@
 </li>
       
         <li class="md-nav__item">
-  <a href="#use-an-appropriate-txqueuelen-setting" class="md-nav__link">
-    Use an appropriate txqueuelen setting
+  <a href="#txqueuelen" class="md-nav__link">
+    使用适当的 txqueuelen 设置
   </a>
   
 </li>
@@ -1426,8 +1426,8 @@
 </li>
       
         <li class="md-nav__item">
-  <a href="#use-an-appropriate-txqueuelen-setting" class="md-nav__link">
-    Use an appropriate txqueuelen setting
+  <a href="#txqueuelen" class="md-nav__link">
+    使用适当的 txqueuelen 设置
   </a>
   
 </li>
@@ -1492,17 +1492,17 @@ resistors</a> on the CAN bus. If the resistors are not properly installed then m
 <li>已知一些用于嵌入式设备的Linux内核版本会对CAN总线消息进行重新排序。可能需要使用替代的Linux内核，或者使用支持不存在此问题的主流Linux内核的替代硬件。</li>
 </ol>
 <p>重新排序的消息是一个必须解决的严重问题。这将导致行为不稳定，并可能导致打印的任何部分出现令人困惑的错误。</p>
-<h2 id="use-an-appropriate-txqueuelen-setting">Use an appropriate txqueuelen setting<a class="headerlink" href="#use-an-appropriate-txqueuelen-setting" title="Permanent link">&para;</a></h2>
-<p>The Klipper code uses the Linux kernel to manage CAN bus traffic. By default, the kernel will only queue 10 CAN transmit packets. It is recommended to <a href="CANBUS.html#host-hardware">configure the can0 device</a> with a <code>txqueuelen 128</code> to increase that size.</p>
-<p>If Klipper transmits a packet and Linux has filled all of its transmit queue space then Linux will drop that packet and messages like the following will appear in the Klipper log:</p>
+<h2 id="txqueuelen">使用适当的 txqueuelen 设置<a class="headerlink" href="#txqueuelen" title="Permanent link">&para;</a></h2>
+<p>Klipper 代码使用 Linux 内核来管理 CAN 总线流量。默认情况下，内核只会排队 10 个 CAN 传输数据包。建议使用 <code>txqueuelen 128</code> <a href="CANBUS.html#host-hardware">配置 can0 设备</a> 来增加该大小。</p>
+<p>如果 Klipper 传输了一个数据包，而 Linux 已经填满了其所有的传输队列空间，那么 Linux 将丢弃该数据包，并且 Klipper 日志中将出现如下消息：</p>
 <div class="highlight"><pre><span></span><code>Got error -1 in can write: (105)No buffer space available
 </code></pre></div>
 
-<p>Klipper will automatically retransmit the lost messages as part of its normal application level message retransmit system. Thus, this log message is a warning and it does not indicate an unrecoverable error.</p>
-<p>If a complete CAN bus failure occurs (such as a CAN wire break) then Linux will not be able to transmit any messages on the CAN bus and it is common to find the above message in the Klipper log. In this case, the log message is a symptom of a larger problem (the inability to transmit any messages) and is not directly related to Linux <code>txqueuelen</code>.</p>
-<p>One may check the current queue size by running the Linux command <code>ip 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 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.</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 Klipper MCU before receiving an acknowledgment from that MCU.) If a single CAN bus has 5 or more Klipper MCUs on it, then it might be necessary to increase the <code>txqueuelen</code> above the recommended value of 128. However, as above, care should be taken when selecting a new value to avoid excessive round-trip-time latency.</p>
+<p>作为其正常应用程序级消息重传系统的一部分，Klipper 将自动重传丢失的消息。因此，此日志消息是警告，并不表示不可恢复的错误。</p>
+<p>如果发生 CAN 总线完全故障（例如 CAN 线路断线），则 Linux 将无法在 CAN 总线上传输任何消息，并且通常会在 Klipper 日志中找到上述消息。在这种情况下，日志消息是更大问题的征兆（无法传输任何消息），与 Linux <code>txqueuelen</code> 没有直接关系。</p>
+<p>可以通过运行 Linux 命令“ip link show can0”来检查当前队列大小。它应该会报告一堆文本，包括代码片段“qlen 128”。如果看到类似“qlen 10”的内容，则表明 CAN 设备尚未正确配置。</p>
+<p>不建议使用明显大于 128 的 <code>txqueuelen</code>。以 1000000 频率运行的 CAN 总线通常需要大约 120us 来传输 CAN 数据包。因此，128 个数据包的队列可能需要大约 15-20ms 才能耗尽。大得多的队列可能会导致消息往返时间出现过度峰值，从而导致无法恢复的错误。换句话说，如果 Klipper 的应用程序重传系统不必等待 Linux 耗尽可能过时的过大队列，它会更加强大。这类似于互联网路由器上的 <a href="https://en.wikipedia.org/wiki/Bufferbloat">bufferbloat</a> 问题。</p>
+<p>在正常情况下，Klipper 可能每个 MCU 使用约 25 个队列槽 - 通常仅在重传期间使用更多槽。（具体而言，Klipper 主机可能向每个 Klipper MCU 传输最多 192 个字节，然后才会收到该 MCU 的确认。）如果单个 CAN 总线上有 5 个或更多 Klipper MCU，则可能需要将<code>txqueuelen</code>增加到建议值 128 以上。但是，如上所述，选择新值时应小心谨慎，以避免过长的往返时间延迟。</p>
 <h2 id="candump">获取candump日志<a class="headerlink" href="#candump" title="Permanent link">&para;</a></h2>
 <p>向微控制器发送和从微控制器发送的CAN总线消息由Linux内核处理。出于调试目的，可以从内核捕获这些消息。这些消息的日志可能在诊断中有用。</p>
 <p>Linux<a href="https://github.com/linux-can/can-utils">can-utils</a>工具提供了捕获软件。通常通过运行以下命令将其安装在计算机上：</p>