Hi, > Can't find such piece of code in version 1.3.2.
Urm ... yes. The comment appeared in 1.3.4. In 1.3.2 it is done = scsi_eval_cmd_outcome(d, c, fp, s.sbp, s.sb_len_wr, start_time, s.timeout, i, 0); if (d->cancel) done = 1; } which would become done = scsi_eval_cmd_outcome(d, c, fp, s.sbp, s.sb_len_wr, start_time, s.timeout, i, 0); if (d->cancel) done = 1; usleep(10000); } > #define Libburn_sg_linux_retry_usleeP 100000 > #define Libburn_sg_linux_retry_incR 100000 This seems to be a remnant of older code. Thrown out with commit 3483, but already disabled by 3368. Now it is in libburn/spc.c function scsi_eval_cmd_outcome(). The macros are in libburn/spc.h /* The waiting time before eventually retrying a failed SCSI command. Before each retry wait Libburn_scsi_retry_incR longer than with the previous one. At most wait for Libburn_scsi_retry_umaX microseconds. */ #define Libburn_scsi_write_retry_usleeP 0 #define Libburn_scsi_write_retry_incR 2000 #define Libburn_scsi_write_retry_umaX 25000 The equivalent to my code change proposal would have been #define Libburn_scsi_write_retry_usleeP 10000 #define Libburn_scsi_write_retry_incR 0 #define Libburn_scsi_write_retry_umaX ...whatever... It seems already to work in e.g. 1.3.8. The differences of the timestamps [ 2880923 ] [ 2884447 ] [ 2890019 ] [ 2899397 ] minus the execution times 5778 , 1410, 1475 yield non-SCSI-execution timegaps of 36, 2114, 4097 microseconds. I.e. the repetition spent most time at a waiting time of 25000 microseconds. So i change my proposal to setting in libburn/spc.c : #define Libburn_scsi_write_retry_usleeP 10000 #define Libburn_scsi_write_retry_incR 5000 #define Libburn_scsi_write_retry_umaX 100000 This reduces the workload during the first 50 seconds to 25 percent of the current one. At 16 x DVD speed it risks that the driver buffer runs empty. Let's see. During the following time it will reduce the number of unsuccessful retries substantially. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org