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