Linux 的 DSL HOWTO
上一页下一页

5. 性能调优和故障排除

5.1. 调优

好的，现在我们已经启动并运行了，并且我们希望以九级速度运行。速度再快也不为过，对吧？

Linux 网络非常强大，即使是默认安装，没有进行任何“调优”。您可能根本不需要做任何其他事情。但是，如果您的连接性能没有达到您认为应该达到的水平，那么可能在某个地方存在问题。与追求任何神奇的“调整”相比，这可能是一种更有价值的方法。

关于您可能合理期望的最大同步速率的非常粗略的指南，基于与 DSLAM/CO 的距离

0-12 千英尺 (0-3.6 公里)���������2000 Kbps 或更高 (ADSL 最大 8100)
12-16 千英尺 (3.6-4.6 公里)���������1500 Kbps 到 1000 Kbps
16-18 千英尺 (4.6-5.4 公里)���������1200 Kbps 到 512 Kbps
18-?? 千英尺 (5.4-?? 公里)���������512 Kbps 到 �128 Kbps 或更低 :(

可能有许多可以单方面影响这种情况的因素。更新一代的 DSL 肯定会改善这种情况，相关的技术如中继器也会如此。

您将损失调制解调器可达到的同步速率的 10-20% 用于网络开销（TCP、ATM、以太网）。因此，1500 Kbps 的连接，实际上只能实现约 1100-1300 Kbps 左右的实际吞吐量。任何调整都无法改变内置的协议开销。此外，如果您的服务被提供商限制在较低的速度，那么无论如何您都无法超过该速度。并且 - 存在许多变量会影响您的环路/信号质量，并因此影响您的速度（又名同步速率）。其中一些可能超出您的控制范围。

但是，有一些事情您可能需要关注。

5.1.1. TCP 接收窗口

对于我们中的许多人来说，默认的 Linux 安装将提供接近最佳的性能。Windows 9x 用户通常可以通过增加他们的 TCP 接收窗口 (RWIN) 来获得很大的提升。但这仅仅是因为它一开始太小了。Linux 的情况并非如此，Linux 的默认值为 32KB。

这里的一个例外是，如果您必须经常处理高延迟连接。例如，如果您的提供商有一个卫星上行链路，该上行链路始终如一地增加异常延迟（250 毫秒或更长时间？）。那么，更大的 TCP 窗口可能会有所帮助。有关 TCP 接收窗口和相关问题的更多信息，请查看http://www.psc.edu/networking/perf_tune.html。

接收窗口是一个有助于控制数据流的缓冲区。如果设置得太低，它可能会成为瓶颈并限制吞吐量。此最佳值完全取决于您的带宽和延迟。延迟是您根据您的典型目的地和条件找到的平均往返时间 (RTT)。这可以通过 ping 来确定。例如，Linux 默认值 32KB 在高达 2 Mbps 的速度和约 125 毫秒的典型延迟，或 1.0 Mbps 和 250 毫秒的延迟下是可以接受的。将此值设置得太高也可能对吞吐量产生不利影响，因此不要过度。

新西兰 Juha Saarinen 提供的一个例子

常用的计算 tcp 缓冲区大小的公式是“带宽延迟乘积”公式

������缓冲区大小 = 带宽 (bits/s) * RTT (秒)

就我而言，我大约有 8Mbps 的下游带宽，但 ATM 网络只能支持约 3.5Mbps 的持续带宽。我离世界其他地方很远，所以为了挤入足够数量的 1,500 字节数据包，平均 RTT 为 250 毫秒，我可能应该有一个 (3,500,000/8)*.25 = 106KB 的缓冲区。（我现在有 128KB，效果很好。）

接收窗口可以在 /proc 文件系统中动态设置。这需要输入一个值为所需缓冲区大小两倍的值

 #echo 262144 > /proc/sys/net/core/rmem_default 
 #echo 262144 > /proc/sys/net/core/rmem_max

上面的例子实际上将值设置为 128K。发送窗口也可以设置，但在 DSL 连接上，它不太可能成为像接收窗口那样的限制因素

 
 #echo 262144 > /proc/sys/net/core/wmem_default 
 #echo 262144 > /proc/sys/net/core/wmem_max

这些值也可以使用 sysctl 命令设置。请参阅手册页。

对于那些想要从铜线中挤出最后一点性能的用户，还有其他建议的内核选项（仅选择条目）

 # sysctl -a 
 net.ipv4.tcp_rfc1337 = 1
 net.ipv4.ip_no_pmtu_disc = 0
 net.ipv4.tcp_sack = 1
 net.ipv4.tcp_fack = 1
 net.ipv4.tcp_window_scaling = 1
 net.ipv4.tcp_timestamps = 1
 net.ipv4.tcp_ecn = 0

这些选项和其他选项的简要说明可以在以下位置找到/usr/src/linux/Documentation/networking/ip-sysctl.txt，在内核源代码目录中。

5.1.2. 交织

“交织”是 ADSL 与 DMT 线路编码的一种错误控制机制。DMT 现在是 ADSL 的标准，并且是迄今为止最普遍的 ADSL 形式。交织缓冲原始数据并在 DSLAM 处动态纠正错误。这可以显着帮助可能容易出现线路错误的边缘环路。缺点是这种缓冲也会给连接增加显著的延迟。因此，对于那些线路质量良好的人来说，交织没有任何实际好处，并且实际上可能会增加不必要的延迟。

交织是一个可调整的参数，可以由电信公司打开或关闭。许多电信公司似乎喜欢默认情况下开启此功能，因为它可能会减少在确实有助于稳定线路的情况下技术支持的电话。但其他所有人都为此付出了代价。

如何知道您的线路是否交织，以及如何更改它？好问题。一般来说，如果您的 traceroute 上的第一跳或第二跳小于 25 毫秒左右，您几乎可以确定交织是关闭的。但是，可能还有其他因素，例如这些跳实际上有多远。除非您的调制解调器准确报告了这一点，否则唯一真正知道的方法是与电信公司的人交谈。这可能说起来容易做起来难。

“FastPath” DMT 与“交织关闭”是同义词。同样，这仅适用于 ADSL/DMT。

5.1.3. TCP 瓶颈

DSL 连接在某些情况下可能会出现性能下降。值得庆幸的是，Linux 拥有非常强大和灵活的网络工具来帮助我们应对这些问题。

一种常见的场景是，当来自快速网段的数据到达较慢的网段时，就会产生流量瓶颈。例如，以太网撞击 DSL 调制解调器/路由器。这可能会导致短期的流量积压，在设备中称为“队列”。排队可能会导致性能下降，特别是对于交互式协议（如 telnet 或 ssh）和流媒体协议（如 RealAudio），并增加 ICMP 和其他网络协议的延迟。当上行链路饱和时，这种情况最明显（因为下行数据在 ISP 端排队，我们对此无能为力）。排队的流量被处理，使得较低流量的协议（如 ssh）通常会被较高流量的批量流量（如 http 或 ftp）所淹没，因为在默认使用中没有任何特殊的优先级排序。

如果上行排队或其他因素导致了足够的延迟，它甚至会通过减慢保持下载以最佳速率移动所需的确认 (ACKnowledgements)（这些确认正向上行方向发送）来降低下行带宽利用率。因此，上传可能会损害同时进行的下载。

这种影响可以在很大程度上通过 Linux 内置的流量整形能力来缓解。用于操作内核高级流量路由功能的用户空间工具是 iproute，有时打包为 iproute2。这包括各种工具，可以相当灵活地对流量进行分类和优先级排序。它还需要打开各种内核配置选项。并且也相当接近黑魔法 ;-) 关于此的权威文档是高级路由和流量控制 HOWTO (https://tldp.cn/HOWTO/Adv-Routing-HOWTO.html)。特别注意 “食谱” 第 15 节，特别是第 15.8 节，“终极流量调节器：低延迟、快速上传和下载”。非常值得一读！

5.1.4. PPP 连接掉线

PPPoE 和 PPPoA 都依赖于久经考验的 PPP 协议。此协议包含链路控制协议 (LCP)，该协议用于维护连接的可用性。每一端都可以向另一端发送 LCP 回显，如果在分配的时间范围内没有响应，则会假定会话已死，并将其拆除。同样，任何一端都可以启动此过程。然后客户端应该协商一个新的连接。但是，这通常意味着分配一个新的 IP 地址以及新的会话。

也许这是不可取的？虽然您当然无法控制远程端在这方面发生的事情，但您可以调整 PPP 在您这一端处理 LCP 回显的非常灵活的方式，以增加回显的数量，延长您这一端的间隔和超时时间。这可能有助于在边缘线路条件或另一端存在错误的情况下延长不稳定连接的寿命。阅读您的客户端文档。YMMV（您的里程可能会因情况而异）。

一些提供商可能会故意强制执行一些时间限制。对此您无能为力。

此外，频繁掉线的连接通常表明存在某种线路问题。这是电信公司应该调查的事情。

5.2. 安装问题

如果您根本没有同步或完全无法连接，请阅读本节。有关解释调制解调器 LED 指示灯的信息，请参阅调制解调器的用户手册。（如果未同步，许多调制解调器会显示稳定的红色（或橙色）指示灯。）

5.2.1. 无同步

调制解调器同步 LED 指示灯从未变为绿色。

5.2.2. 网卡 (NIC) 问题

这里的症状是：NIC 未被识别、模块无法加载，或者 ifconfig 显示接口未启动，或者正在生成大量错误等。

5.2.3. IP 连接问题

如果您确定调制解调器正在同步，NIC 已被识别并且似乎工作正常，客户端软件已安装并运行没有错误，但与 ISP 的连接失败，请阅读本节。通过 LED 指示灯验证调制解调器确实正在同步。IP 连接失败的证据可能是 ifconfig 未显示活动的 eth0 接口（或 PPPoX 的 ppp0），或者 pinging 网关和其他目标生成 '网络不可达' 或类似错误。

5.3. 同步问题

如果您曾经连接正常，但现在丢失了同步，正在间歇性地丢失同步，您的同步速率显着下降，或者遇到“同步/无法上网”的情况，请阅读本节。（质量更好的调制解调器将有一种方法来报告同步速率，通常通过 telnet 或 Web 浏览器界面。请参阅用户手册。）

同步丢失表明 DSLAM、您的线路（内部或外部）或您的调制解调器存在问题。DSLAM 通常具有“机架”和“卡”。例如，Alcatel DSLAM 卡每张卡的容量为四个连接。如果卡坏了，最多会影响四个客户。关键是同步丢失中断可能是非常孤立的。与往往影响大量用户的网络中断不同。同步中断是电信公司的问题，而不是 ISP 的问题。如果您的服务协议是与 ISP 签订的，您将需要联系他们，他们将反过来联系电信公司。

降低的同步速率和 DSL 信号中断可能会导致各种问题。显然，在这些条件下，您永远无法获得最大吞吐量。但是，症状并不总是明显地表明问题是在您这边还是在提供商那边。

例如，不良的室内线路连接可能会导致丢包的数据包重传。这确实会降低吞吐量并减慢连接速度。很容易将丢包视为传统的网络问题，但对于 DSL 而言，它可能是线路不良、信号受损甚至调制解调器本身造成的。

一些可以尝试的事情

另一种可能性是附近的 AM 广播电台或非法业余无线电操作员正在干扰 DSL 信号，因为它们在相似的频率范围内运行。这些可能只在一天中的某些时间引起问题，例如当电台在晚上增强其信号时。优秀的电信 DSL 技术人员可能能够帮助最大限度地减少这种情况的影响。YMMV（您的里程可能会因情况而异）。

5.4. 网络和吞吐量问题

如果您的连接已建立，但遇到吞吐量问题，请阅读本节。换句话说，您的速度与您的比特率计划以及您与 CO 的距离不符。“网络”此处指的是 WAN - ISP 的网关和本地子网/骨干网等。请记住，边缘线路可能会导致同步速率降低，这将影响吞吐量。请参阅上面。

我们将要寻找的两个因素是“延迟”和“丢包”。两者都非常容易使用标准网络工具 ping 和 traceroute 跟踪。如果我们的路径中发生任何一种情况，它们都会影响性能。延迟意味着“响应速度”或“滞后时间”。实际上，我们感兴趣的是异常高的延迟，因为总是存在一些延迟。丢包是指数据包在途中某处被丢弃。TCP/IP 将知道它已“丢失”，并且将重传丢失的数据。这种情况发生得太多真的会减慢速度。理想情况下，丢包率应为 0%。

我们真正需要关注的是我们经常遍历的 WAN 路由部分。如果您对几个不同的站点执行 traceroute，您可能会看到前几个“跳”往往是相同的。这些是您的 ISP 的本地骨干网和您的 ISP 的上游提供商的网关。其中任何一个出现问题，都会影响您去的任何地方和您做的任何事情。

我们可以通过 ping 两到三个不同的站点来开始查找丢包和延迟，希望至少在几个不同的方向上。我们将寻找丢包和/或异常高的延迟。

 $ ping -c 12 -n www.tldp.org
 PING www.tldp.org (152.19.254.81) : 56(84) bytes of data.
 64 bytes from 152.19.254.81: icmp_seq=0 ttl=242 time=62.1 ms
 64 bytes from 152.19.254.81: icmp_seq=1 ttl=242 time=60.8 ms
 64 bytes from 152.19.254.81: icmp_seq=2 ttl=242 time=59.9 ms
 64 bytes from 152.19.254.81: icmp_seq=3 ttl=242 time=61.8 ms
 64 bytes from 152.19.254.81: icmp_seq=4 ttl=242 time=64.1 ms
 64 bytes from 152.19.254.81: icmp_seq=5 ttl=242 time=62.8 ms
 64 bytes from 152.19.254.81: icmp_seq=6 ttl=242 time=62.6 ms
 64 bytes from 152.19.254.81: icmp_seq=7 ttl=242 time=60.3 ms
 64 bytes from 152.19.254.81: icmp_seq=8 ttl=242 time=61.1 ms
 64 bytes from 152.19.254.81: icmp_seq=9 ttl=242 time=60.9 ms
 64 bytes from 152.19.254.81: icmp_seq=10 ttl=242 time=62.4 ms
 64 bytes from 152.19.254.81: icmp_seq=11 ttl=242 time=63.0 ms
 
 --- www.tldp.org ping statistics ---
 12 packets transmitted, 12 packets received, 0% packet loss
 round-trip min/avg/max = 59.9/61.8/64.1 ms

上面的例子从这里来看非常正常。（您可能到此站点的路由非常不同，因此您的结果可能会大相径庭。）显然没有会减慢我速度的严重潜在问题。下面的例子揭示了一个问题

 $ ping -c 20 -n www.debian.org
 
 PING www.debian.org (198.186.203.20) : 56(84) bytes of data.
 64 bytes from 198.186.203.20: icmp_seq=0 ttl=241 time=404.9 ms
 64 bytes from 198.186.203.20: icmp_seq=1 ttl=241 time=394.9 ms
 64 bytes from 198.186.203.20: icmp_seq=2 ttl=241 time=402.1 ms
 64 bytes from 198.186.203.20: icmp_seq=4 ttl=241 time=2870.3 ms
 64 bytes from 198.186.203.20: icmp_seq=7 ttl=241 time=126.9 ms
 64 bytes from 198.186.203.20: icmp_seq=12 ttl=241 time=88.3 ms
 64 bytes from 198.186.203.20: icmp_seq=13 ttl=241 time=87.9 ms
 64 bytes from 198.186.203.20: icmp_seq=14 ttl=241 time=87.7 ms
 64 bytes from 198.186.203.20: icmp_seq=15 ttl=241 time=85.0 ms
 64 bytes from 198.186.203.20: icmp_seq=16 ttl=241 time=84.5 ms
 64 bytes from 198.186.203.20: icmp_seq=17 ttl=241 time=90.7 ms
 64 bytes from 198.186.203.20: icmp_seq=18 ttl=241 time=87.3 ms
 64 bytes from 198.186.203.20: icmp_seq=19 ttl=241 time=87.6 ms
 
 --- www.debian.org ping statistics ---
 20 packets transmitted, 13 packets received, 35% packet loss
 round-trip min/avg/max = 84.5/376.7/2870.3 ms

高丢包率，达到 35%，并且其中一些往返时间非常慢。对此进行一些挖掘表明，问题在于 traceroute 中 13 跳的骨干路由器。虽然这使得从这里访问此站点非常慢，但它只会影响那些恰好命中同一路由器的路由。现在真正会伤害我们的是，如果类似的事情发生在我们倾向于始终通过的路由器上。例如我们的网关，或者也可能是第二跳路由器。使用 traceroute 找到这些，只需选择一个随机站点

 $ traceroute www.bellsouth.net
 
 traceroute to bellsouth.net (192.223.22.134), 30 hops max, 38 byte packets
  1  adsl-78-196-1.sdf.bellsouth.net (216.78.196.1)  14.86ms  7.96ms 12.59ms
  2  205.152.133.65 (205.152.133.65)                  7.90ms  8.12ms  7.73ms
  3  205.152.133.248 (205.152.133.248)                8.99ms  8.52ms  8.17ms
  4  Hssi4-1-0.GW1.IND1.ALTER.NET (157.130.100.153)  11.36ms 11.48ms 11.72ms
  5  125.ATM3-0.XR2.CHI4.ALTER.NET (146.188.208.106) 14.46ms 14.23ms 14.40ms
  6  194.at-1-0-0.TR2.CHI2.ALTER.NET (152.63.65.66)  16.48ms 15.69ms 16.37ms
  7  126.at-5-1-0.TR2.ATL5.ALTER.NET (152.63.0.213)  65.66ms 66.18ms 66.39ms
  8  296.ATM6-0.XR2.ATL1.ALTER.NET (152.63.81.37)    66.86ms 66.42ms 66.40ms
  9  194.ATM8-0.GW1.ATL3.ALTER.NET (146.188.233.53)  67.87ms 68.69ms 69.63ms
 10  IMVI-gw.customer.ALTER.NET (157.130.69.202)     69.88ms 69.25ms 69.35ms
 11  www.bellsouth.net (192.223.22.134)              68.74ms 69.06ms 68.05ms

第一跳是网关。事实上，对我来说，前两跳总是相同的，并且前三或四跳通常是相同的。因此，这些中的任何一个出现问题都可能导致我去任何地方都出现问题。（您自己情况的具体情况可能与此示例略有不同。）一个“正常”网关 ping（对我来说正常！）

 
 $ ping -c 12 -n 216.78.196.1
 
 PING 216.78.196.1 (216.78.196.1) : 56(84) bytes of data.
 64 bytes from 216.78.196.1: icmp_seq=0 ttl=64 time=14.6 ms
 64 bytes from 216.78.196.1: icmp_seq=1 ttl=64 time=15.4 ms
 64 bytes from 216.78.196.1: icmp_seq=2 ttl=64 time=15.0 ms
 64 bytes from 216.78.196.1: icmp_seq=3 ttl=64 time=15.2 ms
 64 bytes from 216.78.196.1: icmp_seq=4 ttl=64 time=14.9 ms
 64 bytes from 216.78.196.1: icmp_seq=5 ttl=64 time=15.3 ms
 64 bytes from 216.78.196.1: icmp_seq=6 ttl=64 time=15.4 ms
 64 bytes from 216.78.196.1: icmp_seq=7 ttl=64 time=15.0 ms
 64 bytes from 216.78.196.1: icmp_seq=8 ttl=64 time=14.7 ms
 64 bytes from 216.78.196.1: icmp_seq=9 ttl=64 time=14.9 ms
 64 bytes from 216.78.196.1: icmp_seq=10 ttl=64 time=16.2 ms
 64 bytes from 216.78.196.1: icmp_seq=11 ttl=64 time=14.8 ms

 --- 216.78.196.1 ping statistics ---
 12 packets transmitted, 12 packets received, 0% packet loss
 round-trip min/avg/max = 14.6/15.1/16.2 ms

以及在不同的一天同一网关出现问题

 $ ping  -c 12 -n 216.78.196.1
 
 PING 216.78.196.1 (216.78.196.1) : 56(84) bytes of data.
 64 bytes from 216.78.196.1: icmp_seq=0 ttl=64 time=20.5 ms
 64 bytes from 216.78.196.1: icmp_seq=3 ttl=64 time=22.0 ms
 64 bytes from 216.78.196.1: icmp_seq=4 ttl=64 time=21.8 ms
 64 bytes from 216.78.196.1: icmp_seq=6 ttl=64 time=32.0 ms
 64 bytes from 216.78.196.1: icmp_seq=8 ttl=64 time=21.7 ms
 64 bytes from 216.78.196.1: icmp_seq=9 ttl=64 time=42.0 ms
 64 bytes from 216.78.196.1: icmp_seq=10 ttl=64 time=26.8 ms
 
 --- adsl-78-196-1.sdf.bellsouth.net ping statistics ---
 12 packets transmitted, 7 packets received, 41% packet loss
 round-trip min/avg/max = 20.5/25.6/42.0 ms

41% 的丢包率非常高，以至于许多服务（如 HTTP）都戛然而止。那些正在工作的服务，工作速度非常非常慢。

在这个最后的真实示例中，很容易让人认为这个网关路由器出现故障。但是，事实证明，这是电信网络 DSLAM/ATM 段中出现问题的结果。因此，任何第一跳出现丢包或高延迟的问题，实际上都可能是第一跳之前发生的事情的结果。我们只是没有足够的工具来充分隔离它的起始位置。丢包可能是电信公司的问题，就像 ISP/NSP 问题一样。或者可能甚至是调制解调器问题。在这种情况下，请尝试通过断电和拔下/重新插入 DSL 电缆（从墙壁插孔）来重置调制解调器。

调制解调器本身也很可能导致丢包。这里的解决方法是重启调制解调器，并通过拔下 DSL 连接 30 秒左右来重新同步。事实上，连接的任何部分都可能是丢包的来源——调制解调器、DSLAM、ATM 网络等。

如果您确实在 ISP 的网络中发现了问题，那么是时候向技术支持报告问题了。

5.4.1. 其他网络问题

一些零星问题

5.5. 测量吞吐量

我们大多数人首先要做的事情之一是检查我们的速度，以确保我们没有被欺骗，并且我们的系统达到了标准。然而，准确地做到这一点说起来容易做起来难。首先，请记住，由于网络协议开销，您一开始就损失了 10-20%。这里的“损失”多少取决于您的提供商的网络架构、您在哪里以及如何测量它以及其他考虑因素。我们大多数人最终可能会更接近 20% 而不是 10%。

然后，每次您访问互联网时，您所经过的每一跳都会导致轻微的性能下降。 只要您没有经过太多跳，并且所有组件（您的系统、您的 ISP 网络、您的 ISP 的上游提供商以及目标本身）都像运转良好的机器一样工作，这可能不会造成太大影响。 但问题就在于此 —— 在混合了如此多的变量的情况下，您如何真正知道呢？ 路径上某一个跃点上的一个路由器上的一个不稳定的接口，都可能导致误导性的结果。

您的绝对最大速度将出现在您连接到 ISP 的点 —— ISP 的网关。 速度只会从那里开始下降，而不会上升！ 因此，理想的测试是尽可能靠近“家”。 这消除了尽可能多的未知变量。 如果您的 ISP 有本地 ftp 服务器，那么这里是运行您自己测试的绝佳场所。（运行 traceroute 只是为了看看它到底有多“本地”。）

如果您的 ISP 没有这个，请寻找一个靠近的 ftp 站点 —— 跳数越少越好。 并寻找一个不太繁忙的站点，否则您将得到误导性的结果。 找一个大文件 —— 比如 10 兆字节 —— 并记录下载时间。 在几天内，并在一天中的不同时间尝试这样做。 服务器和骨干网在一天中的某些时间会更加繁忙，这可能会扭曲结果，您需要尽可能消除这些变量。 您的提供商无法补偿繁忙的骨干网流量、骨干网瓶颈、缓慢或繁忙的服务器等。

网络上散布着许多测试站点。 有些比其他的更好，但对这些测试要持保留态度。 这些测试存在太多变量，无法可靠地为您提供连接和吞吐量的准确快照。 它们可能会给您一个大致的了解，即您是否处于您认为应该达到的范围附近。 一个不错的速度测试是http://www.dslreports.com/stest/0。 另一个测试是 http://speedtest.mybc.com/ （两者都是 Java）。 我发现这些比其他一些要好。

现在请记住，我们受到大约 10-20% 网络开销规则的限制，这里有一个例子。 我的速度上限为 1472 Kbps 同步速率。 减去约 15% 就是 1275 Kbps。 我的同步速率已知良好，并且我到 CO（中心局）的距离约为 11,000 英尺，这足够近，我应该能够达到 1275 Kbps 或大约 1.2-1.3 Mbps 的实际最大吞吐量 —— 在所有其他条件相同的情况下。 来自 dslreports.com 速度测试

 Test running..Downloaded 60900bytes in 5918ms
 Downloaded 696000bytes in 4914ms
 First guess is 1133kbps
 fairly fast line - now test 2mb
 Downloaded 1679100bytes in 11090ms
 Upload got ok 1 bytes uploaded
 Uploaded 1bytes in 211ms
 Upload got ok 1 bytes uploaded
 Uploaded 1bytes in 205ms
 Upload got ok 1 bytes uploaded
 Uploaded 1bytes in 207ms
 Upload got ok 50000 bytes uploaded
 Uploaded 50000bytes in 2065ms
 Upload got ok 100000 bytes uploaded
 Uploaded 100000bytes in 3911ms
 
 ** Speed 1211(down)/215(up) kbps **
 (At least 24 times faster than a 56k modem)
 Finish.

1.211 Mbps 可能是我根据我的服务可以合理期望的最佳效果。 我没有理由去进行故障排除或寻找调整。

重要提示：我的 ISP 使用缓存代理服务器来缓存网页。 这对于这些基于网络的测试来说是一个很大的均衡器。 如果没有它，我在这个测试中肯定会慢得多。 代理的效果是您实际上是在测试来自代理的吞吐量 —— 而不是测试站点。 仅供参考。 另一个注意事项：同时我尝试了另一个测试站点，并且始终如一地获得 600-700 Kbps。 因此，YMMV（您的里程可能会因人而异） 与这些测试。 （通常我在每个测试中得到的结果大致相同。） 计时从两个不同站点下载大型 ftp 文件，我计算出大约 1.25 Mbps。

上一页主页下一页
保护您的连接 附录：DSL 概述