|
So far, we have been examining local IO performance using Windows 2000. As networking and broadband have become more ubiquitous, file-sharing performance is becoming more important, even within the home. In this section, we briefly examine network IO performance using CIFS, the Common Internet File System. CIFS was chosen because it is the network file system most commonly used with Windows NT and Windows 2000 installations. This section is a brief overview rather than a comprehensive study of the intricate world of network IO performance. In our configuration, we measured a point-to-point connection with very low latency. Networks with greater latency or multiple streams may see different results.
We connected the new-new Dell Precision 420 to a comparable Dell Precision 410 machine with two 750MHz PIII processors and 256MB SDRAM. In order to ensure that the disks on the Precision 410 were not the bottleneck, we used three Atlas 10K drives and used RAID0 to create a stripe set. Local throughput on the Precision 410 was greater than that of the highest throughput we were able to achieve through our simple Gigabit Ethernet LAN. We used two SysKonnect SK-9821 copper Gigabit Ethernet cards and a single crossover cable to connect the two computers together. Both computers were running Windows 2000 Server with the addition of the alpha versions of the SysKonnect drivers for the SK-9821. We got a 7% increase in throughput with the following registry key settings. All tests reported here use these settings:
The keys are all relative to
Hkey_local_machine\System\CurrentControlSet\Services\Tcpip\Parameters
MaximumFrameSize = 9014 /* use jumbo frames
NumberOfReceiveBuffers = 100 /* use memory if you need it
NumberofTransmitBuffers = 50 /* ditto
MaxIRQperSec = 2500 /* interrupt coalescing
/* and moderation
The tests were run using the same methodology that we applied to local IO. The UNC and mapped drive tests were run on the new-new machine. The network tests were run on the new-new machine with it as the client and the Precision 410 as the server. We wanted to see what out-of-box performance we could attain.
Figure 36 shows both read and write throughput to a local Quantum Atlas 10K disk using both Universal Naming Convention (UNC) path (such as \\lchung\e$) and a network mapped drive (the network share \\lchung\e$ masquerades as drive F:). Compared with accessing the local drive directly, accessing the disk through UNC paths and mapped drives gives substantially lower performance – especially if requests are larger than 16KB.
Mapped drives show better read performance than UNC paths at request sizes of 64KB and above. Where our mapped drive ran at near disk-speed with large requests, UNC reads dropped to the one and two MB per second range. As the request size increased, the throughput decreased. Interestingly, mapped drives showed good performance at large request sizes, however additional depth caused throughput to decrease. Overall, a depth of two seemed to be the optimum value for both UNC and mapped drives, reading and writing. For good performance, drives should be mapped rather than accessed using their UNC paths.
Unlike reads, writes showed disappointing results for both UNC and mapped drives. Throughput increased with request size until disk speed was achieved with 16KB requests, then suddenly dropped to 2.1MBps with 32KB requests, and finally plateaued at 5.5MBps to 6MBps – showing conclusively that size does matter!
|
