Hi! I have uploaded a new packet patch for kernel 2.4.18-pre2 to: http://w1.894.telia.com/~u89404340/patches/packet/packet-2.4.18-pre2.patch.b... There are two performance improvements: * The 2.4.18-pre2 kernel has a fix to better sort the request queue when requests can not be merged. This fix will in some cases improve write performance, because previously the same packet was sometimes written more than once to the disc. * File-level read-ahead has been enabled for the pktcdvd device. This improves read performance, especially when doing something more advanced than just reading single large files. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
Hi developers,
I've been doing some performance measurements and I realized
(among other things) that dd if=/dev/sr0 is about 4x faster
than dd if=/dev/pktcdvd0 on the same device/disc.
I've tracked it to the point of ro_open() calling pkt_adjust_speed(0xff)
which causes an overflow in pkt_set_speed:
speed = speed * 0xb0; // == 44880
read_speed = (speed * 3) >> 1; // == 67320
now the code tries to stuff the number into two bytes
I've worked it around using:
if(read_speed > 65472) read_speed = 65472;
but it may be simplier to pass 248 to pkt_adjust_speed.
Now to the other things:
I was experimenting with different packet sizes, so I have
few questions at first:
Is the UDF (spec) fs independent on the size of packets?
Does the udffs implementation work with other than 32sec packets?
Is the pktcdvd layer able to deal with bigger packets on write?
Will other OSes read/write udf discs with other packet size?
So I was comparing writes on bigger packets, on 10x medium in 10x burner.
For 32sec packets it was writing at effective speed ~4
For 512sec packets it was writing at effective speed ~8
Now you see where I'm aiming at - it may be better to use bigger
packet sizes for some kind of data or using aggresive write aggregation.
You'll get more space and faster access. In the case of 512sec/pkt
you'll get the random acces capability nearly for free (about
640MB usable on usual 74min disc).
BTW: Why do I get only ~8x even when writing near end?
The vendor (yamaha) claims it does partial CAV and is capable
of 10x for RWs in packet mode in CAV. Do I have to setup
writing page in different way to alow CAV?
I have also some bug reports against cdrwtool:
1. :o)
* Drives tested and known to work:
* - HP 8210i, 9xxx (progress indicator works)
* - Sony CRX100E (without progress indicator)
* - Yamaha CRW6416SX (SCSI, no progress indicator)
+ * - Yamaha CRW2100S (SCSI)
* - Plextor PlexWriter 12/4/32
2. cdrwtool stores packet size in char which is too little
3. if writing variable packets, cdrwtool would get EINVAL
from ioctl because it would try to pass bigger buffer than 128k
(it tries
Hi!
I have uploaded a new packet patch for kernel 2.4.18-pre2 to:
http://w1.894.telia.com/~u89404340/patches/packet/packet-2.4.18-pre2.patch.b...
There are two performance improvements:
* The 2.4.18-pre2 kernel has a fix to better sort the request queue when requests can not be merged. This fix will in some cases improve write performance, because previously the same packet was sometimes written more than once to the disc.
* File-level read-ahead has been enabled for the pktcdvd device. This improves read performance, especially when doing something more advanced than just reading single large files.
-- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
-- To unsubscribe, e-mail: packet-writing-unsubscribe@suse.com For additional commands, e-mail: packet-writing-help@suse.com
On Wed, Jan 09, 2002 at 12:17:00AM +0100, Petr Nejedly wrote:
Is the UDF (spec) fs independent on the size of packets? Does the udffs implementation work with other than 32sec packets? Is the pktcdvd layer able to deal with bigger packets on write? Will other OSes read/write udf discs with other packet size?
The only part of UDF that cares about the packet size is sparing, so you can run with whatever packet size you want (as long as the sparing tables are created correctly).. But it's very unlikely it would be cross platform. The spec allows the recording of packet size, but requires it to be 32 for CDRW media. (for fixed packets) Ben
Am Mittwoch, 9. Januar 2002 02:51 schrieb Ben Fennema:
The only part of UDF that cares about the packet size is sparing, so you can run with whatever packet size you want (as long as the sparing tables are created correctly).. But it's very unlikely it would be cross platform. The spec allows the recording of packet size, but requires it to be 32 for CDRW media. (for fixed packets)
The scsi drivers (at least 2.4 and earlier) might also have problems with larger packets. It already breaks on controllers with sg_tablesize < 32 (e.g. aha1542 and a few more), but for 128 sector packets, it would break on many more of them (e.g. sym53c8xx) that then would have sg_tablesize < packet_size. OTOH, with 16 sector packets, it might work on the currently unsupported controllers. There are also drives that don't follow the standard exactly and give some undefined behaviour for anything that is not used by other OSs. Arnd <><
Arnd Bergmann wrote:
Am Mittwoch, 9. Januar 2002 02:51 schrieb Ben Fennema:
The only part of UDF that cares about the packet size is sparing, so you can run with whatever packet size you want (as long as the sparing tables are created correctly).. But it's very unlikely it would be cross platform. The spec allows the recording of packet size, but requires it to be 32 for CDRW media. (for fixed packets)
The scsi drivers (at least 2.4 and earlier) might also have problems with larger packets. It already breaks on controllers with sg_tablesize < 32 (e.g. aha1542 and a few more), but for 128 sector packets, it would break on many more of them (e.g. sym53c8xx) that then would have sg_tablesize < packet_size. OTOH, with 16 sector packets, it might work on the currently unsupported controllers. There are also drives that don't follow the standard exactly and give some undefined behaviour for anything that is not used by other OSs.
Excuse my ignorance (I'm not an expert on the block layer), but wouldn't it be possible to advertise pkt device as having blocks as large as the packet is? Or better, do this only for interfacing buffer-cache to let it have all the data in one chunk, and keep the fs interface 2kb based as the OSTA udf2.0 spec requires: udf2.0 par. 6.10.2.1: The host shall perform read/modify/write to enable the apparent writing of single 2K sectors.
Arnd <><
-- To unsubscribe, e-mail: packet-writing-unsubscribe@suse.com For additional commands, e-mail: packet-writing-help@suse.com
I'm a bit closer to working UDF writing on Yamaha CRW2100S. I've added explicit cache syncing to the beginning of pkt_gather_data and now I'm able to mount a disc, do a bit of writing and umount it cleanly. If I write too much, it fails: pkt_request: cmd=1, rq=c49f3b40, rq->sector=18304, rq->nr_sectors=128 wake up wait queue handle_queue do_request: bh=7864335, nr_sectors=128, size=128, cmd=1 __pkt_inject_request: list_empty == 1, size=4, cmd=1 (scsi0:A:3:0): data overrun detected in Data-in phase. Tag == 0x3. (scsi0:A:3:0): Have seen Data Phase. Length = 2048. NumSGs = 1. sg[0] - Addr 0x04836000 : Length 2048 (scsi0:A:3:0): data overrun detected in Data-in phase. Tag == 0x3. (scsi0:A:3:0): Have seen Data Phase. Length = 2048. NumSGs = 1. sg[0] - Addr 0x04836000 : Length 2048 (scsi0:A:3:0): data overrun detected in Data-in phase. Tag == 0x3. (scsi0:A:3:0): Have seen Data Phase. Length = 2048. NumSGs = 1. sg[0] - Addr 0x04836000 : Length 2048 Does anybody know what does it mean? Where can be the problem now? To Petr O.: Will you patch the pktdcvd.c to pkt_adjust_speed(248) instead of 255? It makes a huge difference for me and presumably for others. Petr
On Sun, 13 Jan 2002, Petr Nejedly wrote:
To Petr O.: Will you patch the pktdcvd.c to pkt_adjust_speed(248) instead of 255? It makes a huge difference for me and presumably for others.
Yes, I will fix that problem somehow. I'm not yet sure what the best solution is though. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
participants (4)
-
Arnd Bergmann -
Ben Fennema -
Peter Osterlund -
Petr Nejedly