From: Filip M. <f.m...@tu...> - 2006-11-27 01:59:32
Attachments:
sshfs-bug.txt
|
Greetings all: Here goes an issue description for sshfs. I use sshfs to mount a remote directory through a 10mbps wireless link. The remote directory is mainly used for media files like mp3 music and videos. When I start xmms to play mp3 or ogg files, very often the playback suddenly stops in the middle of the song. Sometimes, after a song is finished, xmms just stops and does not play the next one. As far as I can see, no error is reported, as if xmms somehow thinks an EOF has been reached. Similarly, when I use the network connection for an unrelated task at the same time as the playback, the interruption gets much more frequent. As far as I can remember, this problem did not happen with earlier versions of sshfs, which I used while Fedora Core 4 was current. Unfortunately, I do not remember anymore which sshfs version I used then. In the attachment you will find the log excerpt in which the following error scenario. xmms tries to play the file track-15.ogg, but does not do so. It just stops. I hope you can discern something more from the log file. I run FC6, with fuse-sshfs-1.7-2.fc6. f |
From: Miklos S. <mi...@sz...> - 2006-11-28 12:34:32
|
> Here goes an issue description for sshfs. I use sshfs to mount a remote > directory through a 10mbps wireless link. The remote directory is mainly > used for media files like mp3 music and videos. > > When I start xmms to play mp3 or ogg files, very often the playback > suddenly stops in the middle of the song. Sometimes, after a song is > finished, xmms just stops and does not play the next one. As far as I > can see, no error is reported, as if xmms somehow thinks an EOF has been > reached. > > Similarly, when I use the network connection for an unrelated task at > the same time as the playback, the interruption gets much more frequent. > As far as I can remember, this problem did not happen with earlier > versions of sshfs, which I used while Fedora Core 4 was current. > Unfortunately, I do not remember anymore which sshfs version I used then. It's unlikely to be a regression in sshfs itself, but who knows. > In the attachment you will find the log excerpt in which the following > error scenario. xmms tries to play the file track-15.ogg, but does not > do so. It just stops. I hope you can discern something more from the log > file. There's nothing abnormal in that. Is this reproducible? Does it always happen with the same file? Thanks, Miklos |
From: Filip M. <f.m...@tu...> - 2006-11-28 12:55:06
|
Miklos Szeredi wrote: > It's unlikely to be a regression in sshfs itself, but who knows. > I hoped that someone on the sshfs mailing list would spot it immediately if it were something of the sort. > There's nothing abnormal in that. Is this reproducible? Does it > always happen with the same file? > It is not reproducible in the sense that the same file gets stopped at the same place. Xmms will play the file in one case, and stop playing in another. Rather, there are usage patterns that invoke the behaviour. For instance, xmms sometimes stops playing when I click a link in Firefox. A similar thing happens when I do something that (at least I suppose so) invokes transient hardware usage (e.g. intermittent 100% CPU load or disk writes or some such). An almost certain way to invoke the behaviour is to start xmms with a song on the sshfs mounted volume and to try copying something else to that volume. It then becomes almost impossible to listen to music, as xmms is only able to play for a few seconds, before it stops. |
From: Miklos S. <mi...@sz...> - 2006-11-28 14:24:51
|
> > There's nothing abnormal in that. Is this reproducible? Does it > > always happen with the same file? > > > It is not reproducible in the sense that the same file gets stopped at > the same place. Xmms will play the file in one case, and stop playing in > another. > > Rather, there are usage patterns that invoke the behaviour. > > For instance, xmms sometimes stops playing when I click a link in > Firefox. A similar thing happens when I do something that (at least I > suppose so) invokes transient hardware usage (e.g. intermittent 100% CPU > load or disk writes or some such). It could be some harware or driver issue (e.g. interrupt conflict) with the sound card. Have you tried the same with local mp3 files? That would rule out sshfs/fuse. Thanks, Miklos |
From: Filip M. <f.m...@tu...> - 2006-11-29 11:09:34
|
Miklos Szeredi wrote: > It could be some harware or driver issue (e.g. interrupt conflict) > with the sound card. Have you tried the same with local mp3 files? > That would rule out sshfs/fuse. > Yes, I have tried with local MP3 files and have no such issue whatsoever. Note again, this only happens for an sshfs-mounted volume. I am using the same machine for over 3 years now and have not had similar problems, bar those that seem to correlate with the usage of sshfs. HTH, f |
From: Miklos S. <mi...@sz...> - 2006-11-29 11:43:14
|
> > It could be some harware or driver issue (e.g. interrupt conflict) > > with the sound card. Have you tried the same with local mp3 files? > > That would rule out sshfs/fuse. > > > Yes, I have tried with local MP3 files and have no such issue whatsoever. Hmm. > Note again, this only happens for an sshfs-mounted volume. I am using > the same machine for over 3 years now and have not had similar problems, > bar those that seem to correlate with the usage of sshfs. OK, but upgrading the OS could bring in a problem which might show up with strangly unrelated symptoms. In the trace you sent, every operation looks like it has finished normally. Nothing is pending in sshfs that would cause xmms to hang. The other thing you could try is stracing xmms. The problem with that is xmms is multithreaded, and it might not be trivial to see where it's hanging. But it might be worth a try: strace -ff -o xmms.strace xmms or strace -f -o xmms.strace xmms The first will write the trace for each thread in a separate file, the second will write a single file. I'm not sure which will be more useful in this case. Thanks, Miklos |
From: Filip M. <f.m...@tu...> - 2006-11-29 12:30:43
|
Miklos Szeredi wrote: > OK, but upgrading the OS could bring in a problem which might show up > with strangly unrelated symptoms. > I agree. sshfs seems as the first place to look into the issue. The reason I formulated this as a potential bug is that I remember the early versions of sshfs worked smoothly with playback and otherwise, regardless of the strain on the network connection. (or at least in the network bandwidth usage range typical for my home net) I would consider fiddling with the parameters, with readahead being the first one in line for testing, but the way the problem comes about does not make me think the network bandwidth is insufficient. Here's why: I have a 2mbit ADSL outgoing link. I have two computers on the home net. The one hosting the files ('farm') which is attached to the router with a 100BaseT cable. And another ('cow') which accesses the router through IEEE802.11b (10mbps WiFi). When I have BitTorrent running steady at full speed on cow, and start xmms on a sshfs-mounted dir, the playback runs smoothly. But even if BT is not runing (hence all the bandwidth that was used by BT in the previous example is now free for sshfs to use), fiddling with firefox and copying files triggers the problem. Hope this helps explain the situation somewhat better. > normally. Nothing is pending in sshfs that would cause xmms to hang. > Sorry if there was misunderstanding: xmms does not hang. It rather just stops playing. Otherwise it is as responsive as ever. I can play another song (by say selecting from the playlist), play the same song anew (by clicking the 'play' button), or even continue the song from where xmms stopped playing it (by clicking the 'pause' button twice (sic!)). But you can understand that after double-clicking the pause button the tenth time, the fun is mostly gone. sshfs works rock solid on my machines for data transfer. (At this point let me give a tip o' the hat to sshfs developers) The only issue is the mp3 file playback. > The other thing you could try is stracing xmms. The problem with that > is xmms is multithreaded, and it might not be trivial to see [...] Thanks for the tips, I will give it a try. f |
From: <mik...@ho...> - 2006-11-29 11:54:00
|
On Wed, 29 Nov 2006, Filip Miletic wrote: > Yes, I have tried with local MP3 files and have no such issue whatsoever. Have you tried to play MP3 files on a remote volume mounted via some other network filesystem, such as Samba or NFS? |
From: Filip M. <f.m...@tu...> - 2006-11-29 12:48:42
|
Mikael St=C3=A5ldal wrote: > Have you tried to play MP3 files on a remote volume mounted via some > other network filesystem, such as Samba or NFS? I used NFS prior to sshfs. NFS had strange artifacts. It would allow smooth mp3 playback, or file transfer for some time, say a few minutes. Then it would slow down dramatically: the mp3 playback would become unusable, and file transfer would unfold much slower than in the beginning. Remounting the NFS volume would give another few minutes of smooth operation. FWIW, NFS had a different, but IMHO more logical, effect to xmms mp3 playback: xmms would play a few seconds worth of music, then stop and ponder a while, then play another few seconds, then ponder again, and repeat the cycle. Then I tried sshfs. And at first it single-handedly solved all the issues I had with NFS (slowness, playback problems, maintenance issues etc). Only after a few sshfs upgrades (an a few months worth of great fun with sshfs) did I begin noticing the mp3 issues. As I said before, bar this, sshfs has worked for me without problem. f |
From: Miklos S. <mi...@sz...> - 2006-11-29 15:05:33
|
> I would consider fiddling with the parameters, with readahead being the > first one in line for testing, but the way the problem comes about does > not make me think the network bandwidth is insufficient. With a 2mbps link, there isn't likely to be a problem with the bandwidth use of mp3s (100-200kbps). But readahead is important if the latency (round trip time) of the link is high even if there's more than enough bandwidth. > > normally. Nothing is pending in sshfs that would cause xmms to hang. > > > Sorry if there was misunderstanding: xmms does not hang. It rather just > stops playing. Otherwise it is as responsive as ever. I can play another > song (by say selecting from the playlist), play the same song anew (by > clicking the 'play' button), or even continue the song from where xmms > stopped playing it (by clicking the 'pause' button twice (sic!)). Interesting. It's possibly a combination of a bug in xmms with some strange timing of reads only produced by sshfs. You _could_ experiment with the readahead parameters, as that would change the timings. Miklos |
From: Filip M. <f.m...@tu...> - 2006-11-29 15:22:56
|
Miklos Szeredi wrote: > But readahead is important if the latency (round trip time) of the link is high > Aha! I think there's some meat there. > Interesting. It's possibly a combination of a bug in xmms with some > strange timing of reads only produced by sshfs. Does not need to be a bug in xmms. Assuming that xmms aborts play after it hits some latency limit, and assuming that sshfs hits it for some reason would account for the effect. There's nothing really that xmms can do to prevent this as latencies are unbounded in general. I'll experiment a bit and will revert with the results. f p.s. if latency is the problem, then the playback should also be sensitive to the speeds of the peer machines ('cow' and 'farm') right? Also, then setting a large readahead buffer in xmms should also help out because playback is the only one that suffers, and increasing readahead in sshfs increases the time xmms has to wait for a data packet if I am not mistaken. |
From: Miklos S. <mi...@sz...> - 2006-11-29 15:55:52
|
> > But readahead is important if the latency (round trip time) of the link is high > > > Aha! I think there's some meat there. > > Interesting. It's possibly a combination of a bug in xmms with some > > strange timing of reads only produced by sshfs. > Does not need to be a bug in xmms. Assuming that xmms aborts play after > it hits some latency limit, Which I would consider a bug :) What you described in the NFS case (xmms stops for a bit then restarts) would be the correct behavior in that case. > p.s. if latency is the problem, then the playback should also be > sensitive to the speeds of the peer machines ('cow' and 'farm') right? On slow machines and high transfer rates encryption can add considerable latency. But it shouldn't matter for the low bandwidth of mp3s. Miklos |