seanadams;176002 Wrote: > I think you are asking the wrong question here because you are confused > about how TCP and buffering work. Case in point, it took me a moment to > figure out that by m/s you meant milliseconds and not meters per > second! > > Anyway, a 50ms delay is absolutely mice nuts. On wireless we routinely > deal with that sort of variance in the normal flow of packets, not to > mention a few percent of packet loss. Even if you could adjust the > buffer size, I am not sure what that would help you to illustrate. > > 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 I am sorry if i did not explain myself correctly, below is my simplistic view. Please correct me if I am wrong. TCP is partially responsible to ensure the data it receives from the SS is accurate and in the proper order and pass's it up to the next layer. Lets say it drops the data into the "music bucket" If an errored packet arrives at the SB it is discarded an another copy of a particular packet is requested from the SS . The upper layers of the SB's software have the task (among other things of course)to stream out music leaking from the bottom of the bucket . Because the music has to be delivered in a uninterupted fashion a certain amount of buffer space, or bucket content storing capability is built in to the SB to allow TCP time to do it's thing during poor network conditions. If the bucket size is to small or does not exist , and the network was constantly congested or in a poor state (dropping packets) it would not matter if TCP or UDP was used, the user would experience interuption in the music. The goal is to never let the bucket go empty. TCP will ensure what goes into the bucket is accurate, however the rate it fills the bucket is dependant on the network, the SS and other things. I would imagine you guy's played around with the buffer size, and examined the characteristics of the various network medium etc. at some point in time? What I was hoping to do, (it appears I can't, but thats ok) is decrease the SB buffer size, to a point that it cannot tolerate any packet drops. Yes TCP will make sure what goes into the bucket is still accurate. Our network equipment uses very quick failure recovery mechanisms, and has very deep queue's and sophisticated schedulers. By dialing back the SB's buffering capabilities, I am putting the emphasis on our network equipment to deliver the content with little or no packet drops, and very little latency. My plan was to congest the network with best effort traffic, prioritise the music traffic and introduce failures into the network, knowing that SS/SB current setup was tweaked in such a way that it cannot tolerate interuption in packet flow. I can do this all day long with a traffic generator, but seeing real life applications such as music and video is sexy and sexy sells. In a perfect world i would demonstrate the SB/SS working as intended in stock fashion, then i could dial back the buffer size to a point of lets say 75-100 milli-seconds, congest and introduce network failures and let the customer observe the results. Thanks for your time -- sfraser ------------------------------------------------------------------------ sfraser's Profile: http://forums.slimdevices.com/member.php?userid=2026 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
