Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!edi386!eddjp From: eddjp@edi386.UUCP ( Dewey Paciaffi ) Newsgroups: comp.benchmarks Subject: Re: Sparcstation 2 Write I/O Message-ID: <160@edi386.UUCP> Date: 21 Feb 91 17:58:18 GMT References: <156@edi386.UUCP> <43414@super.ORG> Reply-To: eddjp@edi386.UUCP ( Dewey Paciaffi ) Organization: J.M. Huber Corp., Edison,NJ Lines: 59 In article <43414@super.ORG> law@super.ORG (Jeffrey A Law) writes: - In article <152@edi386.UUCP> eddjp@edi386.UUCP ( Dewey Paciaffi ) writes: - -> I've found an anomaly I can't explain on my borrowed Sparcstation 2. -> I've been running the Byte Magazine Benchmarks and the file I/O times -> were surprisingly low, around 270 kb / sec. on read and writes. -[ lots of interesting, but in this case useless dribble deleted ] - -I've been watching this thread for a little while and nobody has -thought to really question the benchmark's accuracy (byte/README): - -"BSD4v2 only: The time functions in the memory and and [sic] file -access tests appear to be incorrect" - -Which just happens to be right! fstime.c has loops that look like: - -while(!sigalarm) { - if ((read(fd,buf,count) <= 0) { - if (errno == EINVAL) { - lseek(fd, 0l, 0); /* rewind at EOF */ -[Further code deleted]- The above actually caused a failure under AIX 3.1, causing me to repair that area of the code some months ago. This is not the question. You can write a very simple program that contains a simple loop writing a 1K buffer to disk until you write 10MB, and it will take about 37 seconds. Any buffer size less than 8K (or somewhere between 4K and 8K ) will take about 37 seconds to write 10MB. I have run this on two Sparc2 systems in different areas of the country and they both respond the same. Use the csh builtin 'time'. Use the Sys5 'time'. Use Ext. and Int. drives. I've tried them all after breaking the problem down to it's most basic component, and I've found Sparc2 systems running about 270 kb consistently when writing buffers < 8K in size. Is this significant ?? I don't know :-). -The lessons to be learned here are: - -1) Read the documentation. That would have at least made you wonder - a little more about a possible real problem, rather than trying to - explain it away with caches, read sizes and other factors. Which I did. And, with the results that I posted yesterday, it appears the the write system call transfer speed varys precisely and dramatically with the size of the buffer being written. I'm trying to explain a result, not explain it away. I'm also offering it for refutation. I'm interested in accuracy. Actually, I thought I'd uncovered a kernel problem with the Write System Call. -2) If results seem way out of line with other data something is probably - very wrong in your data gathering or generation. Question the validity - of the data before trying to explain it away.. Which is why I wrote a program that does nothing more that transfer data to the disk and check for errors. I posted that program. Has anyone been able to find my error ( which I haven't discounted by any means ), corroborate my results, or obtain better results when transferring buffers which are less than 8K in size ? -- Dewey Paciaffi ...!uunet!edi386!eddjp Brought to you by Super Global Mega Corp .com