Has anyone seen these solid state "Drives" from gigabyte yet? -
http://www.pcper.com/article.php?aid=224&type=expert&pid=3
For those who havnt, they are basically a pci card with 4 DDR memory
slots on board, coupled to a SATA interface and with a battery on board
to ensure that you can use standard volotile memory as "non-volotile"
memory.
Whilst not offering the speeds of SATA II, they do say that the device
is quite capable of fully saturating a SATA I interface with 150 MB/s,
and your seek and write times are much much quicker than SCSI, SATA etc,
and i am thinking that you would have much fewer problems with
fragmentation due to increased seek times (would eventually be a prob thou)
There is the limit of 4 gig at the moment, but in a scenario like this
one, you could use the solid state drive for initial writes and then
move the data to a secondary raid array or similar.
Would be interested to see if anyone has used such a device yet and what
the feedback is.
Cheers,
Ben
Matt Roth wrote:
On 4/3/06, Isaac Xiao <[EMAIL PROTECTED]> wrote:
Hi All,
In previous mail lists, people talked about a solution to record large
amount of simultaneous calls. And then it seems that RAM disk
solution was
the best choice due to the I/O bottleneck of Hard disk (System).
Please find
the previous discussion as follows:
http://lists.digium.com/pipermail/asterisk-users/2005-October/120930.html
http://thread.gmane.org/gmane.comp.telephony.pbx.asterisk.user/118497
I noticed that an Intel server platform comes with 4 ports SATA-II
RAID0/1
controller. Please check this link:
http://developer.intel.com/design/servers/boards/se7230nh1-e/index.htm
SATA-II is 3Gps I/O. so I am thinking implement this solution for
recording
large amount of simultaneous calls. My proposed solution is:
CPU: Prentium 4 Dual core 3.2G or higher
RAM: 2G or more
OS HDD: 2 x 80G SATA-II HDD for RAID 1 (for OS)
Separate HDD for voice recording: 1 x 200G SATA-II HDD standalone
Voice recording format: WAV
I did a test on my Asterisk PBX. One leg of 61 seconds WAV voice
recording
use 947564 bytes of hard disk. I did an optimal estimate of numbers of
simultaneous calls with 3Gps without thinking of CPU and system
limitation.
Two legs: 947564 x 2 x 8 = 1895128 Bytes x 8 = 15161024 bits
15161024/61 = 248541 bits/s
So the number of simultaneous calls 3Gps I/O can handle:
3(Gps) x 1024(Mb/G) x 1024 (Kb/M) x 1024 (b/Kb) / 248541 = 12960 calls.
512 are far less than 12960. So I think the hard disk I/O should not
have
any bottleneck problem for 512 simultaneous calls.
Welcome to add your comments, do test and give feedback.
Cheers,
Isaac Xiao
Matt Florell wrote:
Hello,
What happens a few weeks into this when you've fragmented the free
space on the drives by deleting files periodically and rewriting in
some places? The consistent performance of SATA drives goes down
dramatically when this happens, much more so than on a SCSI-based
drive system.
Also, you don't seem to take into account the read-write-seek time of
SATA drives into your calculations
Another thing to consider is that if anything else is being done on
these drives(like running Linux or Asterisk or anything else) the
write performance will also be effected.
MATT---
Isaac,
I'm the author of the original posts and I'd like to share some
additional information with you. Our system is a Dell PowerEdge 6850
and you can see the drive specs here:
<http://www1.us.dell.com/content/products/productdetails.aspx/pedge_6850?c=us&cs=04&l=en&s=bsd&~page=1#tabtop>.
The drives that we purchased are 15,000 RPM Ultra320 SCSI drives. We
have two 73 GB drives configured in a RAID 1 (mirrored). The server has
a PERC hardware RAID controller and we are using the megaraid drivers.
All of the filesystems are ext3 (except the RAM disk which is ext2).
It was an oversight at the time of the original tests to have the
partition that the recordings were written to be a journaled
filesystem. There is some overhead there, but I'm not clear on exactly
how much. The RAID 1 also has some write overhead. We had limited time
to use the test equipment, so we went right to the RAM disk without
changing either of these settings but they are a couple of optimizations
to keep in mind if you aren't seeing satisfactory performance.
The 512 calls was also the only load on the system during testing. We
are actually using the box in production now and with the additional
load of agents, announcements, MOH, unattended monitoring, NFS transfers
of the leg files to a remote box for mixing, etc. it looks like a more
realistic number is somewhere between 250-300 simultaneous calls. For
instance, at this moment we have 45 calls in queue and 116 active calls
(resulting in roughly 250 leg files being generated) and the box is
about 65% idle. I'm assuming that the scaling will be somewhere between
linear and exponential, which is where I'm deriving my projected numbers
from.
The point of all this is that you need to be careful when comparing the
ideal situation to the realistic one. As Matt Florell (who is *very*
knowledgeable) pointed out, many factors and variables come into play.
I've been told by some people that the way the Linux kernel buffers disk
writes should approach the performance of the RAM disk (the ideal), but
what I actually experienced was the complete breakdown of Asterisk at
around 60 concurrent recordings without it (the reality). That seems to
be the magic number for other users as well, so I don't believe that the
ext3 filesystem or the RAID 1 are solely to blame. From the numbers we
captured, I think that the system could not keep up with the overall
number of disk writes. They occur in the same thread as the processing
of the voice frames, so this leads to a severe decrease in call quality,
including dropped calls. I think MixMonitor addresses this problem, but
it has its own set of issues.
The RAM disk solution also seems a bit daunting because of the amount of
memory we dedicated to it. For some perspective, right now we're only
using 5% of the RAM disk, so it looks like we may be overconfigured.
The extra space is nice in case the NFS moves fail, but we are thinking
about moving some other files to it (MOH, announcements, logs, etc.) as
well. I have no personal experience with SATA drives, so your mileage
may vary. I just wanted to make you're aware that sometimes things
aren't the same on paper as they are in the server room and that the RAM
disk solution is being used in a production environment at this time.
When moving ahead, it's a good idea to have plans to fall back on when
things don't go as expected.
I wish you luck with your project and hope that you share the results of
your implementation with the community.
Sincerely,
Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer
_______________________________________________
--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
_______________________________________________
--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
