我的LAN结构：
客户端下载一个需要42.1s的310MB文件，即7.36MB / s。 在传输过程中分析结果（NAS路由器的linux堆栈具有oprofile内置）显示CPU处于default_idle函数的CPU时间约为37％。 我想知道为什么有这么高的default_idle部分。
这是我做的：
我从USB复制文件到路由器的ramfs。 下载速度达到15MB / s。
我在NAS路由器和PC上build立iperf来testingnetworking的最大传输速率。 iperf结果显示双向最大速度约为11.4MB / s。
那么，现在似乎7.36MB / s的限制是由桑巴套件引起的。 find引起这个限制的地方也许可以帮助解释default_idle函数的高部分。
但是我不知道如何继续。 请给出一些build议和build议。
谢谢
SMB有相当大的协议开销; 不幸的是这不是你可以“修复”的东西。
当你看上去显然是在100mbit上运行时，11.4MB / sec的Iperf“理论”实用限制将不会被任何有效负载达到; 我说理论上是因为iperf假设条件完美，并且没有考虑任何窗口错误，错误或重传。 它测量纯粹的低级IP数据包吞吐量。
如果你可以在路由器上设置一个ftpd并进行testing，你会发现你可以接近11.4MB的带宽限制（FTP已知具有最小的任何文件传输协议的开销）。或者，看看你可以通过使用netcat来将数据泵送到文件或从文件中获取数据。
轶事，但我的一个朋友正在与无线高清video交付，发现吞吐量从Samba切换到NFS的重大增加..他说的2-3倍快。 我相信这与Adaptr所说的一致