The cut-over in the data center to the new Cisco 6509 is moving apace. By Friday everything in there will be on the new switch. One of the happy side effects is that now all of the data center is on Gig-Ether ports. Not that we have much that pushes that kind of data, but still, nice to have.
In Benchmarking news, I'm still building the testing protocol. But one thing has shown itself one more time. Back in the original benchmark I noticed an artifact in the data. The IOZONE "random read" test shows a troff in the NCP-on-NetWare data. When using a 64kb record size, there is a marked decrease in performance. It showed up in the original data, and in some of the test runs I've just completed. The hardware behind the January test and this one is different, the server is a bit older but this older server is hooked up to the SAN.
This is sample data. For the 8MB file size, you can see the three record sizes either side of the 64kb line. The performance drop exhibited there is repeated throughout the whole random read test. I wonder why that particular record size is so slow?
In Benchmarking news, I'm still building the testing protocol. But one thing has shown itself one more time. Back in the original benchmark I noticed an artifact in the data. The IOZONE "random read" test shows a troff in the NCP-on-NetWare data. When using a 64kb record size, there is a marked decrease in performance. It showed up in the original data, and in some of the test runs I've just completed. The hardware behind the January test and this one is different, the server is a bit older but this older server is hooked up to the SAN.
| 32kb | 64kb | 128kb | |
| 8128KB | 9216 | 8450 | 9101 |
This is sample data. For the 8MB file size, you can see the three record sizes either side of the 64kb line. The performance drop exhibited there is repeated throughout the whole random read test. I wonder why that particular record size is so slow?