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 - 100kb) I've solved this for me when writting bigger fixed packets by feeding them in parts but that allows buffer underruns. Is the kmalloc limit of 128kb reasonable in the time of GB RAMs? And is the test in cdrom_do_cmd (cdrom.c) good? if (cgc->buflen < 0 || cgc->buflen >= 131072) return -EINVAL; wouldn't this be enough (to allow exactly 128kb pass)? if (cgc->buflen < 0 || cgc->buflen > 131072) return -EINVAL; 4. IMO the sync_cache() in the write_file should be moved ouf ot the loop as I've done for the above measurements. With frequent syncing, the throughput was about 50kb/s Is it enough to put the stuff here or do I have to fill it in some bug tracking system myself? Peter Osterlund wrote:

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

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 <><

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