Slashdot Mirror
Creating a Functional Network for a Radio Station?
E-bot & Ro-bert asks: "I volunteer for my campus radio station and, as the only techy there, I've been asked to help design their new network. We're on a very fixed budget and we're working with win98 PCs. The network needs to provide the ability to simultaneously stream and transfer large files (uncompressed WAV data) w/o interruptions to the stream. I know their current idea of using a simple hub and connecting all the computers won't work, but I'm drawing a blank on what to suggest. The specifics: Two of 6 Win98 PCs need to have the ability to broadcast audio data from any source on the network. The other 4 of 6 computers must be able to transfer files on the network w/o taking too much bandwidth away from the streams. I'm thinking of QoS, but how should it be implemented? What does the slashdot community look for, and suggest, in making a high-bandwidth network?"
Perhaps I'm over-simplifying, but uncompressed WAV data (2-channel, 44.1khz, 16-bits-per-channel) is only 1.411 Mbps. For the network itself, a 100 Mbps switched Ethernet should provide plenty of bandwidth and dramatically reduce latency.
The switch will allow you to dedicate 100 Mbps each way per machine by preventing each box from having to see streams in which it is uninterested. It will also allow you to run full-duplex, which will decrease latency if you're ACKing your transmissions (e.g. using TCP).
Really, a 10 Mbps switched network would probably be sufficient, but good luck finding a 10 Mbps switch these days.
I'd be more concerned about the ability of Win98 boxen to stream/process realtime data without hiccups, but I assume you've already got that solved.
I also work at a small radio station and a limited budget, where all of our computer are either Win98 or DOS, plus one Linux server. We've been streaming our audio onto the air from the Linux box using a Samba server no problem, just by using 100MB full-duplex switches.
The three problems that crop up are:
1) Large file downloads across the LAN, but this is only a problem when the files are being pulled to or from a computer that is serving or receiving a stream. This almost never happens where I work, though.
2) Hard drive accesses. This one isn't so obvious. Once or twice I've put a heavy load on the Linux box's drive (e.g. unthrottled data backups, recursive grep) and the drive couldn't keep up with both the backup and the audio file reads simultaneously.
3) Lack of contingency plans. If you're putting things on the air pulled from a computer across the network, you need to make sure your backups are thorough and extremely fast to restore. Our Linux server is backed up once a day (we only change about a dozen or less files per day) to a second hard drive, and we can pop a floppy in the disk drive and reboot to switch to the backup very quickly, all systems operational; then you have plenty of time to fix the problem and switch back to the main storage drive.
I hadn't heard of the bandwidth limiting software that someone else mentioned. It initially sounds like a good idea, but if you install it on the computers that are serving or receiving a stream, it would actually aggravate the problem, so implement that idea carefully.