[3721] in linux-scsi channel archive
Re: ncr53c8xx-2.6i test results
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Sat Apr 18 04:02:58 1998
Date: Sat, 18 Apr 1998 08:49:11 +0200 (MET DST)
From: Gerard Roudier <groudier@club-internet.fr>
To: "Larry M. Augustin" <lma@varesearch.com>
cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <199804180017.RAA03231@cray.varesearch.com>
On Fri, 17 Apr 1998, Larry M. Augustin wrote:
> Gerard,
>
> Here are some new results with ncr53c8xx-2.6i. I ran Bonnie and
> Iozone on two Ultra2 drives simultaneously. The results weren't bad.
> For Iozone:
>
> 1 drive: 13389.05 read / 9621.50 write
> 2 drives: 11608.85 read / 7092.95 write
>
> Not bad. I will append the complete results.
>
> Unfortunately, I don't have the complete system log, but here's some
> pieces of dmesg output you may want to see.
>
> Larry
>
> ------------------------------------------------------------------------
>
> ncr53c895-1-<3,0>: max active commands 18.
> ncr53c895-1-<3,0>: QUEUE FULL! 0 busy, 16 disconnected CCBs - max tags set to 16
> ncr53c895-1-<3,0>: max active commands 17.
> ncr53c895-1-<3,0>: QUEUE FULL! 0 busy, 15 disconnected CCBs - max tags set to 15
> ncr53c895-1-<3,0>: max active commands 16.
[ ... ]
In ncr53c8xx-2.6j, these messages are only written to the log with driver
verbosity level >= 2.
The current heuristic used by the driver for QUEUE FULL handling seems to
even make Atlas I L912 happy.
2.6i was unable to handle QUEUE FULL with zero command disconnected.
2.6j seems to behave reasonnably in such a situation.
Note that my experience is that disabling write behind caching for LXY4
Atlas II firmware revision gets rid of QUEUE FULL status without impacting
overall I/O performances.
When you are stressed Linux using several Bonnie benchmarks concurrently,
actual write chunks get smaller and QUEUE FULL statuses may me reported
due to internal firmware queue handling limits.
Not using write behing caching does not preclude the firmware from using
buffers for data having to be written. The device only reports GOOD status
when data has been actually copied to the medium.
The device will probably disconnected the bus slightly more often.
Write behind caching by firmware is interesting for systems that are doing
synchronous writes for meta-data from the kernel and that want to allow
disks firmware to just do the opposite, breaking as a result, the initial
assumption. ;-)
Perhaps guys are thinking that disks firmware are far less broken than
their kernel software. ;-)
If we are using a not small number of tags and if the kernel does
well write behind caching and coalescing, it is not interesting IMO to
enable drive's write behind caching. Remember that drives have small
caches and that prefetching is very important for lowering latency.
If you flood the drive with lots of data, you decrease the average number
of buffers for data prefetching or you may also force the firmware to
throw away prefetched data in order to perform write behind caching.
Trying to be as fast as a rabbit may lead to be as stupid as this animal
in some situations. ;-) (remake)
> --- 2 drives ------------------------------------------------------------
>
> Mem: 62920K av, 26792K used, 36128K free, 836K shrd, 21968 buff
> Swap: 130748K av, 228K used, 130520K free
> Bonnie --------Sequential Output---------- ---Sequential Input---- ---Random--
> -Per Char-- ---Block--- --Rewrite-- -Per Char-- ---Block--- ---Seeks---
> Directory MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> /u2 244 4856 49.3 6438 15.7 4907 22.2 7167 51.2 12973 19.8 111.5 3.2
> /u2 244 4748 48.4 7417 18.3 4901 22.1 7332 51.1 12861 18.4 107.4 5.9
> /u2 244 4748 48.2 7056 16.9 4878 22.0 6980 50.9 12273 18.8 115.3 9.2
> /u2 244 4677 47.8 6997 17.4 5077 22.0 7220 50.3 12858 19.9 125.4 13.4
> /u2 244 4925 50.3 7820 19.2 4991 23.0 6467 47.6 12634 19.8 111.8 15.0
> Average 244 4790 48.8 7145 17.5 4950 22.3 7033 50.2 12719 19.3 114.3 9.3
>
> Iozone Size Rec Length Read Rate Write Rate
> Directory Mbytes bytes Kbytes/sec Kbytes/sec
> /u2 244 512 10718.83 7322.86
> /u2 244 512 10830.34 6900.19
> /u2 244 512 10963.41 6616.95
> /u2 244 512 13040.50 6312.68
> /u2 244 512 12499.05 6703.94
> /u2 244 512 11290.38 7058.08
> /u2 244 512 11852.75 7886.87
> /u2 244 512 11675.51 7942.02
> Average 244 512 11608.85 7092.95
[ ... ]
Write speed is abnormaly slow. This may indicate that stressing
to much the buffer cache makes linux behave bad with memory
balancing as throwing away pages of Bonnie programs and so having
to uselessly load/unload pages during benchmark execution.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
