Influence of buffer size and command queueing on the scan speed of the Sharp JX-250 with Sane and Linux

The JX-250 is, compared to many other cheaper scanners, relatively fast – an A4 size 400 dpi gray scale scans need only approximately 10 seconds – [1], but it has obviously a very small internal buffer. This means that, after the data transfer of a "read scan data" command has been finished, the next "read scan data" command must be issued as fast as possible to avoid scan head stops.

In order to get an idea about the importance of efficient command queueing and buffer size for the scan speed of the JX-250 with Sane und Linux, I made a number of tests with different configurations.

I used the following hardware:

Pentium 100MHz, 32 MB RAM, NEC D3827 SCSI disk and the JX250 connected to an Adaptec 2940 (not 2940U)
Pentium 100MHz, 32 MB RAM, NEC D3827 SCSI disk and the JX250 connected to a SCSI adapter with a Symbios 53C810A chip
Celeron 433MHz, 128 MB RAM, NEC D3827 SCSI disk and the JX250 connected to an Adaptec 2940 (not 2940U)

For Scans without command queueing and with command queueing on the level of the Sane SCSI library, I used the Linux kernel version 2.2.7 with the SG driver 2.1.34; for command queueing on the level of the SG driver, I used the Linux kernel version 2.2.14 with the SG driver 2.1.36. All tests were made with a current (February 2000) Sane CVS version, which supports the queueing capabilities of the newer Linux SG drivers.

I made 4 scans for the following setups:

gray scale scan
scan size 216 x 297 mm
resolution 200 dpi, 300 dpi, 400 dpi
queueing:
- no SCSI command queueing ("option readqueue" in sharp.conf set to 1); kernel 2.2.7; SG driver 2.1.34; "off" in table columns "queue" below
- queueing within the Sane SCSI library; "option readqueue" in sharp.conf set to 2; kernel 2.2.7; SG driver 2.1.34; "old" in table columns "queue" below
- queueing by the SG driver; "option readqueue" in sharp.conf set to 2; kernel 2.2.14; SG driver 2.1.36; "new" in table columns "queue" below
buffer size 32k, 64, 128k, 256 kB ("option buffersize" in sharp.conf)
"option buffers" in sharp.conf set to 4

The following command was used for the scans: time scanimage -d sharp:/dev/scanner -l 0 -t 0 -x 216 -y 297 --mode Gray --resolution RES > /dev/null (RES as listed in the tables below)

In order to get additional activity on the SCSI bus, I ran a dd if=/dev/sda of=/dev/null bs=512 in parallel to some of the scans. This constant usage of the SCSI bus is of course not very realistic -- but it should give at least some idea about the influence of other devices connected to the SCSI bus on the scan speed.

Despite the daemons installed on an ordinary Suse Linux 6.1, no other programs were running during the tests.

Results

Celeron 433 / Adaptec 2940

resolution queue buffer size "dd if=/dev/sda .."
running scan time (sec) scan head stops

200 off 32k no 6.2..8.3 no

200 off 32k yes 6.3..8.4 no

300 off 32k no 7.8..8.4 no

300 off 32k yes 19.7..22.4 yes

300 off 64k yes 8.0..8.4 no

400 off 32k no 28.6..29.8 yes

400 off 64k no 20.4..21.8 yes

400 off 128k no 16.4..17.7 yes

400 off 256k no 12.4..12.6 yes

300 old 32k yes 18.4..19.9 yes

300 old 64k yes 8.2..9.8 no

400 old 32k no 28.5..28.6 yes

400 old 64k no 20.4..20.5 yes

400 old 128k no 12.3..13.7 yes

400 old 256k no 9.6..9.8 no

400 old 256k yes 15.2..15.5 yes

400 old 512k yes 9.8..11.3 no

300 new 32k no 7.8..8.0 no

300 new 32k yes 19.7..19.8 yes

300 new 64k yes 7.9..8.0 no

400 new 32k no 27.1..27.2 yes

400 new 64k no 16.3..16.4 yes

400 new 128k no 9.6..9.7 no

400 new 128k yes 28.7..30.0 yes

400 new 256k yes 15.2..15.3 yes

400 new 512k yes 9.8..9.9 no

