bmp/xmms hanging w/ samba

[Mike Perry]

Thus spake Axel Thimm (Axel.Thimm at atrpms.net):

> > > Perhaps your network connection is really that bad, that even mp3
> > > streams outperform its bandwidth?
> > 
> > Doubtful. I get around 2MBytes/sec off of the samba share over wireless,
> > and around 4 over wired.. 
> 
> 4 already looks suspicious, you should get 10 or more. Try ttcp.

4 is probably due to my software RAID5+dmcrypt setup running on shitty
hardware. I do not have that much disk bandwidth, unfortunately. It is
more than enough to play mp3 (and avi and even vob) locally on the
machine without any problems, however.

ttcp achieves 3.4Mbytes over wireless, and 10 over wired.

Also, I just tested playing mp3s over some shares at work using the
same laptop, and both Windows hosted shares and samba (on debian)
hosted shares exhibited the same problem. The Debian Samba server took
the longest to reproduce: about 30 minutes of continuous play before
stopping. This is about as long as NFS took to die on my local setup.

Note that my main desktop at work is a Windows XP machine using winamp
to listen to the same shares. Winamp has *never* stalled, and I have
been on this network for over a year, listening to mp3s almost every
day for several hours a day.


> > I just tried NFS, and the problem took much longer to reproduce,
> > but it did eventually crap out over both the wired and the wireless
> > networks.
> > 
> > Think I should also file the bugs with xmms and bmp upstream? Any
> > other suggestions?
> 
> No, I don't think this is an application issue. Try cutting out the
> apps from the diagnosis by reproducing the error by simple file
> copying.

I am pretty convinced this is an application issue, especially since
now I am able to reproduce it at work. 

My feeling is that file copying will not reproduce the error because
it is due to logic in xmms/bmp expecting unbuffered reads to return in
a particular timeframe and in one instance they do not. That, I think,
is the bug, and apparently makes xmms/bmp so hypersenstive to timing
issues/hiccups that it cannot reliably play mp3s over a network share.

I frequently copy files back and forth to the samba share and have
never noticed a short file. I do not believe it is likely I will ever
do so, either, because copying does not have the time-dependence on
reads that xmms does.


> Try running gkrellm or a similar monitor on side to your apps and
> watch the network traffic. You'll find that when the outages happen
> the network traffic will break down. Or if not, it will be from a
> different machine congesting your connection to your samba server. It
> could be a simple as a dying hdd timing out your read request, so
> check the logs on the server, too.

I do in fact run gkrellm on both machines. There is never a flat
network outage, either when copying or when playing. The setup is a
private one, so it is not due to other traffic on the server. There
are no hdd errors in the logs, nor any errors in the samba or NFS
logs.

When copying files, I do see some single-pixel low points in network
activity in gkrellm, but never a drop to zero. At worst a drop to 1/2
rate. 

The last possibility not ruled out is using a different client box. As
Warren Togami pointed out on the extras list, it could be my machine
is falling victim to
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164742
though I do not believe this to be the case...

Is anyone playing mp3s over a samba share successfully for long
periods of time? I would have thought this would be a common use
case.. Maybe people just tend not to use Linux as the client machine..
Or maybe it is my audio drivers after all? Or some other scheduling
issue?

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs