[asterisk-users] Asterisk RT on Disk On Module Performance andDurability

Mon Oct 9 14:44:04 MST 2006

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 at 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:eaperezh at 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 at 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<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
> ------------------------------------------------------------
>
>
> _______________________________________________
> --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/4f0c4999/attachment.htm