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