我们有一个新的Synology RS3412RPxs，可以为三个Windows 2008 R2盒子和NFS提供iSCSI目标到一个OpenBSD 5.0盒子。
使用sshlogin到RS3412，使用dd和各种数据块读取和写入小文件和6GB文件，都可以获得出色的磁盘I / O性能。
在iSCSI / NFS客户端上使用dd或iometer，我们可以达到20Mbps（这不是一个错误的20 Mbps）。 我们有点希望能够更好地使用Synology中的多个Gbit网卡。
我已经validation交换机和网卡端口configuration设置为千兆，而不是自动协商。 我们尝试了使用和没有Jumboframe没有区别。 我已经用pingvalidation了MTU目前是9000.已经部署了两个固件升级。
我将尝试iSCSI目标和启动器之间的直接链接以排除交换机问题，但是我的其他选项是什么？
如果我打破wireshark / tcpdump，我该找什么？
看起来这是常见的主题，再看一下交换机上的stream量控制设置。 如果交换机有以太网计数器统计信息，请查看它们，看看是否有大量的以太网PAUSE帧。 如果是这样，那可能是你的问题。 通常，在交换机上禁用QOS可以解决这个问题。
像这样的stream程告诉我，各种TCPstream量控制方法是不正确的。 我已经看到Linux内核与Vista后的Windows版本交谈时遇到的一些问题，并获得了这样的吞吐量。 一旦你看了，他们往往在Wireshark中performance得相当不错。
绝对最糟糕的可能性是，TCP延迟确认已完全中断，您将看到一个类似于以下的stream量模式：
packet packet [ack] packet packet [ack] 我已经通过将NIC驱动程序更新应用到Windows服务器来解决这个问题。 某些（broadcom）服务器附带的智能NIC有时可能会以有趣的方式失败，这是一个例子。
正常的stream量模式是大量的数据包，然后是Ack数据包。
另一件事是要拖延很长时间。 可疑值是0.2秒和1.0秒。 这表明，一方没有得到它所期望的，并在等待超时到期之前回复。 将上述不良分组模式与ACK的200ms延迟相结合，您将获得高达1MB / s的吞吐量。
这些是容易注意到的不良交通模式。
我没有使用这种NAS设备，所以不知道如何解决这个问题。