Todd Chauvin wrote:
> -------Sequential Output-------- ---Sequential Input-- --Random--
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> Client K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> 2.2.14(v2) 245 3.4 156 0.2 352 0.6 7535 99.9 254938 99.6 173.3 0.9
> 2.2.14(v3-udp) 690 10.1 705 1.0 567 1.2 7337 99.3 250028 97.7 613.1 2.9
> 2.2.14(v3-tcp) 582 8.5 861 0.7 865 1.0 7373 99.8 254065 99.2 46.7 0.4
> solaris7 922 16.3 851 2.1 523 1.8 919 13.1 947 1.6 26.1 2.1
Michael Clark puzzled:
^^^^^^
What's the story with the 250Mb/sec sequential block rate? Is the linux
client caching this data? Should it really be doing this?
I guess this is bonnie. I'm not sure about its internals, but in the
Connectathon test suite, the following discards cached data and allows
for meaningful over-the-wire reports:
#ifdef MMAP
maddr = mmap((caddr_t)0, (size_t)size, PROT_READ,
MAP_PRIVATE, fd, (off_t)0);
if (maddr == NULL) {
error("can't mmap '%s'", bigfile);
exit(1);
}
if (msync(maddr, (size_t)size, MS_INVALIDATE) < 0) {
error("can't invalidate pages for '%s'", bigfile);
exit(1);
}
if (munmap(maddr, (size_t)size) < 0) {
error("can't munmap '%s'", bigfile);
exit(1);
}
#endif
I was delighted when someone at Sun sent me that code to try out several
years ago and found it worked for us. I'm not certain that Posix
requires this work, someone here once broached the idea of changing it,
but concluded we'd be better off with the status quo.
-Ric Werme
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:12 EST