Celeron 433 / Adaptec 2940
resolution	queue	buffer size	"dd if=/dev/sda .." running	scan time (sec)	scan head stops
200	off	32k	no	6.2..8.3	no
200	off	32k	yes	6.3..8.4	no
300	off	32k	no	7.8..8.4	no
300	off	32k	yes	19.7..22.4	yes
300	off	64k	yes	8.0..8.4	no
400	off	32k	no	28.6..29.8	yes
400	off	64k	no	20.4..21.8	yes
400	off	128k	no	16.4..17.7	yes
400	off	256k	no	12.4..12.6	yes
300	old	32k	yes	18.4..19.9	yes
300	old	64k	yes	8.2..9.8	no
400	old	32k	no	28.5..28.6	yes
400	old	64k	no	20.4..20.5	yes
400	old	128k	no	12.3..13.7	yes
400	old	256k	no	9.6..9.8	no
400	old	256k	yes	15.2..15.5	yes
400	old	512k	yes	9.8..11.3	no
300	new	32k	no	7.8..8.0	no
300	new	32k	yes	19.7..19.8	yes
300	new	64k	yes	7.9..8.0	no
400	new	32k	no	27.1..27.2	yes
400	new	64k	no	16.3..16.4	yes
400	new	128k	no	9.6..9.7	no
400	new	128k	yes	28.7..30.0	yes
400	new	256k	yes	15.2..15.3	yes
400	new	512k	yes	9.8..9.9	no

Pentium 100 MHz / Adaptec 2940

resolution queue buffer size "dd /dev/sda .."
running scan time (sec) scan head stops

200 off 32k no 7.7..8.4 no

200 off 32k yes 7.8..8.7 no

300 off 32k no 7.9..8.7 for some scans

300 off 32k yes 20.0..20.1 yes

300 off 64k yes 8.4..8.5 no

400 off 32k no 37.9..38.1 yes

400 off 64k no 31.2..31.4 yes

400 off 128k no 29.8..29.9 yes

400 off 256k no 25.8..25.9 yes

300 old 32k no 19.8..20.1 yes

300 old 64k no 8.2..8.6 no

300 old 64k yes 8.1..8.5 no

400 old 32k no 31.7..32.6 yes

400 old 64k no 25.8..25.9 yes

400 old 128k no 20.5..21.9 yes

400 old 256k no 16.4..16.5 yes

400 old 512k no 15.1..15.2 yes

300 new 32k no 8.1..9.4 no

300 new 32k yes 18.8..20.5 yes

300 new 64k yes 8.5..8.7 no

400 new 32k no 27.1..27.6 yes

400 new 64k no 16.4..16.5 yes

400 new 128k no 9.7..9.8 no

400 new 128k yes 30.2..30.6 yes

400 new 256k yes 15.6..15.7 yes

400 new 512k yes 10.2..10.3 no

Pentium 100 MHz / Adaptec 2940
resolution	queue	buffer size	"dd /dev/sda .." running	scan time (sec)	scan head stops
200	off	32k	no	7.7..8.4	no
200	off	32k	yes	7.8..8.7	no
300	off	32k	no	7.9..8.7	for some scans
300	off	32k	yes	20.0..20.1	yes
300	off	64k	yes	8.4..8.5	no
400	off	32k	no	37.9..38.1	yes
400	off	64k	no	31.2..31.4	yes
400	off	128k	no	29.8..29.9	yes
400	off	256k	no	25.8..25.9	yes
300	old	32k	no	19.8..20.1	yes
300	old	64k	no	8.2..8.6	no
300	old	64k	yes	8.1..8.5	no
400	old	32k	no	31.7..32.6	yes
400	old	64k	no	25.8..25.9	yes
400	old	128k	no	20.5..21.9	yes
400	old	256k	no	16.4..16.5	yes
400	old	512k	no	15.1..15.2	yes
300	new	32k	no	8.1..9.4	no
300	new	32k	yes	18.8..20.5	yes
300	new	64k	yes	8.5..8.7	no
400	new	32k	no	27.1..27.6	yes
400	new	64k	no	16.4..16.5	yes
400	new	128k	no	9.7..9.8	no
400	new	128k	yes	30.2..30.6	yes
400	new	256k	yes	15.6..15.7	yes
400	new	512k	yes	10.2..10.3	no

Pentium 100 MHz / Symbios 53C810A

resolution queue buffer size "dd /dev/sda .."
running scan time (sec) scan head stops

200 off 32k off 6.8..8.4 no

200 off 32k on 6.4..9.0 no

