Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!super!law From: law@super.ORG (Jeffrey A Law) Newsgroups: comp.benchmarks Subject: Re: Sparcstation 2 Write I/O Summary: Lousy code in fstime.c Message-ID: <43414@super.ORG> Date: 21 Feb 91 05:48:19 GMT References: <1085@rna.UUCP> <156@edi386.UUCP> Sender: news@super.ORG Organization: Supercomputing Research Center, Bowie, Md. Lines: 61 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >On 18 Feb 91 12:42:25 GMT, eddjp@edi386.UUCP ( Dewey Paciaffi ) said: >eddjp> In article <1085@rna.UUCP> dan@rna.UUCP (Root Beer) writes: >dan> In article <152@edi386.UUCP> eddjp@edi386.UUCP ( Dewey Paciaffi ) writes: > >eddjp> I've found an anomaly I can't explain on my borrowed Sparcstation 2. >eddjp> I've been running the Byte Magazine Benchmarks and the file I/O times >eddjp> 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 */ } else { if (errno != EINTR) { perror("you lose"); return (-1); } else stop_count(); } } ++nblocks; } Well, under SunOS and 4.3 BSD a read just returns 0 at EOF (and sometimes I've seen in errno set to EINTR). So loops written like the one above will essentially scan over the file only once. The simple fix is to save the value returnd from the read and properly handle the case where the read/write returned zero but did not set errno. 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. 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.. >I think that a better test, even if it is a system test and not just an >IO subsystem test, is to use bonnie. Remember: bonnie is a benchmark >that also tests cache effectiveness if any, in its random IO section. So true. Jeff -- 1987: We set standards, not Them. Your standard windowing system is NeUWS. 1989: We set standards, not Them. You can have X, but the UI is OpenLock. 1990: Why are you buying all those workstations from Them running Motif? Brought to you by Super Global Mega Corp .com