<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.5700.6" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=839543122-09102006><FONT face=Arial color=#0000ff size=2>I was
thinking about it purely from the perspective of multiple access to flat
files.... :)</FONT></SPAN></DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Erick Perez
[mailto:eaperezh@gmail.com]<BR><B>Sent:</B> Monday, October 09, 2006 3:44
PM<BR><B>To:</B> Asterisk Users Mailing List - Non-Commercial
Discussion<BR><B>Subject:</B> Re: [asterisk-users] Asterisk RT on Disk On
Module PerformanceandDurability<BR><BR></FONT></DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>Thinking of that...15 years ago...the last time i used pascal.</DIV>
<DIV><BR><BR> </DIV>
<DIV><SPAN class=gmail_quote>On 10/9/06, <B class=gmail_sendername>Douglas
Garstang</B> <<A
href="mailto:dgarstang@oneeighty.com">dgarstang@oneeighty.com</A>>
wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>I'm just going to jump in
here, and ask a stoopid question.</FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>How could you possibly
write a multi-user front end in AJAX without using a database backend
like MySQL?</FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>Doug.</FONT></SPAN></DIV>
<DIV><SPAN class=e id=q_10e2ebd4e4d7ad3c_1>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
<DIV dir=ltr align=left><FONT face=Tahoma size=2>-----Original
Message-----<BR><B>From:</B> Erick Perez [mailto:<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:eaperezh@gmail.com" target=_blank>
eaperezh@gmail.com</A>]<BR><B>Sent:</B> Monday, October 09, 2006 1:58
PM<BR><B>To:</B> Asterisk Users Mailing List - Non-Commercial
Discussion<BR><B>Subject:</B> Re: [asterisk-users] Asterisk RT on Disk On
Module Performance andDurability <BR><BR></FONT></DIV>
<DIV>Jeremy, Cohen, Kris, thanks to all of you.</DIV>
<DIV> </DIV>
<DIV>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 ;-) ) </DIV>
<DIV> </DIV>
<DIV>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!). </DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV>I started learning asterisk with flat files...it works for me...but
hey...times are changing.</DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV>Smaller iPBXs will definitely be CF and RAM based and I, at least,
will force VMtoEmail and do all the processing in RAM.</DIV>
<DIV> </DIV>
<DIV>Again,</DIV>
<DIV> </DIV>
<DIV>Thanks to all of you.</DIV>
<DIV><BR>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.</DIV>
<DIV><BR> </DIV>
<DIV><SPAN class=gmail_quote>On 10/8/06, <B
class=gmail_sendername>Kristian Kielhofner</B> <<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:kris@krisk.org" target=_blank>kris@krisk.org</A> >
wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Jeremy
McNamara wrote:<BR>> Tzafrir Cohen wrote:<BR>> >
Hmmmm, I'm not sure that this is exactly the data you're after.
<BR>>><BR>>> You're looking for the ammounts of writes for
the disk block that gets<BR>>> the most
writes.<BR>>><BR>>> E.g: for a standard ext3 filesystem, the
journal area would probably<BR>>> have very frequent writes,
whereas most of the system would remain<BR>>> mostly
unchanged.<BR>><BR>><BR>> Again, if the embedded system is
setup properly, there is NO writing to<BR>> the flash during normal
operations, thus the device won't be killed by <BR>> its alleged 2
million write limitation.<BR>><BR>> Kris and I had a quick
discussion on this topic, off-list, and his<BR>> original flash-based
device is still in constant operation after 2 years<BR>> and I have
flash modules that I purposely tried to kill with writes. It <BR>>
took significant effort to start causing error situations, which
were<BR>> very easily detected before the system would become
unusable.<BR>><BR>> Erick, you should focus on having a quick
action restoration plan and <BR>> extra DOMs always readily
available. Then when a failure situation is<BR>> detected,
you can react very quickly.<BR>><BR>><BR>><BR>><BR>>
Jeremy McNamara<BR><BR>Jeremy, Erick
-<BR><BR> I have always pointed to
this SanDisk whitepaper: <BR><BR><A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://www.sandisk.com/Assets/File/OEM/WhitePapersAndBrochures/RS-MMC/WPaperWearLevelv1.0.pdf"
target=_blank>http://www.sandisk.com/Assets/File/OEM/WhitePapersAndBrochures/RS-MMC/WPaperWearLevelv1.0.pdf
</A><BR><BR> While it specifically
discusses their industrial line of CF cards, it <BR>is pretty obvious
that flash can, and often does, last much longer than<BR>other
components in a system when properly implemented. You will
notice <BR>that the SHORTEST expected life of a CF card in their test
scenarios was <BR>over 70 years! How long is your power
supply going to last? Even if<BR>the consumer level cards had
1/10 the life expectancy, that is still <BR>seven years. I
expect to get at least that from my original
AstLinux<BR>system. It's been two so far, I'll let you know
how it is doing in<BR>another five years
:).<BR><BR> JFFS (and similar FSs)
are not appropriate for CF cards or DOMs. They <BR>are meant
to be used directly on flash memory and do their own wear <BR>leveling
and in some cases, compression. All kinds of
commercial<BR>devices use JFFS2. If you are using a CF or DOM
with Linux, ext2 is the<BR>best FS to use. CF cards and DOMs
use their own wear leveling, so none<BR>is required in the operating
system or file system. CF cards and DOMs<BR>hide wear
leveling from you and expose themselves as an ordinary IDE device.
<BR><BR> I echo Jeremy's
conclusions. With a properly designed operating <BR>system,
decent flash memory, and a reasonable usage pattern, I can tell<BR>you
(with a great amount of certainty) that in most situations, CF cards
<BR>will outlast just about any hard drive (even SCSI) when used 24/7.
<BR>These days, it really is pretty tough to trash
flash.<BR><BR> However, if you are
running a MySQL cluster or something with several,<BR>multi-gigabyte
databases, no type of flash memory will last very long! :)
<BR><BR> To get back to answering
your question, I HIGHLY recommend that you<BR>avoid MySQL and realtime
on your box with a DOM. Nothing against either<BR>(MySQL or
Realtime), but they will probably make your device more <BR>complicated
than it needs to be while substantially shortening the life<BR>of your
DOM. If you absolutely have to use MySQL, you might have
better<BR>luck using a MySQL storage engine that uses fewer writes than
InnoDB, <BR>but I am no expert on that.<BR><BR>--<BR>Kristian
Kielhofner<BR>_______________________________________________<BR>--Bandwidth
and Colocation provided by <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://easynews.com/" target=_blank>Easynews.com</A>
--<BR><BR>asterisk-users mailing list <BR>To UNSUBSCRIBE or update
options visit:<BR> <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://lists.digium.com/mailman/listinfo/asterisk-users"
target=_blank>
http://lists.digium.com/mailman/listinfo/asterisk-users</A><BR></BLOCKQUOTE></DIV><BR><BR
clear=all><BR>--
<BR>------------------------------------------------------------<BR>Erick
Perez<BR>Panama Sistemas<BR>Integradores de Telefonia IP y Soluciones Para
Centros de Datos <BR>Panama, Republica de Panama<BR>Cel Panama. +(507)
6694-4780 <BR>------------------------------------------------------------
</BLOCKQUOTE></SPAN></DIV></DIV><BR>_______________________________________________<BR>--Bandwidth
and Colocation provided by <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://easynews.com/" target=_blank>Easynews.com</A>
--<BR><BR>asterisk-users mailing list<BR>To UNSUBSCRIBE or update options
visit:<BR> <A onclick="return top.js.OpenExtLink(window,event,this)"
href="http://lists.digium.com/mailman/listinfo/asterisk-users"
target=_blank>http://lists.digium.com/mailman/listinfo/asterisk-users</A><BR><BR><BR></BLOCKQUOTE></DIV><BR><BR
clear=all><BR>--
<BR>------------------------------------------------------------<BR>Erick
Perez<BR>Panama Sistemas<BR>Integradores de Telefonia IP y Soluciones Para
Centros de Datos <BR>Panama, Republica de Panama<BR>Cel Panama. +(507)
6694-4780<BR>------------------------------------------------------------
</BLOCKQUOTE></BODY></HTML>