PDA

View Full Version : FW: Tuning Squeezebox buffering parameters



Dan Goodinson
2004-11-15, 07:19
Ah - I see. So in your case, there is a momentary pause in the music
but no reboot of SB? That would seem to be a different issue to that
which I experience...

As for the 2.5 seconds, perhaps this could be down to network traffic?
Are there any other streaming apps on your network, or any
bandwidth-hungry apps (e.g. P2P etc)? Do you have a means of monitoring
bandwidth utilisation at the NIC in kamakura? For my network, I set all
NICs to use a short preamble (apparently this is better for networks
with high volume of traffic). It doesn't help answer the question about
buffering, but perhaps this may help get to the root cause of the
issue...

As for my issue, it was hell this morning :( Dropouts (measured by IP
requests from SB to DHCP server) at 10:01, 10:19, 10:20, 10:24, 10:41,
10:49, 10:51, 10:54, 10:55, 10:56. !! My router is supposed to be
"dynamic channel" to minimise interference... Either it doesn't work
and was picking up the world and his dog (and his microwave) on CH1 or
it was working too well and was dynamically switching every few mins
which causes a SB reboot. I turned off this feature and switched back
to CH11. No problems since... Although it's only been a couple of
hours, so too early to tell if problem is fully resolved...

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Nicholas
Gianniotis
Sent: 15 November 2004 13:30
To: Slim Devices Discussion
Subject: FW: [slim] Tuning Squeezebox buffering parameters


Dan,

> Can you give more detail on the outages? [...]

It's pretty much as I described. My gut feeling is that the SlimServer
gets busy once in a while (related to the size of my library?), and
doesn't service the tcp/ip stream to the SB. This causes the SB to play
out its entire buffer ending with an underrun. It would help to know how
big this buffer is in terms of kbytes or seconds of playback at the
nominated bitrate.

I think the network packet trace I captured tells an interesting story.
Here's the pertinent section around the time of the dropout, filtered so
we can see the actual transmission of data from the server to the
client:

17300 0.01009 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110900045 Len=1460 Win=64240
17301 0.00845 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110901505 Len=1460 Win=64240
17302 0.02043 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110902965 Len=1460 Win=64240
17303 0.00001 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110904425 Len=1460 Win=64240
17304 0.00000 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110905885 Len=1460 Win=64240
17305 0.01049 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110907345 Len=1460 Win=64240
17306 2.50622 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110908805 Len=1460 Win=64240
17307 0.00094 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110910285 Len=1460 Win=64240
17308 0.00000 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110911745 Len=1460 Win=64240
17309 0.01297 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110913205 Len=1460 Win=64240
17310 0.00001 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110914665 Len=1460 Win=64240
17311 0.00483 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110916125 Len=1460 Win=64240
17312 0.00001 kamakura -> slim1 length: 1514 TCP D=26395
S=9000 Ack=2840251971 Seq=110917585 Len=1460 Win=64240

Col 1 = packet #, col 2 = interpacket (delta) time, "kamakura" =
SlimServer and "slim1" = Squeezebox. This trace clearly shows packet
#17306 was transmitted a whopping 2.5 seconds after the previous packet
in the stream. This is very likely what caused the underrun. Note the
average interpacket delay before and after the gap was 0.00569s - 5.7ms
- an acceptable value.

Now, it's another task altogether to figure out *why* the server went
out to lunch for 2.5s (remember, none of us run proper real-time
operating systems - so there are no guarantees whatsoever when it comes
to process or thread scheduling)... but whatever the answer is, the hope
is that we can configure the Squeezebox to buffer more than 2.5s music
to ride out these interruptions when they occur.

Regards,
Nico

Nicholas Gianniotis
2004-11-15, 13:02
> So in your case, there is a momentary pause in the music
> but no reboot of SB?

That's right.

> As for the 2.5 seconds, perhaps this could be down to network
> traffic?

The LAN has hardly any other traffic. And keep in mind that the packet
capture was taken on the server machine (kamakura), so it is recording
when packets are written to the NIC, not neccessarily when they
appeared on the wire. If there was network congestion the outgoing
packets would just get queued in the NIC for transmission - but the
interpacket delay would not be affected until the entire tcp/ip xmit
buffer had filled and blocked the SlimServer (assuming it does
blocking i/o). Also, with a switching hub, 2 endpoints enjoy what is
effectively a "private" full-bandwidth channel, immune from other
point-to-point traffic (until the total switch throughput is
exceeded). I'm not close to those levels.

> Are there any other streaming apps on your network, or any
> bandwidth-hungry apps (e.g. P2P etc)?

Nope.

> Do you have a means of monitoring bandwidth utilisation at the
> NIC in kamakura?

The snoop I ran was on kamakura's NIC. I captured all packets but only
displayed those of interest in my posting. There is not a lot of other
activity...

> It doesn't help answer the question about buffering, but perhaps
> this may help get to the root cause of the issue...

From another post on this thread it appears my hunch was correct, and
the hourly spike in CPU activity & starvation of the stream is due to
a function on the SlimServer which dumps the tag cache to disk. I'm
going to try setting it to a very high value and see if the problem
goes away.

Nick