300 off 32k off 7.9..8.7 no

300 off 32k on 20.2..21.5 yes

300 off 64k on 8.5..8.7 no

400 off 32k off 28.6..29.9 yes

400 off 64k off 16.5..17.8 yes

400 off 128k off 9.7..9.8 no

400 off 128k on 14.3..15.4 yes

400 off 256k on 15.7..18.4 yes

400 off 512k on 21.2..23.8 yes

300 old 32k on 20.1..21.5 yes

300 old 64k on 8.6..9.9 no

400 old 32k off 23.2..24.9 yes

400 old 64k off 9.7..9.8 no

400 old 64k on 37.0..37.3 yes

400 old 128k on 14.4..14.6 yes

400 old 256k on 10.2..10.3 no

300 new 32k off 7.9..8.2 no

300 new 32k on 20.0..20.4 yes

300 new 64k on 8.5..9.1 no

400 new 32k off 17.8..18.1 yes

400 new 64k off 9.7..9.8 no

400 new 64k on 36.9..37.3 yes

400 new 128k on 14.3..14.4 yes

400 new 256k on 10.2..10.3 no

400 new 512k on 10.3..10.4 no

Pentium 100 MHz / Symbios 53C810A
resolution	queue	buffer size	"dd /dev/sda .." running	scan time (sec)	scan head stops
200	off	32k	off	6.8..8.4	no
200	off	32k	on	6.4..9.0	no
300	off	32k	off	7.9..8.7	no
300	off	32k	on	20.2..21.5	yes
300	off	64k	on	8.5..8.7	no
400	off	32k	off	28.6..29.9	yes
400	off	64k	off	16.5..17.8	yes
400	off	128k	off	9.7..9.8	no
400	off	128k	on	14.3..15.4	yes
400	off	256k	on	15.7..18.4	yes
400	off	512k	on	21.2..23.8	yes
300	old	32k	on	20.1..21.5	yes
300	old	64k	on	8.6..9.9	no
400	old	32k	off	23.2..24.9	yes
400	old	64k	off	9.7..9.8	no
400	old	64k	on	37.0..37.3	yes
400	old	128k	on	14.4..14.6	yes
400	old	256k	on	10.2..10.3	no
300	new	32k	off	7.9..8.2	no
300	new	32k	on	20.0..20.4	yes
300	new	64k	on	8.5..9.1	no
400	new	32k	off	17.8..18.1	yes
400	new	64k	off	9.7..9.8	no
400	new	64k	on	36.9..37.3	yes
400	new	128k	on	14.3..14.4	yes
400	new	256k	on	10.2..10.3	no
400	new	512k	on	10.3..10.4	no

Thus, both an efficient command queueing and larger buffers can be essential in order to avoid carriage stops for resolutions of 300 and 400 dpi. This is especially evident for the Pentium/Adaptec combination: At 400 dpi, scans head stop can be avoided only, if command queueing on SG driver level is possible., and if a buffer size of 256kB is used.

An interesting "side result" is the fact, that the quite old and cheap 100 MHz Pentium box with a Symbios 53C810 SCSI adapter can be more efficient than the Celeron 433 with teh Adaptec 2940. I do not know, if the Symbios adapter is so more efficient than the Adaptec adapter, of if the respective Linux drivers are that different.

As a general conclusion, it seems to be a good idea to use a buffer size of 128kB or 256kB for scans with 300 dpi and above, unless a system has real memory shortages.

Finally, it must be pointed out that the results shown above do not give a guarantee, that large buffers and efficient command queueing avoid any scan head stop. "Real life" situations are generally more complicated. The Gimp for example can consume a considerable amount of memory, so that the kernel might need to swap some memory in order to allocate the buffers for scanimage and the SG driver.

Acknowlegdements

Douglas Gilbert, the maintainer of the Linux SG driver, answered many questions about several details of the SG driver, when I worked on the queueing implementation in the Sane SCSI library. Andreas Beck gave very useful suggestions, especially regarding the backward compatibility of the implementation of varaiable buffer size in the Sane SCSI library.

Abel Deuring

[1] More precisely, the time for the command


scanimage -d sharp -l 0 -t 0 -x 216 -y 297 --mode Gray --Xresolution 
400 --Yresolution 400 > /dev/null

is approximately 10 seconds. This figure does not include the time needed to move the scan head back to the idle position, which is around 8 seconds. [back]