Douglas Garstang
2006-Oct-09 14:00 UTC
[asterisk-users] Asterisk RT on Disk On Module PerformanceandDurability
I'd be curious to know what you come up with, because we're using MySQL, and I'd rather not!> -----Original Message----- > From: Aaron Daniel [mailto:amdtech@shsu.edu] > Sent: Monday, October 09, 2006 2:48 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: RE: [asterisk-users] Asterisk RT on Disk On Module > PerformanceandDurability > > > Very very carefully ;) I'm thinking pizza, and maybe some red-bull... > very little time for sleep > > Aaron > > On Mon, 2006-10-09 at 14:19 -0600, Douglas Garstang wrote: > > I'm just going to jump in here, and ask a stoopid question. > > > > How could you possibly write a multi-user front end in AJAX without > > using a database backend like MySQL? > > > > Doug. > > -----Original Message----- > > From: Erick Perez [mailto:eaperezh@gmail.com] > > Sent: Monday, October 09, 2006 1:58 PM > > To: Asterisk Users Mailing List - Non-Commercial Discussion > > Subject: Re: [asterisk-users] Asterisk RT on Disk On Module > > Performance andDurability > > > > > > Jeremy, Cohen, Kris, thanks to all of you. > > > > Indeed after reading the Sandisk paper it shed a > lot of light > > on this matter. The whole idea is to have a large > scale system > > with no moving parts (we call a large system something > > with 250 users, at least down here ;-) ) > > > > the whole idea is for a customer that needs an IVR in 4 > > languages with autoattendant, extensive CDR and > plotted usage > > patterns as well as voicemail. Voicemail will be > used *a lot*, > > probably about one thousand voicemails per day and the > > customer does not want VM-to-Email (God knows why!). > > > > Oh, and the whole idea of the database is because the > > developers are working in an AJAX based interface that does > > the asterisk config/plotting/vm/day-to-day stuff > with ARA, so > > a db is needed. > > I started learning asterisk with flat files...it works for > > me...but hey...times are changing. > > > > Who knows, maybe the whole thing can be fitted in > ram (except > > for the vm part)...we'll see. I had to ask anyway, > but i don't > > like Dbs either....it adds and extra breakup layer (maybe Im > > kind of outdated). > > > > Smaller iPBXs will definitely be CF and RAM based and I, at > > least, will force VMtoEmail and do all the > processing in RAM. > > > > Again, > > > > Thanks to all of you. > > > > P.D. I will later follow this thread with the full working > > configs that will take place at user premises. And for the > > sake of the test. I will try to kill a sandisk USB with the > > full config. > > > > > > On 10/8/06, Kristian Kielhofner <kris@krisk.org> wrote: > > Jeremy McNamara wrote: > > > Tzafrir Cohen wrote: > > > > Hmmmm, I'm not sure that this is > exactly the data > > you're after. > > >> > > >> You're looking for the ammounts of writes for the > > disk block that gets > > >> the most writes. > > >> > > >> E.g: for a standard ext3 filesystem, the journal > > area would probably > > >> have very frequent writes, whereas most of the > > system would remain > > >> mostly unchanged. > > > > > > > > > Again, if the embedded system is setup properly, > > there is NO writing to > > > the flash during normal operations, thus > the device > > won't be killed by > > > its alleged 2 million write limitation. > > > > > > Kris and I had a quick discussion on this topic, > > off-list, and his > > > original flash-based device is still in constant > > operation after 2 years > > > and I have flash modules that I purposely tried to > > kill with writes. It > > > took significant effort to start causing error > > situations, which were > > > very easily detected before the system > would become > > unusable. > > > > > > Erick, you should focus on having a quick action > > restoration plan and > > > extra DOMs always readily available. Then when a > > failure situation is > > > detected, you can react very quickly. > > > > > > > > > > > > > > > Jeremy McNamara > > > > Jeremy, Erick - > > > > I have always pointed to this SanDisk > > whitepaper: > > > > > http://www.sandisk.com/Assets/File/OEM/WhitePapersAndBrochures > /RS-MMC/WPaperWearLevelv1.0.pdf > > > > While it specifically discusses their > > industrial line of CF cards, it > > is pretty obvious that flash can, and often > does, last > > much longer than > > other components in a system when properly > > implemented. You will notice > > that the SHORTEST expected life of a CF > card in their > > test scenarios was > > over 70 years! How long is your power > supply going to > > last? Even if > > the consumer level cards had 1/10 the life > expectancy, > > that is still > > seven years. I expect to get at least that from my > > original AstLinux > > system. It's been two so far, I'll let you know how > > it is doing in > > another five years :). > > > > JFFS (and similar FSs) are not > appropriate for > > CF cards or DOMs. They > > are meant to be used directly on flash memory and do > > their own wear > > leveling and in some cases, compression. > All kinds of > > commercial > > devices use JFFS2. If you are using a CF > or DOM with > > Linux, ext2 is the > > best FS to use. CF cards and DOMs use > their own wear > > leveling, so none > > is required in the operating system or file > > system. CF cards and DOMs > > hide wear leveling from you and expose themselves as > > an ordinary IDE device. > > > > I echo Jeremy's conclusions. With a properly > > designed operating > > system, decent flash memory, and a reasonable usage > > pattern, I can tell > > you (with a great amount of certainty) that in most > > situations, CF cards > > will outlast just about any hard drive (even SCSI) > > when used 24/7. > > These days, it really is pretty tough to > trash flash. > > > > However, if you are running a MySQL > cluster or > > something with several, > > multi-gigabyte databases, no type of flash > memory will > > last very long! :) > > > > To get back to answering your question, I > > HIGHLY recommend that you > > avoid MySQL and realtime on your box with a > > DOM. Nothing against either > > (MySQL or Realtime), but they will probably > make your > > device more > > complicated than it needs to be while substantially > > shortening the life > > of your DOM. If you absolutely have to use > MySQL, you > > might have better > > luck using a MySQL storage engine that uses fewer > > writes than InnoDB, > > but I am no expert on that. > > > > -- > > Kristian Kielhofner > > _______________________________________________ > > --Bandwidth and Colocation provided by > Easynews.com -- > > > > asterisk-users mailing list > > To UNSUBSCRIBE or update options visit: > >http://lists.digium.com/mailman/listinfo/asterisk-users> > > > -- > ------------------------------------------------------------ > Erick Perez > Panama Sistemas > Integradores de Telefonia IP y Soluciones Para Centros de > Datos > Panama, Republica de Panama > Cel Panama. +(507) 6694-4780 > ------------------------------------------------------------ > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users-- Aaron Daniel Computer Systems Technician Sam Houston State University amdtech@shsu.edu (936) 294-4198 _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Douglas Garstang
2006-Oct-09 15:32 UTC
[asterisk-users] Asterisk RT on Disk On Module PerformanceandDurability
I was thinking about it purely from the perspective of multiple access to flat files.... :) -----Original Message----- From: Erick Perez [mailto:eaperezh@gmail.com] Sent: Monday, October 09, 2006 3:44 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] Asterisk RT on Disk On Module PerformanceandDurability Douglas, Im just the asterisk guy. If they decide to write a cross-browser multi-tier interface in AJAX, assembly language or Pascal, that's up to them (the programmers). I will let them know what can/can't be done. Thinking of that...15 years ago...the last time i used pascal. On 10/9/06, Douglas Garstang < dgarstang@oneeighty.com> wrote: I'm just going to jump in here, and ask a stoopid question. How could you possibly write a multi-user front end in AJAX without using a database backend like MySQL? Doug. -----Original Message----- From: Erick Perez [mailto: <mailto:eaperezh@gmail.com> eaperezh@gmail.com] Sent: Monday, October 09, 2006 1:58 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] Asterisk RT on Disk On Module Performance andDurability Jeremy, Cohen, Kris, thanks to all of you. Indeed after reading the Sandisk paper it shed a lot of light on this matter. The whole idea is to have a large scale system with no moving parts (we call a large system something with 250 users, at least down here ;-) ) the whole idea is for a customer that needs an IVR in 4 languages with autoattendant, extensive CDR and plotted usage patterns as well as voicemail. Voicemail will be used *a lot*, probably about one thousand voicemails per day and the customer does not want VM-to-Email (God knows why!). Oh, and the whole idea of the database is because the developers are working in an AJAX based interface that does the asterisk config/plotting/vm/day-to-day stuff with ARA, so a db is needed. I started learning asterisk with flat files...it works for me...but hey...times are changing. Who knows, maybe the whole thing can be fitted in ram (except for the vm part)...we'll see. I had to ask anyway, but i don't like Dbs either....it adds and extra breakup layer (maybe Im kind of outdated). Smaller iPBXs will definitely be CF and RAM based and I, at least, will force VMtoEmail and do all the processing in RAM. Again, Thanks to all of you. P.D. I will later follow this thread with the full working configs that will take place at user premises. And for the sake of the test. I will try to kill a sandisk USB with the full config. On 10/8/06, Kristian Kielhofner < kris@krisk.org > wrote: Jeremy McNamara wrote:> Tzafrir Cohen wrote: > > Hmmmm, I'm not sure that this is exactly the data you're after. >> >> You're looking for the ammounts of writes for the disk block that gets >> the most writes. >> >> E.g: for a standard ext3 filesystem, the journal area would probably >> have very frequent writes, whereas most of the system would remain >> mostly unchanged. > > > Again, if the embedded system is setup properly, there is NO writing to > the flash during normal operations, thus the device won't be killed by > its alleged 2 million write limitation. > > Kris and I had a quick discussion on this topic, off-list, and his > original flash-based device is still in constant operation after 2 years > and I have flash modules that I purposely tried to kill with writes. It > took significant effort to start causing error situations, which were > very easily detected before the system would become unusable. > > Erick, you should focus on having a quick action restoration plan and > extra DOMs always readily available. Then when a failure situation is > detected, you can react very quickly. > > > > > Jeremy McNamaraJeremy, Erick - I have always pointed to this SanDisk whitepaper: http://www.sandisk.com/Assets/File/OEM/WhitePapersAndBrochures/RS-MMC/WPaperWearLevelv1.0.pdf <http://www.sandisk.com/Assets/File/OEM/WhitePapersAndBrochures/RS-MMC/WPaperWearLevelv1.0.pdf> While it specifically discusses their industrial line of CF cards, it is pretty obvious that flash can, and often does, last much longer than other components in a system when properly implemented. You will notice that the SHORTEST expected life of a CF card in their test scenarios was over 70 years! How long is your power supply going to last? Even if the consumer level cards had 1/10 the life expectancy, that is still seven years. I expect to get at least that from my original AstLinux system. It's been two so far, I'll let you know how it is doing in another five years :). JFFS (and similar FSs) are not appropriate for CF cards or DOMs. They are meant to be used directly on flash memory and do their own wear leveling and in some cases, compression. All kinds of commercial devices use JFFS2. If you are using a CF or DOM with Linux, ext2 is the best FS to use. CF cards and DOMs use their own wear leveling, so none is required in the operating system or file system. CF cards and DOMs hide wear leveling from you and expose themselves as an ordinary IDE device. I echo Jeremy's conclusions. With a properly designed operating system, decent flash memory, and a reasonable usage pattern, I can tell you (with a great amount of certainty) that in most situations, CF cards will outlast just about any hard drive (even SCSI) when used 24/7. These days, it really is pretty tough to trash flash. However, if you are running a MySQL cluster or something with several, multi-gigabyte databases, no type of flash memory will last very long! :) To get back to answering your question, I HIGHLY recommend that you avoid MySQL and realtime on your box with a DOM. Nothing against either (MySQL or Realtime), but they will probably make your device more complicated than it needs to be while substantially shortening the life of your DOM. If you absolutely have to use MySQL, you might have better luck using a MySQL storage engine that uses fewer writes than InnoDB, but I am no expert on that. -- Kristian Kielhofner _______________________________________________ --Bandwidth and Colocation provided by Easynews.com <http://easynews.com/> -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: <http://lists.digium.com/mailman/listinfo/asterisk-users> http://lists.digium.com/mailman/listinfo/asterisk-users -- ------------------------------------------------------------ Erick Perez Panama Sistemas Integradores de Telefonia IP y Soluciones Para Centros de Datos Panama, Republica de Panama Cel Panama. +(507) 6694-4780 ------------------------------------------------------------ _______________________________________________ --Bandwidth and Colocation provided by Easynews.com <http://easynews.com/> -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- ------------------------------------------------------------ Erick Perez Panama Sistemas Integradores de Telefonia IP y Soluciones Para Centros de Datos Panama, Republica de Panama Cel Panama. +(507) 6694-4780 ------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20061009/b360a7f2/attachment.htm