本文介绍了作者在家庭网络中实现千兆吞吐量的探索过程，涉及到Vista系统、交换机、磁盘速度、网卡、布线等多个方面。在排除了硬件和网络配置问题后，作者发现SMB2协议相比SMB1在速度上有显著提升，同时揭示了巨型帧在提高传输速度中的重要作用。经过调整，最终实现了较高的数据传输速率。
UPDATE: Here's a Bit.ly Bundled Link of the complete "Wiring your house for Gigabit Ethernet 5 PART SERIES."
更新：这是完整的“为千兆以太网5部分系列为房屋布线”的Bit.ly捆绑链接。
I posted earlier about copying files across my new Gigabit home network. I was getting about 10 MB/s (that's MegaBytes) between two laptops and I got responses like these in the comments that shook my confidence. Here's my thoughts after each interesting comment that appeared in the previous post.
我之前发布过有关在新的千兆家庭网络中复制文件的信息。 我在两台笔记本电脑之间获得了大约10 MB / s(兆字节)的速度，并且在评论中得到了这样的回应，这动摇了我的信心。 在上一篇文章中出现的每条有趣的评论之后，我的想法都是如此。
"You should be pushing at least 100 megabytes per second with gigabit ethernet."
“您应该使用千兆以太网至少每秒推送100兆字节。”
Hm..that doesn't sound right. Given bits/bytes math and some Maximum speed given overhead, etc, is usually 80% of spec, so 1000Mb/s means about 80MB/s. But, still, the point is taken.
嗯..听起来不对。 给定的位/字节数学和某些给定的最大速度等开销通常是规格的80％，因此1000Mb / s意味着约80MB / s。 但是，这仍然是正确的。
"His stats only caught my attention because just today I was profiling the speeds of a new hard drive array for one of the programmers and copied 3.2gb in 7 minutes over our 100mbit ethernet connection."
“他的统计信息只引起了我的注意，因为直到今天，我仍在为一个程序员分析一个新硬盘阵列的速度，并在我们的100mbit以太网连接上在7分钟内复制了3.2gb。”
That's about 8-10 megs a second, so that's on par which what I was seeing. This makes me wonder about the hard drive speed.
那大约是8-10兆秒，所以这与我所看到的差不多。 这使我想知道硬盘速度。
"10Meg/sec is well below what I'd expect even for a laptop to laptop exchange over a gigabit connection where the drives probably top out at 30-50Meg/sec"
“ 10Meg / sec远低于我期望的值，即使笔记本电脑通过千兆位连接交换笔记本电脑，驱动器可能达到30-50Meg / sec”
I checked my hard drive throughput and it was 70MB/s sequential writes and 40MB/s sequential large file reads on the big machine and 30/20 on the laptop. Certainly fast enough that I’d want to see similar network speeds when copying a single large VM, etc. However, I was copying hundreds of files on a medium fragmented drive, so 10MB/s isn't unreasonable, IMHO. I'll look at disks in a second.
我检查了硬盘的吞吐量，在大型计算机上是70MB / s的顺序写入，在大型计算机上是40MB / s的顺序大文件读取，而在笔记本电脑上是30/20。 肯定足够快，以至于我在复制单个大型VM等时希望看到类似的网络速度。但是，我在一个零散的中等大小的驱动器上复制了数百个文件，所以10MB / s并不是不合理的，恕我直言。 我待会儿再看磁盘。
"You should be getting about ~32meg per second with standard 5400rpm notebook hard drives copying a single large file."
“使用标准的5400rpm笔记本硬盘复制单个大文件，您应该获得约32兆秒的每秒。”
OK, sure I can believe that, assuming there is nothing else going on and there's a nice contiguous spot to lay it down, absolutely. So, let's break this down step by step.
好的，可以肯定的是，假设没有其他事情发生了，那么绝对有一个不错的连续地放下它。 因此，让我们一步一步地分解一下。
初始点 (Starting Point)
Here's where we start, as possibly useful background, I recently built a house and put some amount of effort into the Home Network.
我们从这里开始，作为可能有用的背景，我最近盖了一栋房子，并在家庭网络中付出了一些努力。
The house is all Cat 6 wiring, and the main switch is a NetGear 24-port with 20 gigabits of total managed bandwidth. For this test machines are OFF the corporate network and I’ve physically turned their wireless cards OFF. They are single-homed on a basic flat 192.168.x.x network. Nothing fancy.
房屋全部采用Cat 6布线，主交换机为NetGear 24端口，总管理带宽为20吉比特。 对于此测试，机器已关闭公司网络，而我已将其无线网卡完全关闭。 它们是单宿主在基本的平面192.168.xx网络上。 没有什么花哨。
I brought VS2008 down from the cloud, the files, not the single file large ISO and copied the 3 gigs of files via Explorer Drag Drop between two Vista 32-bit RTM machines and got disappointing results.
我将VS2008从云，文件而不是单个大ISO文件中删除，并通过Explorer Drag Drop在两台Vista 32位RTM计算机之间复制了3g的文件，结果令人失望。
No music was playing. The machines are all dual or quad core machines, one with a 10,000 RPM hard drive and the others are pretty fast laptops, so they are beefy machines.
没有音乐在播放。 这些机器都是双核或四核机器，其中一台具有10,000 RPM硬盘驱动器，而其他则是相当快的笔记本电脑，因此它们是强大的机器。
Why mention this? First we eliminate slow or crappy hardware. In this instance, we know it's not CPU that's causing this. That doesn't mean the network cards aren't poo or something, but we gotta start somewhere. Point is, they are more than fast enough to handle the traffic.
为什么要提这个？ 首先，我们消除了缓慢或崩溃的硬件。 在这种情况下，我们知道不是由CPU引起的。 这并不意味着网卡不是便便，但我们必须从某个地方开始。 关键是，它们的速度足以应付流量。
初始次优结果 (The Initial Sub-Optimal Results)
So, after the first run, I was getting 10MB/s between a Vista RTM machine (a Mac) and an SP1 machine. When Vista SP1 talks to Vista RTM it'll talk SMB 1.0, the common protocol between them (the one that's been used forever).
因此，在第一次运行后，我在Vista RTM机器(Mac)和SP1机器之间获得了10MB / s的速度。 当Vista SP1与Vista RTM对话时，它将谈论SMB 1.0，这是它们之间的通用协议(已被永远使用的协议)。
Of course this isn't a BAD result, as one of the commenters pointed out. I mean, 10 MB/s is more than reasonable most often and this is the kind of thing one would only come up against when copying giant files. Still...now it's a mystery...
正如一位评论者指出的那样，这当然不是一个糟糕的结果。 我的意思是，大多数情况下10 MB / s超出了合理范围，这是一种仅在复制巨型文件时才会遇到的问题。 仍然...现在是个谜...
磁盘速度 (Disk Speed)
Perhaps Disk Speed is the problem? Commenters on previous posts say Nay, Nay. SATA disks should get 40 to 70MB/s, and that's consistent with my test. The Hanselman-Atwood Ultimate Developer Rig gets 70Mb/s for sequential writes. Of course this assume non-fragmented disks and that nothing else is moving the disk heads around. The MacBookPro and Lenovo t60p get between 20 and 30MB/s, so they are not slouches either. All this points away from Disk Speed.
也许磁盘速度是问题？ 先前帖子的评论者说，不。 SATA磁盘应达到40至70MB / s，这与我的测试一致。 Hanselman-Atwood Ultimate Developer Rig的连续写入速度为70Mb / s。 当然，这是假设未碎片化的磁盘，并且没有其他东西在移动磁盘磁头。 MacBookPro和Lenovo t60p的速度在20到30MB / s之间，因此它们也不是问题。 所有这些指向磁盘速度。
Here's disk throughput on a laptop:
这是笔记本电脑上的磁盘吞吐量：
C:\>disktest.exe -file "Random" -iobytes 8388608 -pipeline 2 -totalbytes 1073741824
C：\> disktest.exe -file “随机” -iobytes 8388608 -pipeline 2 -totalbytes 1073741824
--- File name: Random Total size: 1073741824 bytes I/O type: read I/O size: 8388608 bytes I/O concurrency: 2 (asynchronous) Buffered: no
--- 文件名：随机总大小：1073741824字节I / O类型：读取I / O大小：8388608字节I / O并发：2(异步) 缓冲：否
---Running the test...---
---运行测试... ---
App. Throughput: 33.2 MBytes/sec (30.9 seconds) Disk Throughput: 33.2 MBytes/sec (27 samples, 1 high variance) Min. I/O latency: 250 ms Avg. I/O latency: 480 ms Max. I/O latency: 811 ms
应用程式吞吐量：33.2 MB /秒(30.9秒) 磁盘吞吐量：33.2 MB /秒(27个样本，1个高差异) 最小I / O延迟：250毫秒平均I / O延迟：480毫秒最高I / O延迟：811毫秒
So, disk throughput is fine.
因此，磁盘吞吐量很好。
网卡 (Network Cards)
In cases like these, it's always a good idea to step back and read the manual. I checked out the release notes for each of my Network Cards and confirmed that they do work on Gigagbit and on Vista and had no issues that smelled like what I am seeing.
在这种情况下，退一步阅读本手册始终是一个好主意。 我检查了每张网卡的发行说明，并确认它们可以在Gigagbit和Vista上运行，并且没有闻起来像我所看到的问题。
One useful tip from Ed Briggs:
Ed Briggs的一个有用提示：
"One thing to watch. On some motherboards, the gigibit NIC (usually a Marvell Yukon 88E8001) is wired to the PCI-33 bus, even if there is a PCI express bus. I find this on a number of boards where they advertise multiple Gig Eth NICs. So say, you'll have an NVidia on the PCI-E or the southbridge, and a Marvell on the PCI-33, and your Intel Pro1000 on the PCI-E. So you'll see some differences there because PCI-33 runs out of steam. "
“要注意的一件事。在某些主板上，即使有PCI Express总线，千兆网卡(通常是Marvell Yukon 88E8001)也已连接到PCI-33总线。我在许多发布了多个主板的板上都发现了这一点。 Gig Eth NIC。也就是说，在PCI-E或南桥上有NVidia，在PCI-33上有Marvell，在PCI-E上有Intel Pro1000。因此，您会看到一些区别，因为PCI-33用尽了。”
This wasn't the case for me, but it is very good to know.
对我来说不是这种情况，但很高兴知道。
布线 (Cabling)
Even though it shouldn't matter I checked all the cables and confirmed that the house was Cat6. I had been using Cat5 (not 5e) patch cables, so I swapped those out for Cat 5e, and ordered some Cat6 ones just to have.
即使没关系，我也检查了所有电缆并确认房子是Cat6。 我一直在使用Cat5(不是5e)跳线，所以我将它们换成Cat 5e，并订购了一些Cat6。
交换机/路由器 (Switch/Router)
Next, I confirmed that my Switch saw these different machines connecting as Gigabit. Here's a screenshot from the Administration Interface of my switch.
接下来，我确认我的Switch看到这些不同的机器以千兆位连接。 这是我的交换机管理界面的屏幕截图。
I'm going between g18, g19, and g21. The administration interface for the switch also shows the length of the cables.
我要在g18，g19和g21之间进行切换。 交换机的管理界面还显示电缆的长度。
Everything is reasonable from a cabling perspective.
从布线的角度来看，一切都是合理的。
中心举行吗？ (Does the Center Hold?)
I determined that I must be making some terrible mistake. Rather than pulling and proding, I just started testing with traffic. Here’s a NTttcp run. Note the CPU and MBits. You can get NTttcp in the Windows 2000 Resource Kit.
我确定我必须犯一些可怕的错误。 我没有进行拖拉操作，而是开始对流量进行测试。 这是NTttcp运行。 注意CPU和MBits。 您可以在Windows 2000 Resource Kit中获得NTttcp。
Total Bytes(MEG) Realtime(s) Average Frame Size Total Throughput(Mbit/s) ================ =========== ================== ======================== 1342.177280 20.649 1424.681 519.997
总字节数(MEG)实时平均帧大小总吞吐量(Mbit / s) ================================================= =================== 1342.177280 20.649 1424.681 519.997
Packets Sent Packets Received Total Retransmits Total Errors Avg. CPU % ============ ================ ================= ============ ========== 942090 83137 0 0 7.27
已发送的数据包已接收的数据包总重发平均错误总数中央处理器 ％ =============================================== ======= ========== 942090 83137 0 0 7.27
Here's a result with two threads. Kind of weird that it's more, but it is over 800 megabits. This implies that the network is generally OK.
这是两个线程的结果。 奇怪的是，它更多，但超过800兆位。 这意味着网络通常可以。
Total Bytes(MEG) Realtime(s) Average Frame Size Total Throughput(Mbit/s) ================ =========== ================== ======================== 2684.354560 26.500 18753.481 810.371
总字节数(MEG)实时平均帧大小总吞吐量(Mbit / s) ================================================= =================== 2684.354560 26.500 18753.481 810.371
Packets Sent Packets Received Total Retransmits Total Errors Avg. CPU % ============ ================ ================= ============ ========== 143139 175153 3 0 15.46
已发送的数据包已接收的数据包总重发平均错误总数中央处理器 ％ =============================================== ======= ========== 143139 175153 3 0 15.46
Then I tried
然后我尝试
I tried iPerf, the standard cross-platform network throughput tester.
我尝试了iPerf (标准的跨平台网络吞吐量测试仪)。
Z:\ntttcp\iperf>iperf -c 192.168.1.14
------------------------------------------------------------
Client connecting to 192.168.1.14, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[132] local 192.168.1.9 port 49642 connected with 192.168.1.14 port 5001
[ ID] Interval Transfer Bandwidth
[132] 0.0-10.0 sec 360 MBytes 302 Mbits/sec
Z：\ ntttcp \ iperf> iperf -c 192.168.1.14 -------------------------------------------------- ---------- 客户端连接到192.168.1.14，TCP端口5001 TCP视窗大小：8.00 KB(默认值) -------------------------------------------------- ---------- [132]本地192.168.1.9端口49642与192.168.1.14端口5001连接[ID]间隔传输带宽[132] 0.0-10.0秒360 MBytes 302 Mbits / sec
Notice the small TCP window size. I'll try again with a larger one.
注意较小的TCP窗口大小。 我会尝试更大的一个。
Z:\ntttcp\iperf>iperf -c 192.168.1.14 -w 64k
------------------------------------------------------------
Client connecting to 192.168.1.14, TCP port 5001
TCP window size: 64.0 KByte
------------------------------------------------------------
[132] local 192.168.1.9 port 49654 connected with 192.168.1.14 port 5001
[ ID] Interval Transfer Bandwidth
[132] 0.0-10.0 sec 1.08 GBytes 926 Mbits/sec
Z：\ ntttcp \ iperf> iperf -c 192.168.1.14 -w 64k -------------------------------------------------- ---------- 客户端连接到192.168.1.14，TCP端口5001 TCP视窗大小：64.0 KB -------------------------------------------------- ---------- [132]与192.168.1.14端口5001连接的本地192.168.1.9端口49654 [ID]间隔传输带宽[132] 0.0-10.0秒1.08 GB 926 Mbits /秒
Ok, so that's good and implies again that the network doesn't totally suck. Note also that this very good test happened between a Vista RTM machine and a Vista SP1 machine.
好的，这很好，再次暗示着网络并没有完全崩溃。 还要注意，此非常好的测试是在Vista RTM计算机和Vista SP1计算机之间进行的。
本地TCP设置 (Local TCP Settings)
Next, I checked the window size on my MSFT Corporate t60p Laptop with Vista SP1 and was shocked to see the tuning level set to highlyrestricted. Not sure who set that but it wasn’t me (that I remember). I switched it back to “normal” but it didn’t affect any of the tests – I ran them again. Everyone is set to normal.
接下来，我检查了装有Vista SP1的MSFT Corporate t60p笔记本电脑的窗口大小，并震惊地看到将调整级别设置为高度限制。 不知道是谁设置的，但不是我(我记得)。 我将其切换回“正常”状态，但没有影响任何测试-我再次运行它们。 每个人都设置为正常。
C:\Users\Scott\Desktop\ntttcp>netsh interface tcp show global Querying active state... TCP Global Parameters ---------------------------------------------- Receive-Side Scaling State : enabled Chimney Offload State : enabled Receive Window Auto-Tuning Level : highlyrestricted (should be normal) Add-On Congestion Control Provider : none ECN Capability : disabled RFC 1323 Timestamps : disabled
C：\ Users \ Scott \ Desktop \ ntttcp> netsh界面tcp显示全局正在查询活动状态... TCP全局参数---------------------------------------------- 接收端缩放状态：已启用烟囱卸载状态：启用接收窗口自动调整级别：严格限制(应该是正常的) 附加拥塞控制提供者：无ECN功能：已禁用RFC 1323时间戳记：已禁用
The standard setting of "normal" should work for nearly everyone although some folks swear by "disabled."
标准设置“正常”几乎对每个人都适用，尽管有些人发誓“残疾人”。
千兆巨型帧 (Gigabit Jumbo Frames)
Marc suggested enabling Jumbo Frames, usually a NIC Driver Level settings. If all your NICs and router/switch support it, you can have frame sizes up to 9014 bytes. However, only to of my NICs supported it, so
I didn't bother.
Marc建议启用“巨型帧” ，通常是NIC驱动程序级别设置。 如果您所有的NIC和路由器/交换机都支持，则帧大小最大为9014字节。 但是，只有我的NIC支持它，因此
我没有打扰。
UPDATE: Turns out that Jumbo Frames are obscenely useful. If your network card and router supports them, go for it. More on this at the bottom.
更新：事实证明巨型帧非常有用。 如果您的网卡和路由器支持它们，那就去吧。 在底部的更多信息。
重新介绍玩家 (Reintroducing The Players)
Right now here’s the machines:
现在是机器：
Quadpower – The Good Lord's own machine. Truly. nForce chipset. Vista x64 RTM. WEI 5.8
Quadpower –善良者自己的机器。 真的nForce芯片组。 Vista x64 RTM。 魏5.8
MacBookPro – Vista x86 SP1 Beta from last week. WEI 4.9. This machine is no slouch.
MacBookPro –上周发布的Vista x86 SP1 Beta。 魏4.9 。 这台机器没有懈怠。
Lenovo T60p – Vista x64 SP1 Beta from last week. WEI 4.2. MSFT Domain joined, but not right now.
联想T60p –上周发布的Vista x64 SP1 Beta。 魏4.2。 MSFT域加入了，但目前还没有。
- Server – Windows Home Server machine, based on Windows 2k3 服务器–基于Windows 2k3的Windows Home Server计算机
测试矩阵(The Test Matrix)
Here are the four machines in question.
这是有问题的四台机器。
| Quadpower x64RTM | MacBookPro x86SP1 | T60p x64SP1 | WHS 2k3 | |
| Quadpower x64RTM | X | <10Mb/s | <10Mb/s | <10Mb/s |
| MacBookPro x86SP1 | X | X | 33Mb/s | 33Mb/s |
| T60p x64SP1 | X | X | X | 33Mb/s |
| WHS 2k3 | X | X | X | X |
| Quadpower x64RTM | MacBookPro x86SP1 | T60p x64SP1 | WHS 2k3 | |
| Quadpower x64RTM | X | <10Mb /秒 | <10Mb /秒 | <10Mb /秒 |
| MacBookPro x86SP1 | X | X | 33Mb /秒 | 33Mb /秒 |
| T60p x64SP1 | X | X | X | 33Mb /秒 |
| WHS 2k3 | X | X | X | X |
So it appears the problem is on/around/near/adjacent to Quadpower. When stuff goes into or out of it, it's slower.
因此看来问题出在Quadpower上/附近/附近。 当东西进出时，它会变慢。
Here’s SP1 to WHS (W2k3) copying a 1 gig file of random data.
这是从SP1到WHS(W2k3)复制1 gig随机数据的文件。
Here’s SP1 to RTM:
这是SP1到RTM：
Here’s the Lenovo t60p with Vista SP1 to a MacBookPro running Vista SP1
这是带有Vista SP1的Lenovo t60p到运行Vista SP1的MacBookPro
This is starting to sound familiar. I'm mixing my network protocols, specifically SMB2 vs. SMB1.
这开始听起来很熟悉。 我正在混合我的网络协议，特别是SMB2与SMB1。
"These are some of the key enhancements in SMB 2.0:
“这些是SMB 2.0中的一些关键增强功能：
SMB 2.0 supports an arbitrary, extensible way of compounding operations to reduce round trips. This makes the protocol less chatty as compared to SMB 1.0. Chattiness of SMB 1.0 has often been a major pain point.
SMB 2.0支持任意，可扩展的复合操作方式，以减少往返行程。 与SMB 1.0相比，这使该协议不那么混乱。 SMB 1.0的即时消息通常是一个主要的痛点。
SMB 2.0 supports much larger buffer sizes compared to SMB 1.0.
与SMB 1.0相比，SMB 2.0支持更大的缓冲区大小。
SMB 2.0 greatly grows the restrictive constants in the protocol, so we never need to worry about the protocol itself being the limiting factor for scalability. This includes increasing the number of concurrent open file handles on the server, and the number of shares that a server can share out, among other things.
SMB 2.0极大地增加了协议中的限制常数，因此我们无需担心协议本身就是可伸缩性的限制因素。 这包括增加服务器上并发打开文件句柄的数量，以及服务器可以共享的共享数量等。
SMB 2.0 supports durable handles that can withstand short network glitches.
SMB 2.0支持可以承受短时间网络故障的耐用手柄。
SMB2.0 has support for symbolic links. "
SMB2.0支持符号链接。 ”
NetMon 3.1 confirms that I'm talking SMB1 between my RTM and SP1 machines and SMB2 between SP1 machines.
NetMon 3.1确认我在RTM和SP1计算机之间谈论SMB1，在SP1计算机之间谈论SMB2。
结论 (Conclusion)
One thing worth pointing out that slowed down my analysis was that I only saw this slowdown when doing a File Copy. I was assuming this was a Network Hardware or TCP issue, perhaps between Vista RTM and Vista SP1. However, the tests above that showed 900+ Mbits/s were actually between and RTM and SP1 machine. Vista Networking works rather fine it seems. It was the older SMB1 protocol being negotiated between my RTM and SP1 machines that was the bottleneck.
值得一提的是，这减慢了我的分析速度，因为我在进行文件复制时才看到这种减慢。 我以为这是网络硬件或TCP问题，可能是在Vista RTM和Vista SP1之间。 但是，上面的测试表明实际上在RTM和SP1机器之间存在900+ Mbit / s 。 Vista Networking看起来运行良好。 瓶颈是我的RTM和SP1计算机之间正在协商的较早的SMB1协议。
I was also prodded to look more into Jumbo Frames. (Thanks Robert G!) Seems my Windows Home Server machine's network card has a Marvell Yukon that supports Jumbo Frames, as does the Marvell Yukon in the MacBookPro. Even though the machines will be using SMB1 as their protocol, the 9104byte frame size makes a massive difference. How much? With a 1 gig file, twice as fast, so 65+ Megabytes a second, even over SMB1. Cool!
我还被迫更多地关注巨型帧。 (感谢Robert G！)似乎我的Windows Home Server计算机的网卡具有支持巨型帧的Marvell Yukon，而MacBookPro中的Marvell Yukon也是如此。 即使这些机器将使用SMB1作为其协议，9104byte的帧大小也会产生巨大的差异。 多少？ 拥有1个gig文件，速度甚至是SMB1的两倍，达到每秒65 MB以上。 凉！
The NVidia nForce hardware chipset supports Jumbo Frames, but the drivers do not yet. NVidia is mum on the issue, which is lame. This the the chipset in my primary machine, the one I'd really like to support Jumbo.
NVidia nForce硬件芯片组支持巨型帧，但驱动程序尚不支持。 NVidia在这个问题上是沉默寡言的。 这是我主要计算机中的芯片组，我真的很想支持Jumbo。
In the Lenovo T60p there is a Intel Pro/1000 PL with an Intel 82573L chipset which apparently doesn't support Jumbo Frames when Active State Power Management (ASPM) is disabled, and since it's in a laptop, it's disabled. No Jumbo Frames on a Lenovo t60p, even with the latest Intel Network Adapter Driver for Vista 64-bit.
在Lenovo T60p中，有一个Intel Pro / 1000 PL和一个Intel 82573L芯片组，当禁用Active State Power Management(ASPM)时，它显然不支持巨型帧，并且由于它在笔记本电脑中，因此被禁用。 即使使用适用于64位Vista的最新英特尔网络适配器驱动程序， Lenovo t60p上也没有巨型帧。
"Intel does not plan to resolve this erratum in the 82573 Gigabit Ethernet
Controller. Jumbo frames is not supported in 82573E/V & is supported with the
workaround above in 82573L."“英特尔不打算解决82573千兆以太网中的这种错误控制器。 82573E / V不支持巨型帧，而解决以上82573L中的问题。”
Regardless, it turns out SMB2 is a way better protocol than SMB1. As far as I'm concerned, problem solved, I'm upgraded to Vista SP1 everywhere and am enjoying Disk Speed on the wire. Now I've gotten speeds up to 33MB/s between machines when copying large files depending on the disk of the machines involved, etc, without Jumbo Frames, and up to 66MB/s with Jumbo. I'll be sure to only get network cards that support Jumbo Frames in the future. I'm happy I went gigabit and I'm happy I went Vista SP1 and I'm happy I went Cat6.
无论如何，事实证明SMB2是比SMB1更好的协议。 就我而言，已解决了问题，我到处都升级到了Vista SP1，并享受在线的磁盘速度。 现在，根据所涉及的机器的磁盘等复制大型文件时，在没有巨型帧的情况下，机器之间的速度最高可达33MB / s，而在巨型磁盘上，则达到66MB / s。 将来，我一定会只获得支持巨型帧的网卡。 我很高兴能达到千兆位，我很高兴能进入Vista SP1，我很高兴能达到Cat6。
Whew. I was worried I'd have to tear my walls open. ;)
ew。 我担心我得把墙壁拆开。 ;)
扫一扫
2231
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
