Re: two questions concerning fast burning and burn-free
On Wed, 16 Jul 2003, Matthias Schniedermeyer wrote: On Wed, Jul 16, 2003 at 12:54:03AM +0200, Norbert Preining wrote: I have two questions concerning burning with/without burn-free: The first: How fast is it theoretically possible with an UDMA100 harddisk to burn *without* burnfree protection? If I burn with my plextor premium at full speed I would always get buffer underruns. With the upcoming Linux-2.6 Kernel you will be able to burn with full speed because the 2.6-Kernel can talk to the burner in DMA mode. Current 2.4 Kernel isn't capable of doing this. That's only true for non 2048 block sizes (audio, (S)VCD, RAW)). regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Wed, Jul 16, 2003 at 09:11:02AM +0200, Markus Plail wrote: On Wed, 16 Jul 2003, Matthias Schniedermeyer wrote: On Wed, Jul 16, 2003 at 12:54:03AM +0200, Norbert Preining wrote: I have two questions concerning burning with/without burn-free: The first: How fast is it theoretically possible with an UDMA100 harddisk to burn *without* burnfree protection? If I burn with my plextor premium at full speed I would always get buffer underruns. With the upcoming Linux-2.6 Kernel you will be able to burn with full speed because the 2.6-Kernel can talk to the burner in DMA mode. Current 2.4 Kernel isn't capable of doing this. That's only true for non 2048 block sizes (audio, (S)VCD, RAW)). Actually, I have 4 52x burners on a UDMA100 chipset (AMD 760MPX Southbridge). The hard drives are on their own UDMA133 controller (Promise 20269). I can burn to all four at full speed on linux 2.4.20 without dipping too far into the writer cache, where full speed is 24x at the hub and 52x at the rim. ...now, that took some fiddling to achieve; most of the controllers (and possibly corresponding kernel drivers) I tried were *awful* at handling atapi devices. Welcome to the world of consumer-grade hardware. Even the $200 ATA133 add on cards never seemed to get 16x if they worked properly at all. The only controller/driver combo I found that worked beautifully happened to be the onboard Southbridge itself... so I moved all the CDROMs to the Southbridge controller, and the hard drives to the add-on controller (which sucked for CDROMs, but works beautifully for hard drives). Monty -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Mit, 16 Jul 2003, Matthias Schniedermeyer wrote: With the upcoming Linux-2.6 Kernel you will be able to burn with full speed because the 2.6-Kernel can talk to the burner in DMA mode. Current 2.4 Kernel isn't capable of doing this. On Mit, 16 Jul 2003, Markus Plail wrote: That's only true for non 2048 block sizes (audio, (S)VCD, RAW)). Does this mean * 2.6+ can talk to burner in DMA for all block sizes or that * 2.4 can talk to burner in DMA, but only for 2048 block sizes. If the later, is there a kernel patch necessary for this? Generally, are there any patches which would increase the throughput? On Mit, 16 Jul 2003, Monty wrote: Actually, I have 4 52x burners on a UDMA100 chipset (AMD 760MPX Southbridge). The hard drives are on their own UDMA133 controller (Promise 20269). I can burn to all four at full speed on linux 2.4.20 I have the burner at the secondary IDE controller of my mainboards VIA686 controller, and the hard disk on my first controller: --VIA BusMastering IDE Configuration Driver Version: 3.37 South Bridge: VIA vt82c686b Revision: ISA 0x40 IDE 0x6 Highest DMA rate: UDMA100 BM-DMA base:0xa000 PCI clock: 33.3MHz Master Read Cycle IRDY:0ws Master Write Cycle IRDY:0ws BM IDE Status Register Read Retry: yes Max DRDY Pulse Width: No limit ---Primary IDE---Secondary IDE-- Read DMA FIFO flush: yes yes End Sector FIFO flush: no no Prefetch Buffer: yes no Post Write Buffer:yes no Enabled: yes yes Simplex only: no no Cable Type: 80w 40w ---drive0drive1drive2drive3- Transfer Mode: UDMA UDMA UDMA UDMA Address Setup: 30ns 30ns 30ns 30ns Cmd Active: 90ns 90ns 90ns 90ns Cmd Recovery:30ns 30ns 30ns 30ns Data Active: 90ns 90ns 90ns 90ns Data Recovery: 30ns 30ns 30ns 30ns Cycle Time: 20ns 20ns 60ns 60ns Transfer Rate: 99.9MB/s 99.9MB/s 33.3MB/s 33.3MB/s I thought that this is not intrinsically a problem! Best wishes Norbert --- Norbert Preining preining AT logic DOT at Technische Universität Wien gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- VANCOUVER (n.) The technical name for one of those huge trucks with whirling brushes on the bottom used to clean streets. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Wed, 16 Jul 2003, Norbert Preining wrote: On Mit, 16 Jul 2003, Matthias Schniedermeyer wrote: With the upcoming Linux-2.6 Kernel you will be able to burn with full speed because the 2.6-Kernel can talk to the burner in DMA mode. Current 2.4 Kernel isn't capable of doing this. On Mit, 16 Jul 2003, Markus Plail wrote: That's only true for non 2048 block sizes (audio, (S)VCD, RAW)). Does this mean * 2.6+ can talk to burner in DMA for all block sizes When using dev=/dev/hdX, yes, but Jörg doesn't like that implementation. or that * 2.4 can talk to burner in DMA, but only for 2048 block sizes. Yes, exactly. If the later, is there a kernel patch necessary for this? Generally, are there any patches which would increase the throughput? Nope, just compile in support for your chipset. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Wed, Jul 16, 2003 at 09:11:02AM +0200, Markus Plail wrote: On Wed, 16 Jul 2003, Matthias Schniedermeyer wrote: On Wed, Jul 16, 2003 at 12:54:03AM +0200, Norbert Preining wrote: I have two questions concerning burning with/without burn-free: The first: How fast is it theoretically possible with an UDMA100 harddisk to burn *without* burnfree protection? If I burn with my plextor premium at full speed I would always get buffer underruns. With the upcoming Linux-2.6 Kernel you will be able to burn with full speed because the 2.6-Kernel can talk to the burner in DMA mode. Current 2.4 Kernel isn't capable of doing this. That's only true for non 2048 block sizes (audio, (S)VCD, RAW)). Ups. I have to admit that i never burned via IDE directly. I jumped directly from SCSI to Firewire because i hadn't had a free 5 1/4 slot in my case. Sorry for the confusion. Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Mit, 16 Jul 2003, Joerg Schilling wrote: If you like to write at maximum speed, you _need_ to disable Burn-Free because the drive reduces the maximum write speed if Burn-Free has been enabled! OK, I understand. If you like to write in 52x, you just need a OS that implements DMA. Hmm. Does this mean that, if the transferspeed TO the burner is too slow, ie not UDMA but PIO, these underruns can occur? I always thought that this is a matter of to slow hard disks not delivering the data fast enough. So, burning DATA should work in DMA33 modus at least, while burning audio is only in PIO mode an thus slow. What are the *theoretically* maximum speeds for audio, ie not DMA, burning? I guess that it is around 12x, this is what I see at the final speed result. Best wishes Norbert --- Norbert Preining preining AT logic DOT at Technische Universität Wien gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- TIBSHELF (n.) Criss-cross wooden construction hung on a wall in a teenage girl's bedroom which is covered with glass bambies and poodles, matching pigs and porcelain ponies in various postures. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
From: Norbert Preining [EMAIL PROTECTED] I have two questions concerning burning with/without burn-free: The first: How fast is it theoretically possible with an UDMA100 harddisk to burn *without* burnfree protection? If I burn with my plextor premium at full speed I would always get buffer underruns. If you like to write at maximum speed, you _need_ to disable Burn-Free because the drive reduces the maximum write speed if Burn-Free has been enabled! If you like to write in 52x, you just need a OS that implements DMA. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
From: Matthias Schniedermeyer [EMAIL PROTECTED] The first: How fast is it theoretically possible with an UDMA100 harddisk to burn *without* burnfree protection? If I burn with my plextor premium at full speed I would always get buffer underruns. With the upcoming Linux-2.6 Kernel you will be able to burn with full speed because the 2.6-Kernel can talk to the burner in DMA mode. This seems to be good hope... Current 2.4 Kernel isn't capable of doing this. This is not always true. The problem is that there is no unique method that allows to set up DMA for all transport implementations and there are plety of them because there is no coordination for a unique API. If people try to start working on a decent unique ABI, Linus Torvalds usually blocks them :-( Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Overburn protection
[EMAIL PROTECTED] wrote: ...only if you need to have your files read on a Linux system. For other situations, writing large files might be quite reasonable and you might need to switch to a tool that will write such files. If Linux tools are aimed only at readers that are unable to honor the full ISO9660 specification, then you might have to use non-Linux tools in this situation. Is the myth that Linux can't handle files over 2GB still alive? Perhaps the application was compiled without support for large files... I don't recall seeing largefile support in any of the cdrtools build, but I certainly never looked for it, either. There may be a limit of 2GB in an isofs mount, I have no way to test that which doesn't involve creating and burning a DVD. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dvd+rw-tools problems
Dan wrote: Hi Andy, thanks for the response The hue's changed, the disc looks pretty much full except for a small rim around the outside of the disc. Also dvd+r-tools won't let me burn over it again so that seems to notice that it's already been recorded on. I've tried the burned dvd's in my laptop's dvd drive and I get the same type of problem: That shoots my theory that you needed to eject and then reinsert (which may still be true). mount: wrong fs type, bad option, bad superblock on /dev/cdroms/cdrom0, or too many mounted file systems While I didn't try playing back any dvd's or copying any files off them in the TDK drive, I did try mounting one and that worked ok, and I could ls the files on it. Unfortunately the day after I had sent that email lightning hit a tree outside my house and to make a long story short fried the onboard lan on my motherboard among other things, so my motherboard is out being repaired/replaced and I won't have it back for a week or two to test out anything with the TDK drive, so bear with me. I haven't tried burning any cd-r's in the drive yet so I think I'll give that a shot when I get it back. It's worth mentioning that I'm burning on kernel 2.5.72-mm2, I haven't tried burning a dvd with a 2.4.x kernel yet. Also cdrecord-proDVD refuses to burn with this drive at all, though I can't remember the error off the top of my head. Thanks for your help, -Dan Do try it with a more working kernel. I have no problems with 2.4.18, 20 or 21, but the 2.5 has some issues with ide-scsi (may be fixed, Doug?) and using ide devices directly as ATAPI. There were some changes for cdrecord post to LKML, I don't know if they made it to the official source code or forks like dvdrtools, etc. I suggest booting a nice stock kernel and doing a burn, then using that as a data point. If it works you can search for what's broken. I highly comment the -wli kernels for desktop! -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
Old-Return-Path: [EMAIL PROTECTED] If you like to write in 52x, you just need a OS that implements DMA. Hmm. Does this mean that, if the transferspeed TO the burner is too slow, ie not UDMA but PIO, these underruns can occur? I always thought that this is a matter of to slow hard disks not delivering the data fast enough. So, burning DATA should work in DMA33 modus at least, while burning audio is only in PIO mode an thus slow. What are the *theoretically* maximum speeds for audio, ie not DMA, burning? I guess that it is around 12x, this is what I see at the final speed result. The max PIO speed depends on many things and is between 12x and 40x. Sometimes you get faster with slower CPUs Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
Joerg Schilling wrote: From: Rob Bogus [EMAIL PROTECTED] As someone who does not use Linux, I would say it is not the user's fault. When that bit is set, it means the first extent is Macintosh resource fork data. That bit was put into the standard specifically for that purpose. Linux should make it _extremely_ difficult to handle an extent flagged in that fashion as anything but a resource fork (and Linux likely has no use for a resource fork except when serving files to Macintoshes). The user deliberately selected an option to make those forks visible. Linux doesn't (deliberately) make things dificult, it just makes the default safe in most cases, and allows you to make a choice. If you ask to see the fork you can't complain that the fork is visible. Solaris does support extended attributes and could be made able to make the files visible in a decent way ;-) I have no Mac to try, I do have some Solaris machines, although I normally just use them as servers. Does this mean that Solaris could be a a fileserver for Macs? Or just that Solaris would let you see and/or use the forks in a useful way? In any case, my point was that if you ask for something unpleasant to happen, it's not the o/s fault. Implementing "rm -r /" is not a Linux "bug," or Solaris or AIX or whatever. Distributed intelligence means above and below the keyboard. -- E. Robert Bogusta It seemed like a good idea at the time
Re: Overburn protection
Is the myth that Linux can't handle files over 2GB still alive? No. Perhaps the application was compiled without support for large files... It's not an application issue (the check performed by mkisofs is artificial, it's not some kind of wrap-around bug, it won't treat e.g. 4GB+1 bytes large file as 1 byte), nor some *common/general* kernel deficiency. It's Linux isofs filesystem driver implementation issue. I also want to remind that I was answering a particular question and the question was about 4.3GB file. Once again, if you break 2GB-2 bytes barrier (actually alpha mkisofs versions do it already), it's still only part of requires solution, as you would need mkisofs to implement support for multi-extent files to break the 4GB-1 byte barrier. As for ...only if you need to have your files read on a Linux system. ISO9660 is about data interchange, isn't it? You don't know in advance where it will have to be read and therefore want your recordings to be normalized to some least common denominator. ISO9660 by itself sets perfect example for such denominator by insisting on that stupid 8.3 directory structure being present. In either case, as you can't patch all Linux kernels in the world over one night, you better be aware of this issue and stick to 2GB-2 bytes boundary. It's unfortunate, but practical choice. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
Linus Torvalds usually blocks them :-( May I make a suggestion? Joerg! Next time you feel like claiming that Linus Torvalds (or anybody else in person, Alan Cox maybe?) is so to say sitting around and deliberately tries to complicate your life as cdrecord developer, then I suggest to take a deep breath and abstain from such remarks. Not that they are simply not true, such comments are generally inappropriate for essentially technical forum such as this. If you want to criticize, criticize technologies and their implementations, but not persons. If personal comment is unavoidable, explicitly address the person in question. Same naturally applies to all subscribers to this forum. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ISO 9660 file size (was: Overburn protection)
[EMAIL PROTECTED] (Andy Polyakov) quoted and then wrote: As for ...only if you need to have your files read on a Linux system. ISO9660 is about data interchange, isn't it? You don't know in advance where it will have to be read and therefore want your recordings to be normalized to some least common denominator. ISO9660 by itself sets perfect example for such denominator by insisting on that stupid 8.3 directory structure being present. In either case, as you can't patch all Linux kernels in the world over one night, you better be aware of this issue and stick to 2GB-2 bytes boundary. It's unfortunate, but practical choice. A. You are correct that ISO-9660 allows an implementation to restrict itself to Interchange Level 2, meaning files consist of a single file section. If a Linux system only handles Level 2 ISO-9660 structures, it should be documented as having that restriction. Ideally, it would detect a disc that does not conform to that restriction and issue a clear error message to the user. The restriction to 8.3 filenames would be Interchange Level 1, and is not limited to the Directory Hierarchy identified in the Primary Volume Descriptor. It also applies to any Directory Hierarchy identified by a Supplementary Volume Descriptor. Perhaps you have confused this with the restriction on valid characters outlined in section 7.4.4 of the ISO 9660 standard. So nothing in ISO 9660 differentiates between the various Directory Hierarchies regarding 8.3 filename restrictions, but perhaps some authors (or even authoring tools) follow such a restriction only for the Directory Hierarchy identified in the Primary Volume Descriptor as a pragmatic step toward compatibility with some unspecified operating system (PC DOS?). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
From [EMAIL PROTECTED] Wed Jul 16 15:36:51 2003 Linus Torvalds usually blocks them :-( May I make a suggestion? Joerg! Next time you feel like claiming that Linus Torvalds (or anybody else in person, Alan Cox maybe?) is so to say sitting around and deliberately tries to complicate your life as cdrecord developer, then I suggest to take a deep breath and abstain from such remarks. Not that they are simply not true, such comments are generally inappropriate for essentially technical forum such as this. If you want to criticize, criticize technologies and their implementations, but not persons. If personal comment is unavoidable, explicitly address the person in question. Same naturally applies to all subscribers to this forum. A. First: it is Linus who started to be personal against me, so he obviously likes this way of discussion Second: I was not critizising the person but the doings. If you read through the Linux Kernel mailing list for long enough, you understand even why: Linus is missing the needed know how to understand what a interface is and in addition he refuses to learn about good programming practice. He e.g. even refuses to have a look at the FreeBSD kernel source in order to understand that my claims about common proctice in SCSI programming is (in contrast to his claims) true. Well, it is not bad it a person is missing the background knowledge for a specific topic, but it is bad if such a person likes to decide on such a topic. Let me make an example: A few weeks ago, Jeff Garzik announced a new SCSI interface for ATAPI. http://marc.theaimsgroup.com/?t=10539253612r=3w=2 If you read this thread, you see that Linus obviously does not understand the background and likes the implementation to be better than anything before, before giving Jeff a chance. As it should be obvious that a draft of a new implementation method never is made complete just in order to save time, a knowledgeable programmer would be able to understand whether a new idea could give problems in the future. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Wed, 16 Jul 2003, Joerg Schilling wrote: Let me make an example: A few weeks ago, Jeff Garzik announced a new SCSI interface for ATAPI. http://marc.theaimsgroup.com/?t=10539253612r=3w=2 If you read this thread, you see that Linus obviously does not understand the background and likes the implementation to be better than anything before, before giving Jeff a chance. As it should be obvious that a draft of a new implementation method never is made complete just in order to save time, a knowledgeable programmer would be able to understand whether a new idea could give problems in the future. What you don't tell is, that this implementation is in recent 2.4-ac kernels and thus it has a fair chance of being incorporated in plain 2.4 or 2.6 sometime. Of course you are right that Linus didn't like it. He just has *very* different view on this matter compared to yours. Let's just hope that this thing crawls into mainline. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Wed, Jul 16, 2003 at 10:24:37AM +0200, Markus Plail wrote: or that * 2.4 can talk to burner in DMA, but only for 2048 block sizes. Yes, exactly. Why is it then that this problem seems to affect only VIA 686b and Intel ICH4 southbridges? I'll have to admit I only run a 16x burner, but with my current SiS745 based motherboard I have no problems burning anything at 16x, while it was awful with my 686b based motherboard (effective speed 14x and computer totally bogged down during writing). I just got a pair of emails from people who had read my year old post (http://marc.theaimsgroup.com/?l=linux-kernelm=101826880719379w=2) to linux-kernel asking if there's a fix. The only solutions I know are 1) different chipset for the motherboard 2) Linux 2.5.x or 2.6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Wed, 16 Jul 2003, Anssi Saari wrote: On Wed, Jul 16, 2003 at 10:24:37AM +0200, Markus Plail wrote: or that * 2.4 can talk to burner in DMA, but only for 2048 block sizes. Yes, exactly. Why is it then that this problem seems to affect only VIA 686b and Intel ICH4 southbridges? I'll have to admit I only run a 16x burner, but with my current SiS745 based motherboard I have no problems burning anything at 16x, while it was awful with my 686b based motherboard (effective speed 14x and computer totally bogged down during writing). I have no idea. I also didn't have any problems with my SiS735 and an acer2010, but there is simply no code in the kernel to allow DMA so it can't be used. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
