asterisk users - Apr 2005 - TDM400P and SCSI/SATA = * noise problems???

We're running asterisk on a pair of 1GB 12mb/s flash cards running on
separate IDE channels. 

We've setup software RAID1 to protect ourselves from failures if any of
the flash cards die.

VoiceMail is stored on a small IDE that is dedicated just for this.

It appears to work quite well. Although we don't have TDM's on our
system.


 
> -----Original Message-----
> From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-
> bounces@lists.digium.com] On Behalf Of Damian Funnell
> Sent: Wednesday, 20 April 2005 05:30
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [Asterisk-Users] TDM400P and SCSI/SATA = * noise
problems???
> 
> Hi Tim,
> 
> Thanks for your post, it's most insightful.  It certainly puts a
pretty
> large dent in my confidence in the TDM for commercial use - imagine if
> there was more than one TDM in a system (especially with a RAID
adapter).
> 
> Running a PABX without hardware RAID 0 is not an option for us, as we
> don't want disk failure to result in the PABX dying, so I guess we are
> going to have to research ways of retarding it somehow.
> 
> Cheers,
> D.
> 
> FFF Managed Technology Ltd
> 60 Cook St
> P.O. 6368 Wellesley St
> Auckland
> t +64 9 356 2911
> f +64 9 358 9070
> m +64 21 415 297
> w www.fff.co.nz
> 
> 
> 
> tmassey@obscorp.com wrote:
> 
> >Yes.  It has to do with latency and bus contention.
> >
> >I've run a TDM board in an IBM Netfinity 5600 server with an IBM
> ServeRAID
> >3L controller (SCSI-U2W).  The big difference, though, is that the
RAID
> >controller was on its own PCI bus, and the TDM card was on its own
PCI
> >bus.
> >
> >With both controllers on the bus, you can have latency issues.  For
> >example, if the RAID controller sets up a DMA of a big chunk of disk,
it
> >owns the bus for that transfer.  If an Ethernet packet is delayed by
50us
> >during that time, nobody cares.  But if the TDM card is delayed, it
most
> >certainly cares:  especially as its generating 1000 interrupts a
second!
> >
> >That's the problem with the TDM cards.  They do *nothing* on the
CPU
> side.
> > The CPU has to do *everything*, and it has to do it *immediately*.
When
> >you are using plain-jane IDE, you can tweak the kernel to put the IDE
> >stuff at a low priority.  But when you've got a fancy RAID
controller, it
> >tends to think it's the most important thing in the system.  And as
a
> >rule, hard drive I/O usually *is* the most important I/O going on in
a
> >system.  However, in this case, the TDM card trumps that.  And Digium
> >doesn't know how to tweak every last RAID driver in existence for
> >low-priority operation--or even if it's possible.  Hence, the
> >recommendation for IDE.
> >Yet they require PCI 2.2, which eliminates most Pentium III's and
lower!
> >:)
> >
> >I'm still in the midst of testing the TDM cards.  So far, so good,
in
an
> >EPIA-based solution and in the 5600.  But I've been through at
least
half
> >a dozen different systems before I've found these...
> >
> >Tim Massey
> >
> >_______________________________________________
> >Asterisk-Users mailing list
> >Asterisk-Users@lists.digium.com
> >http://lists.digium.com/mailman/listinfo/asterisk-users
> >To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-users
> >
> >
> >
> >
> >
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users

This message (and any associated files) is intended only for the use of the
individual or entity to which it is addressed and may contain information that
is confidential, subject to copyright or constitutes a trade secret. If you are
not the intended recipient you are hereby notified that any dissemination,
copying or distribution of this message, or files associated with this message,
is strictly prohibited. If you have received this message in error, please
notify us immediately by replying to the message and deleting it from your
computer. Messages sent to and from us may be monitored...

Internet communications cannot be guaranteed to be secured or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses. Therefore, we do not accept responsibility for
any errors or omissions that are present in this message, or any attachment,
that have arisen as a result of e-mail transmission. If verification is
required, please request a hard-copy version. Any views or opinions presented
are solely those of the author and do not necessarily represent those of the
company.