You are here: Home » Topic » NSLU performance

NSLU performance

Viewing 15 posts - 1 through 15 (of 37 total)
  • Author
    Posts
  • #1038
    uncleremus
    Participant

    Hello,

    I have a LinkSys NSLU2 that I have “unslung” http://www.nslu2-linux.org/wiki/Unslung/HomePage. These things worked fine and I installed mt-daapd on it, the “nightly builds” and it works fine with my Roku Soundbridge. There is however one problem, the performance is quite lagging. When I e.g. “Brows Artists” I have to wait for a minute before all artists (~1500) are downloaded to the Soundbridge.

    On the other hand, if I run firefly on a laptop with Windows, things are much better and the same operation is complete within a few seconds (and during that test I ran a compile simultaneously on a large source tree, so the machine was also under stress).

    Are there any key tricks to make firefly on an unslung NSLU more responsive?

    #8724
    rpedde
    Participant

    @uncleremus wrote:

    Hello,

    I have a LinkSys NSLU2 that I have “unslung” http://www.nslu2-linux.org/wiki/Unslung/HomePage. These things worked fine and I installed mt-daapd on it, the “nightly builds” and it works fine with my Roku Soundbridge. There is however one problem, the performance is quite lagging. When I e.g. “Brows Artists” I have to wait for a minute before all artists (~1500) are downloaded to the Soundbridge.

    On the other hand, if I run firefly on a laptop with Windows, things are much better and the same operation is complete within a few seconds (and during that test I ran a compile simultaneously on a large source tree, so the machine was also under stress).

    Are there any key tricks to make firefly on an unslung NSLU more responsive?

    There are several problem with the slug — it’s under-cpu powered, under RAMed, etc. Turns out it’s really hard to make it perform well. 🙁

    This particular problem, though, seems to scale okay by making an index on the fields you browse on. I was considering building indexes on those fields to help speed up the returns on browses.

    If you are comfortable with playing around in the raw database with sqlite, you can do that yourself:


    $ sqlite /opt/var/mt-daapd/songs.db
    sqlite> create index idx_artist on songs(artist)

    That should build the index, and it should use that index when doing browses by artist.

    — Ron

    #8725
    uncleremus
    Participant

    Thanks a lot, I will test this later today!

    #8726
    uncleremus
    Participant

    Hmmmm, I’m having a problem when I try to follow your recommendation, I get this strange behaviour:

    # ls -las /opt/var/mt-daapd
    4 drwxr-xr-x 2 guest root 4096 Jan 27 23:11 .
    4 drwxr-xr-x 3 root root 4096 Jan 18 07:15 ..
    34220 -rw-r--r-- 1 guest everyone 34999296 Jan 27 23:11 songs.db
    20 -rwxr-xr-x 1 guest root 18139 Jan 21 11:33 songs.gdb
    # sqlite /opt/var/mt-daapd/songs.db
    sqlite: No such file or directory

    I also installed midnight commander, but I cannot run it, I get the same thing.

    # mc
    mc: No such file or directory

    EDIT:

    Found the problem, I think /opt/bin is not in my path, doing


    # /opt/bin/sqlite /opt/var/mt-daapd/songs.db
    SQLite version 2.8.16
    Enter ".help" for instructions
    sqlite> create index idx_artist on songs(artist)
    ...>

    so I guess it is creating the index now

    #8727
    uncleremus
    Participant

    Hmmmm, I have no idea what to do now, I have never interacted with sqlite before. It still looks like its processing, but I guess it is not.

    sqlite> create index idx_artist on songs(artist)
    ...>
    ...> .help
    ...> help
    ...> quit
    ...> q
    ...> sqlite close
    ...> close
    ...>

    The first …> came immediately, or very shortly, after I entered return. My point being that it did not seem like the time it would take to index all those artists.

    #8728
    fizze
    Participant

    hehe, thats prolly the newbie SQL error/trap #1, ever 😀

    you need to end all your commands with a semicolon

    ;

    😉

    #8729
    uncleremus
    Participant

    @rpedde wrote:

    @uncleremus wrote:

    Are there any key tricks to make firefly on an unslung NSLU more responsive?

    If you are comfortable with playing around in the raw database with sqlite, you can do that yourself:


    $ sqlite /opt/var/mt-daapd/songs.db
    sqlite> create index idx_artist on songs(artist)

    That should build the index, and it should use that index when doing browses by artist.

    — Ron

    Many many thanks, this worked very fine. I did as you said and restarted mt-daapd and got a lot faster access when “entering” an artist in the “Browse Artists” part of the navigation in the Soundbridge.

    There is however one more thing I’d like to speed up and that is the initial download of artists, that is taking as much time as before, i.e. the part where I press “OK” in the “Browse Artists”-field.

    This would be especially useful, since I am often browsing like this:

      Browse Artists? OK! …30s….
      Frank Zappa? OK!…[now much faster thanks to your tip!]…
      All Songs? OK! ….[also faster]….
      Play

    And then, when I want to change Artist, i have to go through all this again (at least I think so, I haven’t found another way with the Soundbridge).

    So, if I could speed up step 1 above, that would make it even better.

    #8730
    S80_UK
    Participant

    @uncleremus wrote:

    And then, when I want to change Artist, i have to go through all this again (at least I think so, I haven’t found another way with the Soundbridge).

    So, if I could speed up step 1 above, that would make it even better.

    Don’t forget that using ADD (to queue) on the remote rather than PLAY does not throw you back to the beginning of the search. So if you know what you will want to listen to after you’ve listened to Frank Zappa, then after adding him you can quickly step through to other artists and ADD them as well. Once all done, press PLAY to start. Should save you some time. 🙂

    #8731
    mas
    Participant

    There is however one problem, the performance is quite lagging. When I e.g. “Brows Artists” I have to wait for a minute before all artists (~1500) are downloaded to the Soundbridge.

    On the other hand, if I run firefly on a laptop with Windows, things are much better and the same operation is complete within a few seconds (and during that test I ran a compile simultaneously on a large source tree, so the machine was also under stress).

    Are there any key tricks to make firefly on an unslung NSLU more responsive?

    Well the NSLU is a different class in CPU power than a normal PC, but I cannot agree that it is running sluggish at all with about 3500 songs here.

    Even a play-all takes only ca. 5 Secs. downloading all 3500 song titles. I am running DebianNSLU-LE here, but it wasnt much different with unslung before.

    I think the key things to keep in mind are:

      – Run 1-2 major applications on it. Maybe one minor in addition. Not more. The thing isnt a general server to run 20 server-apps at the same time as you can do with a PC running some linux-server install. Strip the unneeded rest!
      – Run economic programs. Dont use apache/mysql if lighthpptd/sqlite will also do. etc.
      – Use the latest nightly. It is way faster than the stables. Especially the transcoding is way better.
      – De-underclock it unless it is already

    I can run without trouble mt-daapd latest nichthly, samba and ntpd on my slug. It will run without rebuffering when I have it transcode an ogg from an AES128 encrypted partition. Even though it has to decrypt plus transcode/stream then. Theres even a bit reserve – small up/downloads via samba dont hamper it.
    Now if I trash the thing by logging in via ssh and starting a big compile job, then it goes crawling of course. But is that a surprise?

    So the performance is more than enough, if one doesnt overwhelm the unit by trying to do everything at the same time. What you describe seems to indicate something is wrong, thats not the slow NSLU.

    #8732
    S80_UK
    Participant

    @mas wrote:

    What you describe seems to indicate something is wrong, thats not the slow NSLU.

    I have to agree. My “worst-case” browse is Browse Songs (I have 6685 today) and that takes about 14 seconds (maybe 2 or 3 more if streaming WAV and transcoding at the same time).

    Setup NSLU2 at 266MHz (unslung to stick, but database on HDD), SB M1000 is wireless to router, router is wired to NSLU2.

    #8733
    rpedde
    Participant

    @mas wrote:

    So the performance is more than enough, if one doesnt overwhelm the unit by trying to do everything at the same time. What you describe seems to indicate something is wrong, thats not the slow NSLU.

    I agree. What kind of file system is the drive that houses your music and database? Is it NTFS? That’s notoriously slow on the NSLU2.

    — Ron

    #8734
    mas
    Participant

    Well the speed is not even the problem with the proprietary paragon NTFS driver that the unslung and original software uses.
    I tried it in the beginning, you dont even notice any speed issues. The driver is so buggy that it corrupts your data before you have a chance of complaining about the speed. LOL*
    Usually 15 minutes of heavier use and its set to readonly because of an error. What a joke.

    So I dont think this can be the source of the problem. We should have heard another type of complaint then.

    #8735
    uncleremus
    Participant

    Hello and thanks again for all your help.

    I have done exactly as it says in the unslung README that they say is mandatory to follow to the point, which I did. So, I “ipkg”:ed out mt-daapd and that’s about it what I have installed outside of what that README implies.

    Oh yes, I have also installed midnight commander.

    As for the external disc, it is ext3.

    #8736
    rpedde
    Participant

    @uncleremus wrote:

    Hello and thanks again for all your help.

    I have done exactly as it says in the unslung README that they say is mandatory to follow to the point, which I did. So, I “ipkg”:ed out mt-daapd and that’s about it what I have installed outside of what that README implies.

    Oh yes, I have also installed midnight commander.

    As for the external disc, it is ext3.

    How many songs do you have in your corpus?

    #8737
    zuovo2
    Guest

    I also had serious performance issues with browsing, running mt-daapd on an NSLU2, and fixed most of them as follows:

    1) Overclocking the slug was super easy (using just tweezers, no solder), and this gave me a 30% performance boost for getting the full Artists list. See http://www.nslu2-linux.org/wiki/HowTo/OverClockTheSlug.

    2) Cleaning or splitting your music collection to sets of 5K or fewer songs, if possible, would fix the problem. In my case, most of my mp3s were in a backup folder that was double-indexed (doh!). Moving that folder and deleting some other junk brought the number of songs well under 10K. You might also consider splitting your collection and running multiple instances of firefly as discussed in http://forums.fireflymediaserver.org/viewtopic.php?t=4688, though this seems like a last-resort hack.

    3) Indexing the artist/album/genre columns of the songs table gives a huge improvement for browsing with partial criteria (eg give me all albums for artist X, or give me all artists for genre Y). But as you noticed, it does not affect the query for a full list of artists, albums, and genres. This is because the index affects only queries where that column is in the search criteria (e.g. “select * from songs where artist=’X'”) not queries where that column is just in the results (e.g. “select artist from songs”).

    On my system, it now takes 6-8s to get the full Artists list from Firefly. Not as bad as your 30s delay, but still unacceptable IMO to begin every browse.

    In my case, I looked for a solution on the client, not the server. I use a wireless PocketPC running VisualMR to control my SoundBridge, and Thorsten, bless his soul, was kind enough to implement client-side caching of the artist/album/genre lists in VisualMR 1.5. Since my PocketPC is always on, getting the full list of artists, albums, or genres is now instantaneous. No Firefly queries, no SoundBridge commands, no wireless roundtrips. I only need to clear the cache and re-fetch the lists of artists, etc. when I add new files on the server.

    I’m guessing that this performance issue could also be fixed on the server if Firefly maintained a separate “artists” table in songs.db. Then the database would not need to scan the entire “songs” table to get the list of artists, which is much smaller than the list of songs. Ditto for albums and genres. If enough people are running Firefly on slow NAS units with large music collections, perhaps Ron will consider this. It can’t hurt to ask, anyway. 🙂

    Happy listening – hope this helps!


    Linksys NSLU2 — 266Mhz, EXT3, Unslung 6.8 beta, Firefly svn-1450
    SoundBridge M1001 — 2.7.50, WPA-TKIP
    Dell Axim X30 — WM2003SE, WPA-TKIP, VisualMR 1.5.0

Viewing 15 posts - 1 through 15 (of 37 total)
  • The forum ‘General Discussion’ is closed to new topics and replies.