Streaming server gives priority to video
- By John Breeden II
- May 22, 2002
Most servers are jacks of all trades. Vividon Corp.'s Streaming Delivery Accelerator is the master of only one. Because it specializes in streaming video, it performs that task better than general-purpose servers.
Built from a Dell PowerEdge 2550 rackmounted server with a 1-GHz Pentium 4 processor, 2G of RAM and standard Dell warranty, the SDA has a small, acustomized operating system called XOK. All drivers are customized to deliver video content at the expense of just about anything else.
The GCN Lab tested the SDA 1000, designed for enterprises with Fast Ethernet networks. It had two 100-Mbps ports; the higher-end SDA 2000 incorporates a Gigabit Ethernet port.
For test purposes, we set up a PC as a swamping server that simulated numerous users trying to access streaming media stored on the SDA.
In the first test, 95 simulated users tried to access 95 different 15M video clips. The SDA served all 95 with their requested videos, creating a 96-Mbps stream close to Fast Ethernet's maximum bandwidth. At peak, the SDA used only 25 percent of its capacity, and none of the video streams showed any lag or server errors.
The next test purposely overloaded the bandwidth pipe entering the server to see how the SDA would react. The test simulated 1,000 users trying to access 1,000 different media clips. All clips were Windows Media files; the SDA also supports the RealPlayer and QuickTime formats.
At the point of near-overload, the SDA behaved better to already-connected users than to newcomers. Once the simulated users connected and started to play their video clips, the machine kept on feeding them.
When the 100-Mbps limit was reached, the SDA denied access to newcomers, thus preventing lag on its existing streams. As the earlier users' clips finished playing, the SDA connected newcomers so long as its bandwidth limit was not exceeded.Turned away at the gate
On a Gigabit Ethernet connection with an overload on the SDA, a similar thing happened. The SDA refused to serve up choppy video.
The bottom line seems to be that, once you're in, the SDA takes good care of you. Unfortunately, our virtual users whose connections were refused got no details about why.
The SDA administrator could impose usage limits via bandwidth constraints or number of users, or both.
In addition, there were filtering tools to stop denial-of-service attacks and other malicious uses. The SDA could be programmed to e-mail the administrator about events such as reaching a bandwidth limit.
There were two power supplies, one redundant. The only problem here was that the sysadmin got no alert about a power supply failure. The SDA simply switched to the second unit.
Our test unit had three drives, storing from 54G to 210G. That would be enough for several hundred hours' worth of high-quality video content.
The optimum enterprise setup would be to put one SDA behind the firewall at each remote agency site and one in a central office. Then training videos, official remarks and the like could be pushed from the main SDA to all the field units. Remote users could connect to their local SDAs and view high-quality video.
An SDA could also become a video server component in an existing network, caching often-viewed streams to save bandwidth and speed access.
A secondary use for a network of SDA systems could be pushing nonmultimedia data files to other locations. Such a push-content system, like any other network server, would work for any data type.
We found the SDA impressive at video service. Its streamlined OS stayed out of the way and gave far smoother access to media files than a standard server OS.