PDA

View Full Version : Diagnosing dropouts



Michael Haan
2004-12-23, 08:40
I've been trying to track down this ghost in the machine as well.  Last night, I had squeeze running while I monitored the buffer and ran KDE monitor on the linux box running slimserver.  For the most part, everything was fine, but twice (when the drop-out occurred) I saw the buffer go to zero.  The CPU showed no appreciable increase in load (in fact, it decreasedduring the dropout), there was zero swap, no increase in physical memory and no increase in average load.  In the first case, a few seconds later the buffer refilled and the cpu rose to it's pre-dropout level.  In the second case, the buffer dropped to zero and stayed there, the cpu dropped, and all other indications were the same as the first.  Eventually, the squeeze reported it couldn't find slimserver even though I verified it was running.  Powering-off and on the squeeze caused it to be able to find slimserver.  In this instance, I was streaming FLAC over powerline to a squeezeG from slimserver 5.4.  Any thoughts anyone?

Jack Coates
2004-12-23, 08:47
Michael Haan wrote:
> I've been trying to track down this ghost in the machine as well. Last
> night, I had squeeze running while I monitored the buffer and ran KDE
> monitor on the linux box running slimserver. For the most part,
> everything was fine, but twice (when the drop-out occurred) I saw the
> buffer go to zero. The CPU showed no appreciable increase in load (in
> fact, it decreasedduring the dropout), there was zero swap, no increase
> in physical memory and no increase in average load. In the first case,
> a few seconds later the buffer refilled and the cpu rose to it's
> pre-dropout level. In the second case, the buffer dropped to zero and
> stayed there, the cpu dropped, and all other indications were the same
> as the first. Eventually, the squeeze reported it couldn't find
> slimserver even though I verified it was running. Powering-off and on
> the squeeze caused it to be able to find slimserver. In this instance,
> I was streaming FLAC over powerline to a squeezeG from slimserver 5.4.
> Any thoughts anyone?
>

did the network traffic actually stop during the drop out? iptraf is a
good tool for watching this, or tcpdump -n -i eth0 tcp port 3843

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

Michael Amster
2004-12-23, 12:29
Michael:

Sounds like we have the exact same types of issues. What type of
wireless network do you have? I have the Linksys WAP54G as my AP
running in mixed mode with 128 WEP encryption.

I am leaning more toward the network being the issue, but it would be
great to understand the Slimserver buffering strategy -

How big is that buffer in the Squeezebox and how does the Slimserver.pl
fill it? A bigger buffer would help with what seems to be relatively
short lived drops.

-MA

Michael Haan wrote:

> I've been trying to track down this ghost in the machine as well.
> Last night, I had squeeze running while I monitored the buffer and ran
> KDE monitor on the linux box running slimserver. For the most part,
> everything was fine, but twice (when the drop-out occurred) I saw the
> buffer go to zero. The CPU showed no appreciable increase in load (in
> fact, it decreasedduring the dropout), there was zero swap, no
> increase in physical memory and no increase in average load. In the
> first case, a few seconds later the buffer refilled and the cpu rose
> to it's pre-dropout level. In the second case, the buffer dropped to
> zero and stayed there, the cpu dropped, and all other indications were
> the same as the first. Eventually, the squeeze reported it couldn't
> find slimserver even though I verified it was running. Powering-off
> and on the squeeze caused it to be able to find slimserver. In this
> instance, I was streaming FLAC over powerline to a squeezeG from
> slimserver 5.4. Any thoughts anyone?
>
>------------------------------------------------------------------------
>
>