24 Jul
2004
24 Jul
'04
4:48 a.m.
On Sat, 2004-07-24 at 01:46, Lee Revell wrote:
On Sat, 2004-07-24 at 00:07, Lee Revell wrote:
I repeated the test with 'bonnie -f' and without jackd running, and with
32KB vs. 1024KB. The results are not as drastic, which suggests that
all the overhead from the XRUN tracing was a factor.
These results show that 32KB is better than 1024KB in some areas, and
not singificantly worse in any of these metrics.
32KB:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
mindpipe 1G 38499 68 16383 28 35913 34 154.5 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 257 99 +++++ +++ 24008 98 256 99 +++++ +++ 1179 98
mindpipe,1G,,,38499,68,16383,28,,,35913,34,154.5,1,16,257,99,+++++,+++,24008,98,256,99,+++++,+++,1179,98
1024KB:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
mindpipe 1G 38285 60 13961 20 33694 28 155.2 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 259 99 +++++ +++ 24250 98 256 99 +++++ +++ 1184 98
mindpipe,1G,,,38285,60,13961,20,,,33694,28,155.2,1,16,259,99,+++++,+++,24250,98,256,99,+++++,+++,1184,98
Lee
On Tue, 2004-07-20 at 08:19, Jens Axboe wrote:
OK, here are my bonnie test results. They are not what I expected -
read and write performance is significantly better with 16KB max request
size, while seeking is much better with 1024KB.
On Tue, Jul 20 2004, Ingo Molnar wrote:
I am currently testing the effect on throughput and will have some
better numbers soon. > How much I/O do you allow to be in flight at
once? It seems like by
> decreasing the maximum size of I/O that you handle in one interrupt
> you could improve this quite a bit. Disk throughput is good enough,
> anyone in the real world who would feel a 10% hit would just throw
> hardware at the problem.
it's not tweakable right now, but if you wish to experiment you just
need to add a line to ide-disk.c:idedisk_setup() - pseudo patch:
+ blk_queue_max_sectors(drive->queue, 32);
+