bpa;175886 Wrote: > I think a 50msec changeover is a bit irrelevant to a TCP connections as > long as the basic comms link stays up. If there is a glitch which > results in packet corruption/loss, TCP will arrange retransmissions as > long as the TCP connections is maintained. If the retransmission can > occur such that the missing packet arrive in time, then there will be > no gaps in the audio. > > If the changeover resulted in some loss of sync or similar which resets > the TCP connection then there would be a problem regardless of the > amount of buffering. > > So if you are demoing that "physical" comms path can be changed (e.g. > onto a different fibre in a SDH ring) without > interrupting/breaking/resetting the TCP connections, the SB will be > ideal and the amount of buffering won't really matter.
Your right, I obviously did not read the other post close enough, I thought the SS streamed via UDP not TCP. As long as the SB can buffer long enough to send/receive the retransmit request/reply for a lost packet or two, all is good. We are using RSVP-TE FRR on MPLS service router platforms. Most failovers actually occur in and around 20-30 m/s. The impact to Ethernet services, and customer applications running on this infrastructure is rather negligable. TCP session dropping, will not be an issue. If i can crank down the buffer size so the SB cannot tolerate a large amount of packet drops i may have a interesting demo on my hands. (and a good excuse to pick ip a old SB1 ) -- 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
