seanadams;176002 Wrote: > Is there an alternative failure mode (for example a competing product > which does not recover as quickly), where you would like to show that > streaming does not perform as well? If you could describe what that > failure looks like, maybe we could suggest a test to illustrate it. > > If you want to show the difference between, say, a 50ms outage and a > 250ms outage, then VOIP is probably the best thing to demonstrate. VOIP > potocols, by design, sacrifice reliability in order to achieve real-time > streaming with low latency. Squeezebox is the opposite - it plays from > stored data which can be read into its memory as fast as the network > will deliver it, even in a bursty manner, so the stream can continue > even with heavy packet loss or a complete outage of several seconds. > You couldn't make Squeezebox behave like VOIP just by reducing the > buffer size, because TCP is *totally* different!
Sean, Just as there are divisions in the audiophile community, so too are the divisions in the networking world. In one corner, the group that believes that bandwidth should be reserved end to end (RSVP) and that failover has to happen in 50ms (or less) (MPLS FRR). In another corner, is the group that believes in adaptive buffering, using algorithms and lots of memory, since it is cheap, and transfering the requirements out of the network to the application layer. OP is asking to test the camp #1 concepts by taking perfectly good applications from camp #2 and detuning them to show the benefit of approach #1. Even VOIP as practiced by most green fields carriers these days (e.g. cable companies) do not require the methodologies of camp #1. People discovered that with some IETF protocols that sense one way latency and report it (RTP & RTCP) you can do an excellent job of adaptive buffering. Most devices today that connect phone and IP network do significant adaptive buffering. They often keep somewhere between 100-200ms of buffer available, so that the application can ride out most nastiness in the carrier network. By using simple IP & OSPF, and fast convergence techniques you can get failover down to low O(100ms), which beats FCC reporting requirements AND beats cellular, and arguably matches PSTN in listening tests (i.e. what customers actualy report). Its much simpler and cheaper than RSVP/TE/FRR and works quite well. And all you needed was buffering in the device that adapts a telephone from a bit synchronous analog device to a smarter packet device. Even broadcast video distribution systems, the last holdout of large scale synchronous end to end clocking, are starting to see the benefits of switching over to a buffered approach. My suggestion is that if you actually want to test MPLS FRR and really see the impact, you need a legacy application that is bit synchronous end to end, no buffering and no adaptive protocols or algorithms anywhere. How about a CD transport S/PIDF over Ethernet emulation? (Sorry, humorous attempt to bring discussion back on topic) Before anyone reacts, I am not making negative comments on the OP's equipment or technology strategy. There are valid business reasons to go with that approach. But the SB3 isn't going to show it. This discussion has been going on a long long time in the Internet community. See Craig Partridge's RFC1257. http://www.faqs.org/rfcs/rfc1257.html -- Eric Carroll Transporter-Bryston 3B SST-Paradigm Reference Studio 60 v.4 SB3-Rotel RB890-B&W Matrix 805 SB3-Pioneer VSX-49TXi-Mirage OM7+C2+R2 ------------------------------------------------------------------------ Eric Carroll's Profile: http://forums.slimdevices.com/member.php?userid=9293 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 _______________________________________________ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
