This seems like a very large load for just one server: Network:
Let's first assume that you use the MP3 maximum bitrate of 320 kbit/s. This is equivalent to 40.000 bytes per second. With all 200 clients running, you have 8.000.000 bytes/s throughput, so that the network interface is nearly saturated, if you do not choose to use a gigabit interface, which would by a logical choice, since the backbone switch should be gigabit as well. Regarding your overall investment, this is not that much more expensive. Whatever, network throughput should be no problem. Harddisk: While the throughput of 8 MByte/s does not seem much at first sight with current harddisks running at 30 MByte/s at least (inner tracks), you have to remember, it is 200 clients causing that load, each probably playing a different song. This means that with buffering at - say - 1 second, there would be 200 random seeks per second, each taking ~12ms for a current harddisk including latency and read. This would take 2.4 seconds, so it would not work. You have to make sure that buffering is at least 3 seconds, which equals around 128 KBytes. With a Linux server, you can control this read-ahead, regardless of application buffering. However, with real-life assumptions, maybe it would work out just fine, since you don't have to use maximum bitrate and in a hotel, you'd rarely see more than half of the clients actually working. Processing: This does not mean there is no other K.O. criterium here, I don't know if the processor load caused by slimserver may be to high - after all, it's interpreted PERL... Maybe someone with more than a few clients can give figures about their CPU load factors? -- meyergru ------------------------------------------------------------------------ meyergru's Profile: http://forums.slimdevices.com/member.php?userid=1980 View this thread: http://forums.slimdevices.com/showthread.php?t=18098 _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
