Configuring Servers for Streaming, Part Two

Thanks for the Memory

Contrary to popular wisdom, adding more memory to a server does not necessarily enhance performance. Look at the performance attributes of the entire server prior to assuming that more memory will speed things up. Also, RAM should be in proportion to the speed of the processor. The faster the processor, the more data it can process. It’s important to have as much data in memory as the processor can handle.

Tip: Real recommends 256 MB of RAM to run its RealSystem Server. Adding more RAM will increase the number of clients the machine can serve simultaneously. The table below, courtesy of Real, demonstrates how much RAM is needed for various operating environments under measured operations. Your mileage will vary. But it’s a good place to start.

Estimated Streams Served@225Kbs/stream	Estimated Bandwidth Served	Linux	Windows NT 4.0	Solaris 2.7
Up to 130	10 MB	Pentium II 350MHz 512MB RAM	Pentium III 500 MHz 512 MB RAM	Ultra 10 512 MB RAM
Up to 265	30 MB	Pentium III 750 MHz 768 MB RAM	Pentium III 750 MHz 768 MB RAM	Ultra 30 768 MB RAM
Up to 445	60 MB	Dual Pentium III 750 MHz 1024 MB RAM	Dual Pentium III 750 MHz 1024 MB RAM	Ultra 60 1024 MB RAM
445	100 MB	Dual Pentium III 750 MHz 1024 MB RAM	Quad Pentium III 750 MHz 2048 MB RAM	E250 2048 MB RAM

The above has been provided courtesy of Real. RealSystem Server also runs on Windows 2000, HPUX, IBM AIX, Compaq's Tru64, Solaris 2.8 and Free BSD.

Tip: Configure memory for peak load, not average load. For this reason, and because memory is relatively cheap, it’s a good idea to double the above values, if possible.

Tip: Do not allow the server to "swap" to the hard drive when it’s short on system memory. Ensure that there is enough memory so swapping NEVER occurs. Disk drive performance is not even in the same ballpark as memory speed. Swapping (or paging) program instructions and data on and off the hard drive will kill the performance of any system, especially streaming media servers.

Tip: Check other variables for even more memory. The media server’s ability to maximize available memory may mandate more memory for additional performance. For example, on the Solaris system, RealSystem Server is designed to pre-allocate a large amount of memory and then use memory from that block. This helps ensure smooth streaming and minimize latency from buffering and data fetching.

In fact, many Unix systems are designed to pre-allocate (buffer) large amounts of memory explicitly for media data. Memory buffers can be established for each active video stream, which helps the efficiency of streaming data over the network as the next "cluster" of media data is fetched from the disk. This helps ensure smooth streaming and minimizes latency resulting from disk I/O. This is a good example of how more memory supports more concurrent streams. The ability to buffer multiple concurrent media streams is a function of the media server and its operating system’s ability to maximize available memory.

On the other extreme, Microsoft Media Services does not use system memory to cache file system data. Given the complexity of interaction between server components and the design of Microsoft Media Services, adding more memory may or may not affect the number of concurrent streams the server can run.

Coming and Going, the I/0
Server I/O subsystems are critical to streaming performance yet are the most difficult to configure. The goal is to maintain a sustainable bit rate through the server for multiple concurrent streams. I/O subsystems include the I/O bus, disk bus architecture, host bus adapters (HBAs), and RAID arrays.

I/O Bus
There used to be a battle between vendors to introduce new I/O bus architectures, features, and speeds. Thankfully, that war is over and PCI is the winner (but keep your eye on InfiniBand in the near future). Virtually every hardware vendor uses PCI as the standard I/O bus. The advice on this is simple: Get the fastest PCI bus your money can afford.

Disk Bus Architectures
For disk bus architecture, you’ll have two choices: SCSI or IDE/ATA. For sheer transfer speeds, you can’t beat SCSI. For this reason, SCSI is typically preferred for streaming applications.

Here’s a list of considerations for each.

IDE and ATA(IDE/EIDE, Fast-ATA and ATA-2 Ultra-ATA, each is a souped up version of the previous)

Less expensive disk than SCSI

Way slower than SCSI drives

Less expensive host bus adapters

EIDE disk can be configured to emulate SCSI disks within multiple disk arrays, which provides a superior price/performance ratio

Polled I/O means processor does all the I/O work

Limited devices (4-EIDE)

Only one IDE drive can transfer between memory and disk at once

Slower IDE bus transfer rates: up to 13.3MB/second

SCSI

More expensive disk than IDE/ATA

Way faster than IDE/ATA drives

Host bus adapter prices vary considerably, but still much higher than IDE ($15 IDE vs. $200 SCSI)

Typically DMA based (frees up CPU)

Handles way more devices (15 Wide SCSI)

SCSI drives operate independently and can all communicate simultaneously on the SCSI bus

SCSI drives are not quite fast enough to flood more than half the SCSI bus bandwidth, so you can have at least two drives on a single bus pumping full speed.

SCSI buses offer the fastest transfer rates: up to 200MB/second; 32 and 64-bit bus (SCSI 3 Ultra 2) - soon to be 512MB/second

Tip: You can get near SCSI bus performance (133MB/second and higher) for less cost by going with arrays from companies who have figured out how to create RAID arrays out of IDE drives to make the computer think they are SCSI disk arrays. The IDE/ATA RAID array appears as one large SCSI disk drive to the computer. Look to companies like Medea and Promise, which specialize in products that spoof the computer into thinking IDE disk drives are SCSI drives (with some limitations) to achieve significantly higher performance.

Next Page: Server Storage Pointers >>