PDA

View Full Version : Best Performance - recommendations?



thomas
2005-07-29, 03:01
Hello,

I have two original Slimp3s and one of the second generation wired players. All three run from one Slimp3 server. The server has about 60GB of music. Often, there is more than one person viewing the web interface. The players are only ever controlled from the web interface, nobody has access to the hardware players or remotes.

The larger the music library gets, the worse the performance. It's getting to a stage where it really isn't good enough to run - when for example two people run searches on the music library, all three players will stall.

I know the server is designed with single users in mind, but there must be a way of increasing performance. Originally I ran the server on a Windows box, but have found performance slightly better when running on Mac OS X. The Mac box I have is only a dual-1Ghz G4.

What hardware and OS is recommended for best performance? I don't mind spending some money on getting it right, but am reluctant to unless I have a pretty good idea of what sort of improvement I can expect and what hardware and OS is likely to perform best.

Thx

Thomas

radish
2005-07-29, 06:49
Well dual CPUs aren't going to help as slimserver is single threaded, so your mac is effectively a single 1GHz G4. I would imagine you want the fastest single proc you can get, but I don't have any specific recommendations.

Jim
2005-07-29, 16:33
thomas wrote:
> Hello,
>
> I have two original Slimp3s and one of the second generation wired
> players. All three run from one Slimp3 server. The server has about
> 60GB of music. Often, there is more than one person viewing the web
> interface. The players are only ever controlled from the web interface,
> nobody has access to the hardware players or remotes.
>
> The larger the music library gets, the worse the performance. It's
> getting to a stage where it really isn't good enough to run - when for
> example two people run searches on the music library, all three players
> will stall.
>
> I know the server is designed with single users in mind, but there must
> be a way of increasing performance. Originally I ran the server on a
> Windows box, but have found performance slightly better when running on
> Mac OS X. The Mac box I have is only a dual-1Ghz G4.
>
> What hardware and OS is recommended for best performance? I don't mind
> spending some money on getting it right, but am reluctant to unless I
> have a pretty good idea of what sort of improvement I can expect and
> what hardware and OS is likely to perform best.

Unless you're transcoding on-the-fly, I'd look first at the hard drive
speed and RAM. I suspect since you're using a somewhat older Mac (early
2002, yes?), that the drive isn't all it can be. The stock 512MB of RAM
that came with the dual processor units should be enough, though PC133
isn't screaming fast.

Western Digital, and others, have IDE drives with integrated 8MB caches.
They're affordable and perform very well compared to a 2MB cache version.

Personally, I use Linux (Fedora Core 1) to host SlimServer and three
players. My library is pretty "medium" in size, 3,000 songs at ~11GB.
2.4GHz Celeron with 512MB RAM and one of the WD 8MB drives, cost me
about $300.

Jim

Mitch Harding
2005-07-29, 18:20
If disk IO is the limiting factor, I'd consider a RAID array. With
drive prices, RAID 5 is affordable and gives you both improved disk
access times plus data security.

On 7/29/05, Jim <jim1128 (AT) comcast (DOT) net> wrote:
> thomas wrote:
> > Hello,
> >
> > I have two original Slimp3s and one of the second generation wired
> > players. All three run from one Slimp3 server. The server has about
> > 60GB of music. Often, there is more than one person viewing the web
> > interface. The players are only ever controlled from the web interface,
> > nobody has access to the hardware players or remotes.
> >
> > The larger the music library gets, the worse the performance. It's
> > getting to a stage where it really isn't good enough to run - when for
> > example two people run searches on the music library, all three players
> > will stall.
> >
> > I know the server is designed with single users in mind, but there must
> > be a way of increasing performance. Originally I ran the server on a
> > Windows box, but have found performance slightly better when running on
> > Mac OS X. The Mac box I have is only a dual-1Ghz G4.
> >
> > What hardware and OS is recommended for best performance? I don't mind
> > spending some money on getting it right, but am reluctant to unless I
> > have a pretty good idea of what sort of improvement I can expect and
> > what hardware and OS is likely to perform best.
>
> Unless you're transcoding on-the-fly, I'd look first at the hard drive
> speed and RAM. I suspect since you're using a somewhat older Mac (early
> 2002, yes?), that the drive isn't all it can be. The stock 512MB of RAM
> that came with the dual processor units should be enough, though PC133
> isn't screaming fast.
>
> Western Digital, and others, have IDE drives with integrated 8MB caches.
> They're affordable and perform very well compared to a 2MB cache version.
>
> Personally, I use Linux (Fedora Core 1) to host SlimServer and three
> players. My library is pretty "medium" in size, 3,000 songs at ~11GB.
> 2.4GHz Celeron with 512MB RAM and one of the WD 8MB drives, cost me
> about $300.
>
> Jim
>
>

Stewart Loving-Gibbard
2005-08-03, 15:25
>>>The larger the music library gets, the worse the performance. It's
>>>getting to a stage where it really isn't good enough to run - when for
>>>example two people run searches on the music library, all three players
>>>will stall.

Ah, a topic near to my heart.

I'm running a dual P3 800 mhz Linux box. 512 MB RAM. 750 GB RAID 5 array
(4 x 250 GB drives, PATA), 3Ware 4-port RAID controller. I have about
300 GB of MP3s in the SlimServer library. 2 Slimp3s, 1 Squeezebox 1,
although it's the Slimp3s getting active duty.

The server does some very light email chores and file serving, but its
primary task is to run Slimserver. Which it struggles with. Which still
surprises the heck out of me.

Doing a search or active use of the web interface will often interrupt
music playing. The web interface can take 10-20 seconds to respond or
get to the next tab, although it's usually 2-5 seconds.

Until browsing was fixed in the 6.1.x releases, it could take 50 seconds
to get from one directory to enclosed directories using the remote and
display. Sometimes, the player display would actually blank out. Now,
it's better, but each button press still takes .5 - 5 seconds to
respond, usually .5-1.5 seconds. It's still aggravating, regardless.

I can't shake the feeling that if the server were multi-threaded that
these problems would be completely absent. One thread to make sure the
players didn't go dry, one to handle navigation via the remote, one to
handle the web server, etc. Part of me keeps hoping SlimDevices has a
master plan to fix all this. Python, Java? A tidy C++ core maybe? I'm
not holding my breath.

In the meantime, I'm going to throw an absurd amount of hardware at this
problem. I'm putting together a dual Xeon 3ghz server, likely with a
Areca SATA RAID 5. (The performance of the 3ware RAID cards has always
been underwhelming, Perl proc hogs aside. The Areca/Tekrams I have
running elsewhere seem far, far better.)

I'd be curious if anyone out there with a "large" library (I'll let you
define what that means) is getting good or even snappy performance with
their setup? Care to brag?

Stew

Mitch Harding wrote:
> If disk IO is the limiting factor, I'd consider a RAID array. With
> drive prices, RAID 5 is affordable and gives you both improved disk
> access times plus data security.
>
> On 7/29/05, Jim <jim1128 (AT) comcast (DOT) net> wrote:
>
>>thomas wrote:
>>
>>>Hello,
>>>
>>>I have two original Slimp3s and one of the second generation wired
>>>players. All three run from one Slimp3 server. The server has about
>>>60GB of music. Often, there is more than one person viewing the web
>>>interface. The players are only ever controlled from the web interface,
>>>nobody has access to the hardware players or remotes.
>>>
>>>The larger the music library gets, the worse the performance. It's
>>>getting to a stage where it really isn't good enough to run - when for
>>>example two people run searches on the music library, all three players
>>>will stall.
>>>
>>>I know the server is designed with single users in mind, but there must
>>>be a way of increasing performance. Originally I ran the server on a
>>>Windows box, but have found performance slightly better when running on
>>>Mac OS X. The Mac box I have is only a dual-1Ghz G4.
>>>
>>>What hardware and OS is recommended for best performance? I don't mind
>>>spending some money on getting it right, but am reluctant to unless I
>>>have a pretty good idea of what sort of improvement I can expect and
>>>what hardware and OS is likely to perform best.
>>
>>Unless you're transcoding on-the-fly, I'd look first at the hard drive
>>speed and RAM. I suspect since you're using a somewhat older Mac (early
>>2002, yes?), that the drive isn't all it can be. The stock 512MB of RAM
>>that came with the dual processor units should be enough, though PC133
>>isn't screaming fast.
>>
>>Western Digital, and others, have IDE drives with integrated 8MB caches.
>>They're affordable and perform very well compared to a 2MB cache version.
>>
>>Personally, I use Linux (Fedora Core 1) to host SlimServer and three
>>players. My library is pretty "medium" in size, 3,000 songs at ~11GB.
>>2.4GHz Celeron with 512MB RAM and one of the WD 8MB drives, cost me
>>about $300.
>>
>>Jim
>>
>>

radish
2005-08-03, 17:02
I don't know if I qualify as "large", but this is my current status:

Your music library contains 750 albums with 9298 songs by 3275 artists

That's mainly FLAC or Vorbis (a few mp3s) taking around 130GB total. Slimserver (6.1.1) is running on XP Pro/SP2, on a 1.3GHz athlon with 512mb and Seagate Barracuda disks (no RAID, PATA). The box is pretty much idle apart from SS. Performance when browsing is fine, the occasional UI pause of less than a second (for instance when going into Browse Artists) but I can live with that. Interruptions are rare (I'm not sure I've seen once since upgrading the server) but to be honest I don't really stretch it - we rarely use more than one player at a time.

tgoldstone
2005-08-04, 06:23
When I set up my system I took the 200% approach which was to make a system that was 200% more than I needed. I have a SB1 and an SB2 both wireless. I have never had a hiccup or a pause or anything that has effected slimserver performance. UI performance is excellent.
This setup is working great for me.
Intel mainboard 7505 chipset with dual 2.4ghz xeon with HT.
Mirrored 10K RPM Raptor system drives
4 250GB WD SATA drives raid 5 using Adaptec 4 port 64mhz PCI-X card.
1GB RAM DDR something.

Current library is 12,500 tracks and growing...

CouchPotatoe
2005-08-04, 07:43
Stewart Loving-Gibbard wrote:

> >>>The larger the music library gets, the worse the performance. It's
> >>>getting to a stage where it really isn't good enough to run - when for
> >>>example two people run searches on the music library, all three
> players
> >>>will stall.
>
> Ah, a topic near to my heart.
>
>
> In the meantime, I'm going to throw an absurd amount of hardware at
> this problem. I'm putting together a dual Xeon 3ghz server, likely
> with a Areca SATA RAID 5. (The performance of the 3ware RAID cards has
> always been underwhelming, Perl proc hogs aside. The Areca/Tekrams I
> have running elsewhere seem far, far better.)
>
> I'd be curious if anyone out there with a "large" library (I'll let
> you define what that means) is getting good or even snappy performance
> with their setup? Care to brag?
>
Hi Stewart,

A topic near to my heart too. I would caution against throwing
"absurd amounts of hardware" at this as a solution. SlimServer runs for
me on XP on a 3.4GHz 4GB memory machine, almost dedicated and the
results , although slightly better than before, are still flawed. Memory
- which was a big issue on v5 is now not an issue under v6. Here's my
experience...

I have a very large library - circa 100K tracks, and I have 8 players
although only ever about 2 or 3 are playing. The V6 Slimserver has
helped solve a lot of my problems (stalls) but it hasn't fixed what I
believe is an architecture issue in SlimServer to do with threading. It
is not the number of players that is the issue btw. On searching my
library I can interrupt all playback and displays for over 15 minutes !!
This is to do with the search results being large, if you search for
narrower terms then control returns quicker, say 2-3 minutes but once
you exceed 10 secs or so then music stalls so it's still an issue. . If
I rescan my libray it takes over 24 hours :-( and all player
interaction is lost for that time. This has got much worse btw in recent
(beta) builds. There has been a bug filed over a year since v5.1.6 - it
was hoped to fix this in v6 with the new DB architecture and then when
it didn't pan out it was intended for 6.1 but now yet again it has been
pushed to a 6.2 target.

I can't help feeling that this is a big issue in how SlimServer is
architected and may not be so easy to remedy. No consumer product
should really lock out users for long lengths of time however my library
size is hardly typical consumer either so that is unfair. If people with
much more typical libraries are seeing this then it's an issue though.
I feel the display, IR remote and playback should be threaded
separately from the other processes such that they can continue to
function without interruption. mp3 playback (no transcoding) is a very
light cpu task and the DB searches now seem lightning fast in their
responses - it's the subsequent data handling and the library scan task
that seems to kill anything - which to me ( as a novice programmer)
seems something that shouldn't be happening, but may be a bi-product of
Perl or something.. In a way I wish a big development pause/splurge
could be had on the fundamental performance issues of SlimServer rather
than fancy new features, but that's not so interesting to people I
guess. The open source side does tend to become a bit of a
rollercoaster sometimes - but that's why I love SlimServer too - all the
new things that it can do . My purchase has grown in functionality for free.

I am hanging on in there for this fix as SlimServer is potentially
such a great product for me (if it worked) , the current situation is
very fragile though. The fact that player actions effect other players
(stalling / interrupting music) is my main problem. I control via AMX
and Crestron and these modules get really messed around by stalls in the
CLI interface too. But, I'll wait to 6.2 and pin my hopes on that once
more. No other solution is as accessible and flexible for me as
SlimServer and fits so well into my HA setup so fingers crossed. Indeed
I'm struggling at the moment to find an alternative or I might have
jumped already.


Kevin

dean
2005-08-04, 07:50
Kevin,

Which bug numbers describe the issues you are having? Scanning and
searching should NOT take as long as you describe.

-dean

CouchPotatoe
2005-08-04, 07:57
dean blackketter wrote:

> Kevin,
>
> Which bug numbers describe the issues you are having? Scanning and
> searching should NOT take as long as you describe.
>
> -dean
>
>
Hi dean,

http://bugs.slimdevices.com/show_bug.cgi?id=399

Kevin

dean
2005-08-04, 08:08
Thanks, is there a bug about your scanning performance issues?

On Aug 4, 2005, at 7:57 AM, Kevin Hawkins wrote:

> dean blackketter wrote:
>
>
>> Kevin,
>>
>> Which bug numbers describe the issues you are having? Scanning
>> and searching should NOT take as long as you describe.
>>
>> -dean
>>
>>
>>
> Hi dean,
>
> http://bugs.slimdevices.com/show_bug.cgi?id=399
>
> Kevin
>
>

radish
2005-08-04, 08:20
I'm still surprised how many people are running SS on dedicated multi-proc boxes...

CouchPotatoe
2005-08-04, 08:22
No - I haven't filed a bug as I have only just experienced this in a
6.2 nightly . Previously I have kept my library DB between installs so I
don't know how long it's been there. I know some changes were made
recently to the DB duplicates issue and that maybe related. It maybe
something that isn't a bug in the 6.1 released version. I did make an
adjacent post (today) in a thread entitles "Re-Scan problems".

kevin

dean blackketter wrote:

> Thanks, is there a bug about your scanning performance issues?
>
> On Aug 4, 2005, at 7:57 AM, Kevin Hawkins wrote:
>
>> dean blackketter wrote:
>>
>>
>>> Kevin,
>>>
>>> Which bug numbers describe the issues you are having? Scanning
>>> and searching should NOT take as long as you describe.
>>>
>>> -dean
>>>
>>>
>>>
>> Hi dean,
>>
>> http://bugs.slimdevices.com/show_bug.cgi?id=399
>>
>> Kevin
>>
>>

Craig, James (IT)
2005-08-04, 08:28
I was just thinking that.
Surely overkill for what we all know is a single threaded process?

I run SlimServer on my office desktop, which I frequently use heavily
while playing music on SlimServer and I have no problems apart from
during the rescan, which I have scheduled to run at night.

(almost 10,000 MP3s on a 2Ghz 512Mb PC)

James
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

Marshall Clow
2005-08-04, 08:33
At 4:28 PM +0100 8/4/05, Craig, James (IT) wrote:
>I was just thinking that.
>Surely overkill for what we all know is a single threaded process?
>
>I run SlimServer on my office desktop, which I frequently use heavily
>while playing music on SlimServer and I have no problems apart from
>during the rescan, which I have scheduled to run at night.
>
>(almost 10,000 MP3s on a 2Ghz 512Mb PC)

I've set up a dedicated server: a mac mini with an external FireWire drive.
1/25 GHz G4, 512 MB RAM.

Works great to drive two or three players. Library is about 11K tracks.
--
-- Marshall

Marshall Clow Idio Software <mailto:marshall (AT) idio (DOT) com>

It is by caffeine alone I set my mind in motion.
It is by the beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.

Stewart Loving-Gibbard
2005-08-04, 13:23
Ah, good to know -- thank you for responding!

I have an Adaptec RAID card that came bundled with my new machine, I was
concerned it would be too slow for the purpose. Your library is just a
little smaller than mine, and your specs very close to what I was
intending. I'd be tickled if I had similar smooth sailing.

Stew

tgoldstone wrote:
> When I set up my system I took the 200% approach which was to make a
> system that was 200% more than I needed. I have a SB1 and an SB2 both
> wireless. I have never had a hiccup or a pause or anything that has
> effected slimserver performance. UI performance is excellent.
> This setup is working great for me.
> Intel mainboard 7505 chipset with dual 2.4ghz xeon with HT.
> Mirrored 10K RPM Raptor system drives
> 4 250GB WD SATA drives raid 5 using Adaptec 4 port 64mhz PCI-X card.
> 1GB RAM DDR something.
>
> Current library is 12,500 tracks and growing...
>
>

Mark.Bennett
2005-08-04, 14:46
Intrigued by this thread I wanted to test my system to see
what happens. First of all, I'll make no bones - it's a
fairly high-end system, so I wasn't expecting any problems:

Intel P4, 3.4GHz with Hyper-threading
1 GB 400MHZ dual-channel DDR
OS/home on a Western Digital 200GB PATA drive with 8MB Cache
Music on a Western Digital 250GB PATA drive with 8MB Cache
Linux (Fedora Core 2 SMP kernel)

(Don't ask how it got to be such a high-end system for
Slimserver, it just did.)

I loaded it up with as much as I reasonably can (slimserver wise):

2 * wireless SB2's (Flac to Flac)
1 * wireless SB1 (Flac to Wav)
1 Softsqueeze (on server) (Flac to Flac)
1 WinAmp (Flac to MP3)
1 PocketPC PDA (Flac to MP3)

All players were playing different music.

With all of this going on, the SS and decoding/re-encoding were
struggling to break 10% CPU load. No dropouts, excellent
performance.

To load it further I did a wipe and rescan, which put the overall
CPU performance up to effectively 100%. The only interruption from
sound on any of the players was when they tried to move to
the next track and couldn't find the database entry anymore.
Restarting worked fine even during the scan. All the players and
the web interface also remained responsive.

OK, I only have a small library (~6,500 Flac songs) but scanning
took roughly 15 minutes for the lot.

(BTW the machine was also running a mail client which was regularly
checking for email and Mozilla.)

Throwing hardware at the problem does help, even if it isn't
necessary.


--
"The biggest problem encountered while trying to design a system that
was completely foolproof, was, that people tended to underestimate the
ingenuity of complete fools." (Douglas Adams)

Mark.Bennett
2005-08-04, 14:49
One important piece of data to add:

slimserver-2005_05_30-1

Haven't bothered to update since it does what I need 99%
of the time.

On Thu, 2005-08-04 at 22:46 +0100, Mark Bennett wrote:
> Intrigued by this thread I wanted to test my system to see
> what happens. First of all, I'll make no bones - it's a
> fairly high-end system, so I wasn't expecting any problems:
>
> Intel P4, 3.4GHz with Hyper-threading
> 1 GB 400MHZ dual-channel DDR
> OS/home on a Western Digital 200GB PATA drive with 8MB Cache
> Music on a Western Digital 250GB PATA drive with 8MB Cache
> Linux (Fedora Core 2 SMP kernel)
>
> (Don't ask how it got to be such a high-end system for
> Slimserver, it just did.)
>
> I loaded it up with as much as I reasonably can (slimserver wise):
>
> 2 * wireless SB2's (Flac to Flac)
> 1 * wireless SB1 (Flac to Wav)
> 1 Softsqueeze (on server) (Flac to Flac)
> 1 WinAmp (Flac to MP3)
> 1 PocketPC PDA (Flac to MP3)
>
> All players were playing different music.
>
> With all of this going on, the SS and decoding/re-encoding were
> struggling to break 10% CPU load. No dropouts, excellent
> performance.
>
> To load it further I did a wipe and rescan, which put the overall
> CPU performance up to effectively 100%. The only interruption from
> sound on any of the players was when they tried to move to
> the next track and couldn't find the database entry anymore.
> Restarting worked fine even during the scan. All the players and
> the web interface also remained responsive.
>
> OK, I only have a small library (~6,500 Flac songs) but scanning
> took roughly 15 minutes for the lot.
>
> (BTW the machine was also running a mail client which was regularly
> checking for email and Mozilla.)
>
> Throwing hardware at the problem does help, even if it isn't
> necessary.
>
>
--
"The biggest problem encountered while trying to design a system that
was completely foolproof, was, that people tended to underestimate the
ingenuity of complete fools." (Douglas Adams)

Ert
2005-08-12, 12:02
Hiya.

On Aug 3, 2005, at 6:25 PM, Stewart Loving-Gibbard wrote:
> I can't shake the feeling that if the server were multi-threaded
> that these problems would be completely absent. One thread to make
> sure the players didn't go dry, one to handle navigation via the
> remote, one to handle the web server, etc. Part of me keeps hoping
> SlimDevices has a master plan to fix all this. Python, Java? A tidy
> C++ core maybe? I'm not holding my breath.

Like many of the people who have written on this thread, I have also
thought that separating the stream-serving and web-interface portions
of SlimServer into separate processes would help performance
dramatically. Over the last couple of years I've pretty much given
up using the web interface because of poor response, and very
frequently the device UI freezes for 10-100 seconds while trying to
navigate. I've just resigned myself to wandering away for a while
and coming back in a minute or two.

These are definitely problems that were once unnoticed, but have
grown as my library has grown, now at a large 120 GB / 25,000 tracks
on an admittedly aging 450 MHz single proc G3 Mac that's dedicated to
SlimServer. On one hand, I'd love it if my server was more robust,
on the other hand, I'm running two Slims from a 25K song library on a
7 year old computer with annoyances I've learned to live with.

I do sometimes renice the slimserver process down to -10 or -19 to
squeeze a little more out of it, but since it's a dedicated box it
doesn't do too much.

I've also noticed that some hooks for a mysql DB option are there
somewhere, yes? I've certainly considered switching to that in the
hopes I can squeeze some more performance out.

- Ert

MrC
2005-08-13, 10:02
[ this was also posted in the bug referenced early on page 1 of this topic - supplimental text added here ]

It is very difficult to diagnose this type of problem without more detailed data. It seems like those experiencing the problems are primarly on Windows. Data such as which task is hogging the CPU, how many page faults are occuring, and by which task, etc. would be invaluable.

Without that data, I'm going to play a hunch.

I don't know if this issue has been resolve for you folks or not, but this behaviour seems very much like something I've seen with particularly agressive virus scanners such as Kaspersky and a couple of others. I might be way off base with this diagnosis in this case, but the information below might be useful for others in the future if I've misdiagnosed in this case.

The reports here don't seem to indicate which tasks are actually hogging the CPU times, causing large numbers of page faults, doing large quantities of I/O, etc. This would be key information. Large VMs don't mean very much, as that's not the same as increasing consumption of memory, which does matter (ie. leak).

Some virus scanners when set on more agressive modes perform a checksum on each file, and store that checksum and other information in an additional "stream" of the file. The goal is that the virus scanner can compare the checksum information in its database with that in the new stream of the file more quickly than re-performing the checksum itself (esp. for large files). For database files that change constantly (ie. slims music database), and tagged music files, this agressive virus scanning performs horribly, and the system spends all its time doing disk I/O and checksum calculations, leaving nothing for other apps. The result, users experience long hangs or stalls, and the system is unusable.

Reducing the agressiveness of these scanners helps resolve the problem with no loss of security.

For those of you who don't know how to see this information, you can add many more very useful pieces of data to your Windows task manager. Under the Processes tab, open View->Select Columns and add all the possible columns. For your Performance tab, be sure to enable View->Show kernel times as well. During the times when the system seems wedged, watch and sort by the columns that show most activity.

thomas
2005-08-22, 07:13
Some replies mentioning multi-cpu box versus single threaded server process... that's the box that's available, so that's what I'm using.

Interesting to note responses showing no performance problems with similar sized libraries (10k tracks). My setup is used exclusively through the web interface - the player hardware is never controlled through the remote, so perhaps it is the load from the web interface that is causing the problem? Often there are ten or more users who have the interface open to see what's playing. There is a plain text 'now playing' page, but people tend just to leave the full interface open.

mdw
2005-08-22, 10:39
Hey Kevin -

I was working bug #2001 with Fred over the weekend and the fix seems to have had the added benefit of speeding up the reponses to my Crestron CLI polling program. Check out last night's build (I'm on 4030) and see if you see any improvement (I know that it won't address the DB issue) ...

On a related topic, I'm about to upgrade my server and wonder if you have any strong opinions about the tradeoffs of Linux vs. Windows for the server - I've used both and I can't decide if the added complexity of administering Linux (I'm not an advanced user) are worth any performance improvements. Thoughts?

Matt

Michaelwagner
2005-09-16, 21:51
Under the Processes tab, open View->Select Columns and add all the possible columns. For your Performance tab, be sure to enable View->Show kernel times as well.
This was very helpful. Thanks. For a start, it showed me that, despite comments in the code, slim does run at high priority on windoz boxes.

ModelCitizen
2005-10-08, 11:25
I'm glad I saw this thread as I was beginning to think that I was the only one experiencing constant and long-term issues with SlimServer performance.
I've run SS on lots of different boxes (always Windows XP, fastest machine was 3.2Hhx with 1gb RAM) and wired/wireless networks and the performance of SS has always been less than ideal.
Currently I have a library of about 275gb consisting of 805 flac albums (8952 songs and 1197 artists) on a Maxtor OneTouch 300gb USB drive. I almost always use the remote.

I have been exploring Linux/Unix recently to see if I can improve performance by using a spare work machine solely dedidated to SS. Unfortunately my experiments were stymied by the NTFS file system on the Maxtor and I fought shy of reformatting the disk with a Unix file system.

However, in between Linux/Unix experiments I thought I would try a clean install of XP Home SP2 and cut it down as much as I possibly could, taking out all extraneous services, windows gubbins etc and give priority to background services. I am not running any other programs other than SS (not even a virus checker or windows firewall). This installation is specifically aimed at running SS as effiently as is possible. No power management. Wired. Squeezebox 2. No other network activity.

Unfortunately this laptop is not a high spec machine. It only has a 500ghz P3 processor and O.5gb Ram. Is this considered to be too underpowered to run as a dedicated SS machine? What is SlimDevices minimum spec for XP running SS? I've had a good look around but not found any recommendations.

I've experimented. I am running the 6.1.1 download from the SD home page. My problem is definitely with processor usage. The processor usage always goes up to 99% whilst I am waiting for track/albumlistings to display. Using the remote, sometimes music listings can take an absolute age to appear... but unfortunately results do not appear to be consistant. In fact it seem that the problem is much worse when I first use the remote. After a few goes at browsing menus things appear to improve.
The most consistently bad result is browsing albums, i.e. Genres>Pop>Albums. Using this type of path it can take almost a minute to list albums and meanwhile the music stops playing. Unfortunately the album listing is my most used menu path.

At this moment all seems fast, so am flummoxed. But, "turning off" the Squeezebox2 by hitting the remote's power button once, and then turning it back on again seem to bring back the very slow display of album listings (at least at first).

Is there some sort of caching going on?

The other annoyance (minor in comparison) is that using the remote's up and down buttons (tapping lightly) can often cause it to skip a listing (i.e. does not go to next track/album, but goes to the next but one).

So, at this moment it sort of appears that if I use SS all the time there is no problem and that the problem of very slow track/album listings might only occur when I first start using the remote.

Although I am currently using an underpowered laptop these findings are consistent with all my experience on a variety of much higher spec machines.

BTW. It was very interesting to see that on the same machine with Linux/BSD installed (with Gui) browsing all the SS web interface menus (e.g server or player settings) was much, much faster (almost immediate) than on the XP minimal install, even though it took much longer for Firefox to open on the Linux/BSD installs than it did on the XP install.

Any thoughts would be very welcome.

MC

Patrick Dixon
2005-10-08, 11:43
I have been exploring Linux/Unix recently to see if I can improve performance by using a spare work machine solely dedidated to SS. Unfortunately my experiments were stymied by the NTFS file system on the Maxtor and I fought shy of reformatting the disk with a Unix file system.Linux can read an NTFS disk, but not write to it. So you'll need another disk to install the OS, or try SlimCD.

If you want a 'universal' HD, format with FAT - but use a Linux box rather than an XP box to do the formating, otherwise you will be size restricted.



The other annoyance (minor in comparison) is that using the remote's up and down buttons (tapping lightly) can often cause it to skip a listing (i.e. does not go to next track/album, but goes to the next but one).MC
http://bugs.slimdevices.com/show_bug.cgi?id=2018

ModelCitizen
2005-10-08, 12:34
Linux can read an NTFS diskAt the risk of subverting this thread I submit that *nix is not that good at reading NTFS disks, at least with all the distros I tried it appeared to be very flaky and extremely slow (I was reading a USB disk via USB 1 and *nix gui.. Windows had no problem though).

Thanks for the bug link. Wierd that there is only me, you and Dean on it though... ;-(
Sometimes I get the impression that all the geezas on this list spend all their lives on a computer and therefore use the web interface, not the remote.

MC

nmizel
2005-10-08, 12:41
Hello,

I have two original Slimp3s and one of the second generation wired players. All three run from one Slimp3 server. The server has about 60GB of music. Often, there is more than one person viewing the web interface. The players are only ever controlled from the web interface, nobody has access to the hardware players or remotes.

The larger the music library gets, the worse the performance. It's getting to a stage where it really isn't good enough to run - when for example two people run searches on the music library, all three players will stall.

I know the server is designed with single users in mind, but there must be a way of increasing performance. Originally I ran the server on a Windows box, but have found performance slightly better when running on Mac OS X. The Mac box I have is only a dual-1Ghz G4.

What hardware and OS is recommended for best performance? I don't mind spending some money on getting it right, but am reluctant to unless I have a pretty good idea of what sort of improvement I can expect and what hardware and OS is likely to perform best.

Thx

Thomas

Hello,

I also suffered from similar problems in the past with my SB1, mainly caused by my low-power hardware (VIA Eden 533 MHz, USB 1.1 external hard disk).

To overcome this, I managed to run two instances of slimserver.pl, one for the web interface (browse, search, rescan, etc.) and the other for the rest.

Since then, I never had any stall or drop out. I can even do a rescan while playing flac files and doing searches on my modest hardware without having the music being interrupted.

I'll post more details if anyone is interested.

Nicolas

ModelCitizen
2005-10-08, 13:04
I managed to run two instances of slimserver.pl, one for the web interface (browse, search, rescan, etc.) and the other for the rest.
I'll post more details if anyone is interested.
If this is on Windows (but I guess it's a Mac) I'd be very appreciative of more details.
MC

lemppari
2005-10-08, 13:59
I'll post more details if anyone is interested.

Nicolas

Please do!!

Kari

radish
2005-10-08, 14:50
This was very helpful. Thanks. For a start, it showed me that, despite comments in the code, slim does run at high priority on windoz boxes.

Not on mine it doesn't, stock install.

Michaelwagner
2005-10-08, 17:55
Not on mine it doesn't, stock install.
How odd. I just checked. There are 2 processes running:

Slimserver
which despite the name is actually the internet explorer window and runs at normal priority and

slim
which despite the name is actually the server, runs at high priority.

I'm currently running 5.4.0

radish
2005-10-08, 17:58
I'm on 6.1 so it's Slim Tray and slim.exe but they're both at Normal.

Michaelwagner
2005-10-08, 18:08
I'm on 6.1 so it's Slim Tray and slim.exe but they're both at Normal.
Maybe they broke it in 6?

Think we could put a bug request in to put back the feature they dropped in the move to 6? :-)

Michaelwagner
2005-10-08, 18:24
If you want a 'universal' HD, format with FAT - but use a Linux box rather than an XP box to do the formating, otherwise you will be size restricted.
I assume you mean FAT32, not really old FAT.

And a Win98 can do it too. Or a copy of Partition Magic. But starting at W2K, MS restrict FAT32 partitions to 40GB (or 32, can't remember).

Michaelwagner
2005-10-08, 18:32
I also suffered from similar problems in the past with my SB1, mainly caused by my low-power hardware (VIA Eden 533 MHz, USB 1.1 external hard disk).
I DJ with my squeezebox, and I'm trying to build a portable system. Portable means light weight hardware, small server, slow disks, etc. So I'm in a similar situation - I have to have low-spec hardware in order to have low weight.

Moreover, as a DJ, the sound can't stop. Like, it's not an option. Never. So "minor annoyances" people talk about where the music stops for only the merest second or two - those are the stuff of nightmares.


To overcome this, I managed to run two instances of slimserver.pl, one for the web interface (browse, search, rescan, etc.) and the other for the rest.
I considered doing this, but if you've already done it ...


I'll post more details if anyone is interested.
Totally!

stinkingpig
2005-10-08, 18:56
Michaelwagner wrote:

>nmizel Wrote:
>
>
>>I also suffered from similar problems in the past with my SB1, mainly
>>caused by my low-power hardware (VIA Eden 533 MHz, USB 1.1 external
>>hard disk).
>>
>>
>I DJ with my squeezebox, and I'm trying to build a portable system.
>Portable means light weight hardware, small server, slow disks, etc. So
>I'm in a similar situation - I have to have low-spec hardware in order
>to have low weight.
>
>Moreover, as a DJ, the sound can't stop. Like, it's not an option.
>Never. So "minor annoyances" people talk about where the music stops
>for only the merest second or two - those are the stuff of nightmares.
>
>
>
>

Sounds like you might be letting a less-important consideration
(portability) interfere with a more important consideration (viability).
What's wrong with a decent laptop chassis (say a T41, $500-$1000 on
EBay) and a 100GB 7200 RPM internal drive ($300)?

--
Jack At Monkeynoodle Dot Org: It's A Scientific Venture!
"I spent all me tin with the ladies drinking gin
so across the Western ocean I must wander" -- trad.

Michaelwagner
2005-10-08, 19:27
Michaelwagner wrote:

>I DJ with my squeezebox, and I'm trying to build a portable system.
Sounds like you might be letting a less-important consideration
(portability) interfere with a more important consideration (viability).
What's wrong with a decent laptop chassis (say a T41, $500-$1000 on
EBay) and a 100GB 7200 RPM internal drive ($300)?
Nothing, but if you read some of the other performance threads, that's no guarantee that it won't experience dropouts.

In fact, at the moment, I DJ from a Dell C610 with a built-in 40GB drive and an extra 80GB internal drive. Works fine with 5. Broke with "new improved better performance" 6, so I went back to 5. But I can't stay there forever.

pfarrell
2005-10-08, 19:30
On Sat, 2005-10-08 at 18:56 -0700, Jack Coates wrote:
> Michaelwagner wrote:
> >I'm in a similar situation - I have to have low-spec hardware in order
> >to have low weight.

> Sounds like you might be letting a less-important consideration
> (portability) interfere with a more important consideration (viability).
> What's wrong with a decent laptop chassis (say a T41, $500-$1000 on
> EBay) and a 100GB 7200 RPM internal drive ($300)?

Or a decent SFF chasis.

I'm not at all convinced that Michaelwagner has to have low spec.
The gaming dudes build SFF systems with the latest AMD or Pentiums, at
least a gig of ram, and multiple disks.

Compared to the rest of a DJ's setup (like PA speakers or turntables)
a SFF would be small and light and portable and as powerful as you want.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

pfarrell
2005-10-08, 20:28
On Sat, 2005-10-08 at 19:27 -0700, Michaelwagner wrote:
> Works fine with 5. Broke with "new improved better performance" 6, so I went back to 5.
> But I can't stay there forever.

Why not? I run Windows 2K on my serious Windows machine. And I'm
currently running my slimserver version 5.1 and use it every day.
It works for me, I see no reason to change. I'll probably change
once 6.2 is released, if it gets glowing reviews.

If it ain't broke, don't fix it.

Do you need something specific in SS 6.*?

Still, the easiest way to get performance in the PC world is with new,
fast systems. I'd look at a SFF system for music performance.
I don't like laptops in that environment because they tend to be
more fragile than I like. Not that you can let a roadie throw
any computer around like they do amps and speaker stands.
Get one with a handle on top.




--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

stinkingpig
2005-10-08, 20:57
Pat Farrell wrote:

>On Sat, 2005-10-08 at 18:56 -0700, Jack Coates wrote:
>
>
> ...
>
>>Sounds like you might be letting a less-important consideration
>>(portability) interfere with a more important consideration (viability).
>>What's wrong with a decent laptop chassis (say a T41, $500-$1000 on
>>EBay) and a 100GB 7200 RPM internal drive ($300)?
>>
>>
>
>Or a decent SFF chasis.
>
>I'm not at all convinced that Michaelwagner has to have low spec.
>The gaming dudes build SFF systems with the latest AMD or Pentiums, at
>least a gig of ram, and multiple disks.
>
>Compared to the rest of a DJ's setup (like PA speakers or turntables)
>a SFF would be small and light and portable and as powerful as you want.
>
>
>
>
SFF's are nifty for the gamers because they have rocking video cards,
but they're bigger than a laptop, just as expensive as a laptop, lack
the integrated flat panel, mouse, and keyboard, and are typically
somewhat noisier.

However, that improved video card could be worth a lot to a DJ... I've
been in a couple of clubs in Vegas where they were playing XMMS or
ITunes visualizations on the big projector screens :)

--
Jack At Monkeynoodle Dot Org: It's A Scientific Venture!
"I spent all me tin with the ladies drinking gin
so across the Western ocean I must wander" -- trad.

pfarrell
2005-10-08, 21:13
On Sat, 2005-10-08 at 20:57 -0700, Jack Coates wrote:
> Pat Farrell wrote:
> >Or a decent SFF chasis.
> >
> SFF's are nifty for the gamers because they have rocking video cards,
> but they're bigger than a laptop, just as expensive as a laptop, lack
> the integrated flat panel, mouse, and keyboard, and are typically
> somewhat noisier.

Panel, mouse and keyboard part is 100% right.
They tend to be noiser because gamers like P4-3400 CPUs and
killer 6800 video cards which have to have wicked fans.

If you didn't need screaming speed, you could get it a lot quieter
than the game dudes. And in a club, who's gonna hear a little fan
noise?

> However, that improved video card could be worth a lot to a DJ... I've
> been in a couple of clubs in Vegas where they were playing XMMS or
> ITunes visualizations on the big projector screens :)

That doesn't take the wacko 3D gamer video, any decent card can do that,
most big projectors aren't more than 1024x...
Beside, you don't expect people to look at the videos rather than
the hot chick or guy on the floor, do you?

If laptops are wanted for the display and IO, then I'd look
at big "desktop replacement" laptops, probably used from IBM
or other major vendor. Even a Centrino 1.5mHz is way fast enough
to Slimserver and a few other toys for eye candy. A grand worth of
used laptop can buy an impressive system.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

stinkingpig
2005-10-08, 21:17
Pat Farrell wrote:...

>
>If laptops are wanted for the display and IO, then I'd look
>at big "desktop replacement" laptops, probably used from IBM
>or other major vendor. Even a Centrino 1.5mHz is way fast enough
>to Slimserver and a few other toys for eye candy. A grand worth of
>used laptop can buy an impressive system.
>
>
>
Certainly a lot better than a Dell C610... one of those was part of the
junk box that I just sent back to corporate a few months ago. I sent it
back for a failed hard drive controller, might be worth asking what kind
of disk throughput michaelwagner is seeing, especially if he's driving
two drives.

--
Jack At Monkeynoodle Dot Org: It's A Scientific Venture!
"I spent all me tin with the ladies drinking gin
so across the Western ocean I must wander" -- trad.

Robin Bowes
2005-10-09, 04:57
ModelCitizen said the following on 08/10/2005 19:25:
> Unfortunately this laptop is not a high spec machine. It only has a
> 500ghz P3 processor and O.5gb Ram.

You might like to check that - when I was logged in when you had CentOS
installed the machine only appeared to have 192MB physical RAM .

R.
--
http://robinbowes.com

If a man speaks in a forest,
and his wife's not there,
is he still wrong?

Free Lunch
2005-10-11, 07:57
> Still, the easiest way to get performance in the PC world is with new,
> fast systems. I'd look at a SFF system for music performance.
> I don't like laptops in that environment because they tend to be
> more fragile than I like. Not that you can let a roadie throw
> any computer around like they do amps and speaker stands.
> Get one with a handle on top.

I run on an XP2200 system with 512MB of ram and 7200 RPM disks (Gentoo
Linux). The performance problems are mainly due to the way the
slimserver software is written. Throwing hardware at the problem will
not solve those design issues.

Telling people they just need to throw more money at it is not helping anyone.


FL

Michaelwagner
2005-10-11, 08:50
The performance problems are mainly due to the way the slimserver software is written. Throwing hardware at the problem will not solve those design issues.
That is my impression from the code reading I've done (when I worked in IT I was a performance analyst).

Clarification: in the short term, a user who does not want to become a developer can probably solve some problems by "overconfiguring" a system.
in the longer term, the code needs some selective performance analysis, segmenting and possibly some rewriting.

ModelCitizen
2005-10-11, 11:09
The performance problems are mainly due to the way the slimserver software is written. Throwing hardware at the problem will not solve those design issues.

That is my impression from the code reading I've done (when I worked in IT I was a performance analyst).
Clarification: in the short term, a user who does not want to become a developer can probably solve some problems by "overconfiguring" a system. In the longer term, the code needs some selective performance analysis, segmenting and possibly some rewriting.
So it's worse than I thought then? It's not solely a problem with Perl code performing badly on Windows machines (which in my experience is always been the case), it's just that SlimServer is fundamentally flawed and needs some part of the core rewriting. I remember when SD first mentioned the proposed SlimServer "upgrade" from 5.** to 6.** Robin Bowes was adamant that this should include making the application multi-threaded. Unfortunately his suggestion was not taken up. In retrospect it looks like it should have been.
MC

pfarrell
2005-10-11, 11:24
On Tue, 2005-10-11 at 11:09 -0700, ModelCitizen wrote:
> Free Lunch Wrote:
> > The performance problems are mainly due to the way the slimserver
> > software is written. Throwing hardware at the problem will not solve
> > those design issues.

I generally find that throwing hardware at most problems
solves performance. or at least makes it tolerable.

I ran SlimServer on a P3-500 box for over a year. It could
have been faster, but it worked fine. When the CPU fan died
and fried the CPU, I got a AMD 2200+ or so, and it is
more than fast enough for me.



> So it's worse than I thought then? It's not solely a problem with Perl
> code performing badly on Windows machines (which in my experience is
> always been the case), it's just that SlimServer is fundamentally
> flawed and needs some part of the core rewriting. I remember when SD
> first mentioned the proposed SlimServer "upgrade" from 5.** to 6.**
> Robin Bowes was adamant that this should include making the application
> multi-threaded. Unfortunately his suggestion was not taken up. In
> retrospect it looks like it should have been.

I'm not sure I want to jump into a discussion with such heated
terminology.

The discussion of whether the database back end or multi-threading
should be first priority got a lot of discussion. Both are big jobs.
With limited resources, one has to make decisions. The potential
for growth in functionality using the database is huge. The
re-implementation for multi-threading will only help folks who
don't get the performance they want from their hardware.

You are, of course, welcome to join developers (AT) lists (DOT) slimdevices.com
and help with the effort.

I don't see much point in complaining about water than is over the
dam and way downstream by now.



--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Triode
2005-10-11, 11:51
> Unfortunately this laptop is not a high spec machine. It only has a
> 500ghz P3 processor and O.5gb Ram. Is this considered to be too
> underpowered to run as a dedicated SS machine? What is SlimDevices
> minimum spec for XP running SS? I've had a good look around but not
> found any recommendations.
>

As this is a laptop do you have power management features enabled - if the disk spins down it will probably add several seconds to
the responsiveness of the UI when it starts up again.

I run on a 500MHz P3 OK under linux with good performance. I do find linux give better performance per MHz than Windows though.
When I test using a windows box with a claimed 4 times greater performance I don't see that over the linux platform. [in some cases
because of the other tasks the windows box does it can be slower]

You may want to try 6.2 as it getting close to release and hence nightlies are relatively stable. It includes quite a few updates
over 6.1.1 including improved speed for browsing the music folder (not the specific problem you identified) There's also a trial
web page which tries to monitor network and server performance ["Network and Server Health" in the help section] - this can give an
indication of performance problems and maintains a log of a few key performance metrics of the server process itself. I'd be
interested to see what it is showing when your server is running slow.

Adrian

Michaelwagner
2005-10-11, 12:14
It's not solely a problem with Perl code performing badly on Windows machines
I saw no evidence of that. I can fire off at least 10s of requests per second to the slim server and it handles the interrupts and replies quickly.


it's just that SlimServer is fundamentally flawed and needs some part of the core rewriting.
I wouldn't agree with that assessement either. I would say, from past experience with performance analysis of large pieces of code, that 99% of it is fine. There's 1% that may need some rewriting. Finding and identifying that 1% is often more work than the rewriting of it.


Robin Bowes was adamant that this should include making the application multi-threaded. Unfortunately his suggestion was not taken up. In retrospect it looks like it should have been.
Again, I don't think that conclusion is supportable (at least not as far as I have looked into it). I read in another thread recently that someone broke it out into 2 threads fairly easily, and that solved almost all of the problem. I'm waiting to hear back from him what he did. But from what he described, the results sound plausable and the work achievable without huge expenditures of time and resources.

Michael

ModelCitizen
2005-10-11, 12:37
I read in another thread recently that someone broke it out into 2 threads fairly easily, and that solved almost all of the problem. I'm waiting to hear back from him what he did. But from what he described, the results sound plausable and the work achievable without huge expenditures of time and resources. Michael
This thread... and I am *still* waiting to hear back from him too (hoping that the two instances of slimserver.pl do not require twice as much RAM as one process).
cygwin? efficient? c'mon. Surely anyone who has tried Windows ported perl code via cygwin can easily discern that it works very badly indeed on Windows compared to the original code on Unix/Linux?
MC

Michaelwagner
2005-10-11, 13:51
I am *still* waiting to hear back from him too (hoping that the two instances of slimserver.pl do not require twice as much RAM as one process).
The interpreter/compiler/hybrid/whatever no doubt has some RAM overhead of it's own. But I suspect the lions share of resource consumption is due to the actual perl code. If you strip function from one in order to move it to the other, the ram usage of the two will be greater than when it was monolithic, but hopefully nowhere near twice.

Dan Sully
2005-10-11, 14:04
* ModelCitizen shaped the electrons to say...

> cygwin? efficient? c'mon. Surely anyone who has tried Windows ported perl
> code via cygwin can easily discern that it works very badly indeed on
> Windows compared to the original code on Unix/Linux?

SlimServer doesn't run using Cygwin. We use ActiveState perl on Windows, which is native code.

-D
--
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin

Music Machine
2005-10-11, 15:13
Two cents from the Peanut Gallery

It seems like people are pretty happy with performance if they have around 350 or less albums in the database. 750 albums or more is about the place where no one seems satisfied with performance. Between those quantities satisfaction varies quite a bit. I could easily have missed posts to the contrary.

On the surface it looks like data handling is the bottleneck, not processing power.

I have no problems running SS on w2k with a 800mhz PIII and only 256 meg ram. My database has a little less than 350 albums.

Regards,
Music Machine

pfarrell
2005-10-11, 15:23
On Tue, 2005-10-11 at 15:13 -0700, Music Machine wrote:
> It seems like people are pretty happy with performance if they have
> around 350 or less albums in the database. 750 albums or more is about
> the place where no one seems satisfied with performance. Between those
> quantities satisfaction varies quite a bit. I could easily have missed
> posts to the contrary.

I've bought a small number of albums since I upgraded my server.
Right now, SS says "Your music library contains 707 albums with 10480
songs by 1188 artists."

I was quiet happy with the performance on my P3-500 w/384mB of ram.

More power is always good, but then, I'm not at your magic 750 number.
It is not clear to me what the important number is, number of albums,
or songs, or artists.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

stinkingpig
2005-10-11, 19:00
Music Machine wrote:

>Two cents from the Peanut Gallery
>
>It seems like people are pretty happy with performance if they have
>around 350 or less albums in the database. 750 albums or more is about
>the place where no one seems satisfied with performance. Between those
>quantities satisfaction varies quite a bit. I could easily have missed
>posts to the contrary.
>
>On the surface it looks like data handling is the bottleneck, not
>processing power.
>
>I have no problems running SS on w2k with a 800mhz PIII and only 256
>meg ram. My database has a little less than 350 albums.
>
>Regards,
>Music Machine
>
>
728 albums with 8504 songs by 755 artists

My performance is still fine on 6.1.1, though there can be some slowness
in browsing music. I guess I'd better quit buying albums :)

--
Jack At Monkeynoodle Dot Org: It's A Scientific Venture!
"I spent all me tin with the ladies drinking gin
so across the Western ocean I must wander" -- trad.

scalesr1
2005-10-11, 22:12
And another 2c:

I ran Slimserver (up to 5.4) on a dual PII-733 box, 1GB RAM for several
years - mostly OK. I now run the latest 'official' release on a P4 3Ghz box
with 1.5GB RAM under Windows 2003 Small Business Server and it mostly
performs at rocket speed - there are however significant delays (3-8
seconds) when navigating right from 'browse artists' or 'browse albums'
before the list of artists/albums is displayed. Once displayed I can
navigate through the list at high speed.

I suspect that the source of my particular problem is as follows:
2596 albums with 48489 songs by 6223 artists

Regards
Richard


-----Original Message-----
From: Jack Coates [mailto:jack (AT) monkeynoodle (DOT) org]
Sent: 12 October 2005 03:01
To: Slim Devices Discussion
Subject: Re: [slim] Re: Best Performance - recommendations?

Music Machine wrote:

>Two cents from the Peanut Gallery
>
>It seems like people are pretty happy with performance if they have
>around 350 or less albums in the database. 750 albums or more is about
>the place where no one seems satisfied with performance. Between those
>quantities satisfaction varies quite a bit. I could easily have missed
>posts to the contrary.
>
>On the surface it looks like data handling is the bottleneck, not
>processing power.
>
>I have no problems running SS on w2k with a 800mhz PIII and only 256
>meg ram. My database has a little less than 350 albums.
>
>Regards,
>Music Machine
>
>
728 albums with 8504 songs by 755 artists

My performance is still fine on 6.1.1, though there can be some slowness
in browsing music. I guess I'd better quit buying albums :)

--
Jack At Monkeynoodle Dot Org: It's A Scientific Venture!
"I spent all me tin with the ladies drinking gin
so across the Western ocean I must wander" -- trad.

Richie
2005-10-11, 22:57
> It seems like people are pretty happy with performance if they have
> around 350 or less albums in the database. 750 albums or more is about
> the place where no one seems satisfied with performance. Between those
> quantities satisfaction varies quite a bit. I could easily have missed
> posts to the contrary.

I've well over 1000 albums on a 1.4 GHz Athlon. Performance is absolutely fine.

Richard

Dan Sully
2005-10-11, 23:00
* Richie shaped the electrons to say...

>> It seems like people are pretty happy with performance if they have
>> around 350 or less albums in the database. 750 albums or more is about
>> the place where no one seems satisfied with performance. Between those
>> quantities satisfaction varies quite a bit. I could easily have missed
>> posts to the contrary.
>
>I've well over 1000 albums on a 1.4 GHz Athlon. Performance is absolutely fine.

1252 albums here, 14k tracks. No issues - 2.2 Ghz Athlon

Also, one of our customers in the UK has 70k tracks, and since the early 6.2
nightlies, we've done a lot of performance work. He was suffering before, but
has no issues now.

-D
--
Minds are like parachutes... they work best when open.

radish
2005-10-11, 23:10
It seems like people are pretty happy with performance if they have around 350 or less albums in the database. 750 albums or more is about the place where no one seems satisfied with performance. Between those quantities satisfaction varies quite a bit. I could easily have missed posts to the contrary.

I have over 800 albums, running on Windows, no problems (as I've stated in many threads). The OS is not the problem - Perl runs just fine on Windows, no more or less performant than any other platform. Now whether Perl would be my language of choice for such a system, well that's another matter - but I don't think it affects performance in any significant way. You also need to decide what you're optimizing for - memory usage, response time, or cpu usage. Pick one (or if you're lucky, two). Personally I have no problem with CPU or memory usage in SlimServer - most people's complaints seem to be response time.

I personally suspect that adding some threading would help, as it does whenever you have blocking I/O and a mixture of event and non-event driven processing. However, I wouldn't do any work on it without much more evidence that that. We need to configure a system to breaking point and find out what's going on inside. I don't know what the current state of the art w.r.t Perl live debugging and analysis tools is, I'm a Java/C# man, but that kind of info is essential in this type of exercise. Blind optimization (i.e. looking for things which might be slow and rewriting them in a way which might be faster - or might not be) is a huge waste of time and resources and almost never fixes anything useful.

Michaelwagner
2005-10-11, 23:23
I personally suspect that adding some threading would help
Likely true, but as you say, needs more analysis and better tools before committing resources to it.

Blind optimization (i.e. looking for things which might be slow and rewriting them in a way which might be faster - or might not be) is a huge waste of time and resources and almost never fixes anything useful.
Agreed.
Does perl have a profiler?
I assume it has some cute name like pp (perl profiler)?

Michaelwagner
2005-10-11, 23:39
my stats: 548 albums, 8390 songs, 2251 artists.
1.8GHz P4 512MB RAM W2K SP4 200GB in 2 hard disks.
dual monitor (doubt that effects anything, though).

All I need to do to make it stutter is "clear library before rescan" followed by clicking the rescan button. If you turn on buffer fullness display you can see it draining the buffer because it doesn't pay enough attention to the streaming.

Dan Sully
2005-10-11, 23:51
* Michaelwagner shaped the electrons to say...

>> Blind optimization (i.e. looking for things which might be slow and
>> rewriting them in a way which might be faster - or might not be) is a
>> huge waste of time and resources and almost never fixes anything
>> useful.
>
>Agreed.
>Does perl have a profiler?
>I assume it has some cute name like pp (perl profiler)?

Perl has multiple profilers available.

http://search.cpan.org/search?query=devel%3A%3Aprofile&mode=all

-D
--
<dr.pox> do they call it 'gq' because it makes your text fashionable?

Patrick Dixon
2005-10-12, 01:09
Personally I have no problem with CPU or memory usage in SlimServer - most people's complaints seem to be response time.

I personally suspect that adding some threading would help, as it does whenever you have blocking I/O and a mixture of event and non-event driven processing. However, I wouldn't do any work on it without much more evidence that that. We need to configure a system to breaking point and find out what's going on inside.
See http://bugs.slimdevices.com/show_bug.cgi?id=2081

I personally think it is essential to improve the remote response times: I don't mind waiting for a search or browse function providing I'm aware that something is going on; but getting no response at all is both confusing and frustrating.

I also think it would be useful to be able to cancel tasks that are taking too long: I seem to regularly accidentally ask the server to play 'everything' (I'm pretty stupid, I know), and my server literally goes away for minutes! It's usually quicker for me to ssh in and restart slimserver than wait for it to come back of it's own accord.

ModelCitizen
2005-10-12, 01:46
See http://bugs.slimdevices.com/show_bug.cgi?id=2081
I also think it would be useful to be able to cancel tasks that are taking too long: I seem to regularly accidentally ask the server to play 'everything' (I'm pretty stupid, I know), and my server literally goes away for minutes! It's usually quicker for me to ssh in and restart slimserver than wait for it to come back of it's own accord.
I completely agree with Patricks comments.
I don't understand why, for me, most of the browse functions work well while some almost always crash the music and leave me waiting.
I'd be very glad if someone above who stated that SlimServer performance was acceptable on a (preferably not hugely specced) Windows machine could use the *remote* to call up Browse Genres > A Genre With a Lot of Albums > All Albums, and let me know if performance is fine with this menu choice.

Unfortunately this is a favourite menu choice of mine but I cannot use it at all.

MC

mherger
2005-10-12, 02:11
> I'd be very glad if someone above who stated that SlimServer
> performance was acceptable on a (preferably not hugely specced) Windows
> machine could use the *remote* to call up Browse Genres > A Genre With a
> Lot of Albums > All Albums, and let me know if performance is fine with
> this menu choice.

What's "a Lot of Albums"? 100? 1000?

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
SlimString Translation Helper (http://www.herger.net/slim/)

Patrick Dixon
2005-10-12, 03:17
I don't understand why, for me, most of the browse functions work well while some almost always crash the music and leave me waiting.I don't actually think you are crashing the server (I'm running from svn, the server is up 24/7 and I haven't had a crash for ages - so it's very robust these days); SS is just going away to build the list you've requested from the dB. I think there's also some caching going on, which is probably why it seems slower the first time you do it.

I have 900+ albums on my very low spec server (but I'm generally only using one SB2 at a time) so I think it's unfair to expect instant responses for time consuming tasks (like dB searches). The SS equilvalent of the hourglass would be fine as far as I'm concerned. I just hate the 'no busses for ages and then 15 turn up at once' approach of the current code!

Robin Bowes
2005-10-12, 04:47
Music Machine said the following on 11/10/2005 23:13:
> Two cents from the Peanut Gallery
>
> It seems like people are pretty happy with performance if they have
> around 350 or less albums in the database. 750 albums or more is about
> the place where no one seems satisfied with performance. Between those
> quantities satisfaction varies quite a bit. I could easily have missed
> posts to the contrary.

My slimserver installation is currently reporting:

1273 albums with 12943 songs by 529 artists

I run Fedora Core 4 Linux on a (dual) P3 1GHz processor with 1.5GB RAM.
This box is also my mail server, web server, database server, samba
server, etc. I also use a MySQL backend and always run the latest dev.
code from svn trunk.

Normal operation is fine. In fact, I've never had any *real* problems
with slimserver.

However, the current architecture is such that any blocking operation
will interrupt audio streaming if it blocks for long enough.

As Model Citizen rightly says, I have been advocating breaking the code
up into separate processes or threads for sometime. I have also
discussed this at some length with Dan.

Unfortunately, I'm not in a position to contribute much time/effort to
developing code at the moment and the Slim team are even more busy so
the initiative is on the back-burner.

> On the surface it looks like data handling is the bottleneck, not
> processing power.

It's more about spreading the processing power between the necessary
processes. The core "real-time" processes need to run uninterrupted,
e.g. audio streaming, display update, response to remote, etc. Other
stuff, like playlist management, scanning, etc. need as much CPU as
possible but without interrupting the core processes. This would be
easier to achieve with a multi-process/thread architecture.

R.
--
http://robinbowes.com

If a man speaks in a forest,
and his wife's not there,
is he still wrong?

Michaelwagner
2005-10-12, 06:22
However, the current architecture is such that any blocking operation will interrupt audio streaming if it blocks for long enough.
From looking at the code, it seems that perl has no built-in interrupt handling or dispatching, and that all dispatching is being handled by hand-written code. So the operation doesn't have to block, it just has to call some subroutine that takes a while (like an sql call), and that's all she wrote.


It's more about spreading the processing power between the necessary processes. The core "real-time" processes need to run uninterrupted, e.g. audio streaming, display update, response to remote, etc. Other stuff, like playlist management, scanning, etc. need as much CPU as possible but without interrupting the core processes. This would be easier to achieve with a multi-process/thread architecture.
Multi-process/multi-thread is fairly complex and this isn't the right language. But 2 process/thread is more achievable, given the tools and the language, and I believe adequate to the task at hand. It won't solve the problem that 14 people in a library pounding away at the web interface will get lousy response, but that's not really the intended use.

A separate perl low-level routine that just kept the active clients fed with music and display information and serviced remote control keyclicks (all the time-critical stuff) would actually simplify all the rest of the code, which then wouldn't have to mess with timers and "make sure I don't do too much" code. And it could serve as the model for a rewrite in C down the road.

radish
2005-10-12, 06:49
And it could serve as the model for a rewrite in C down the road.
I thought we were supposed to be improving things? :)

Robin Bowes
2005-10-12, 06:53
Michaelwagner said the following on 12/10/2005 14:22:
> Robin Bowes Wrote:
>
>>However, the current architecture is such that any blocking operation
>>will interrupt audio streaming if it blocks for long enough.
>
>>From looking at the code, it seems that perl has no built-in interrupt
> handling or dispatching, and that all dispatching is being handled by
> hand-written code. So the operation doesn't have to block, it just has
> to call some subroutine that takes a while (like an sql call), and
> that's all she wrote.

Exactly. But that relies on everyone writing code for slimserver to
yield regularly if their code take any length of time to execute.

>>It's more about spreading the processing power between the necessary
>>processes. The core "real-time" processes need to run uninterrupted,
>>e.g. audio streaming, display update, response to remote, etc. Other
>>stuff, like playlist management, scanning, etc. need as much CPU as
>>possible but without interrupting the core processes. This would be
>>easier to achieve with a multi-process/thread architecture.
>
> Multi-process/multi-thread is fairly complex and this isn't the right
> language. But 2 process/thread is more achievable, given the tools and
> the language, and I believe adequate to the task at hand. It won't
> solve the problem that 14 people in a library pounding away at the web
> interface will get lousy response, but that's not really the intended
> use.

Language is irrelevant. multi-process/multi-thread systems can be
written in pretty much any language. qpsmtpd is an example of a program
written in perl that can multi-task and handle high loads.

> A separate perl low-level routine that just kept the active clients fed
> with music and display information and serviced remote control keyclicks
> (all the time-critical stuff) would actually simplify all the rest of
> the code, which then wouldn't have to mess with timers and "make sure I
> don't do too much" code. And it could serve as the model for a rewrite
> in C down the road.

I don't think a re-write in C would help - that's analogous to throwing
hardware horsepower at the problem.

If the core code is broken out into separate threads/processes with
clearly defined interfaces then each process can be written in whatever
language you like. I think each core element of the code should have its
own process/thread rather than just one as you suggest. 6 processes
would be not much harder to implement than 2.

R.
--
http://robinbowes.com

If a man speaks in a forest,
and his wife's not there,
is he still wrong?

Michaelwagner
2005-10-12, 07:17
If the core code is broken out into separate threads/processes with clearly defined interfaces then each process can be written in whatever language you like. I think each core element of the code should have its own process/thread rather than just one as you suggest. 6 processes
would be not much harder to implement than 2.

In theory I agree with you.

In practice, I was looking at what is practical and achieveable in a short time and with limited staff resources. I wasn't advocating writing our own generalized scheduler/dispatcher. I was advocating running 2 copies of perl, one with the time-critical stuff, one with the rest. And prioritize the time-critical one higher. Let the operating system dispatch the two of them.

You don't want to have 6 because you don't want 6 operating system processes running.

Michael

ModelCitizen
2005-10-12, 07:42
[QUOTE=mherger]> I'd be very glad if someone above who stated that SlimServer
> performance was acceptable on a (preferably not hugely specced) Windows
> machine could use the *remote* to call up Browse Genres > A Genre With a
> Lot of Albums > All Albums, and let me know if performance is fine with
> this menu choice.
What's "a Lot of Albums"? 100? 1000?

Michael, a mere 122 under Browse Music > Browse Genres > Ambient > All Albums

MC

mherger
2005-10-12, 08:14
>> What's "a Lot of Albums"? 100? 1000?
>>
>> Michael, a mere 122 under Browse Music > Browse Genres > Ambient > All
>> Albums

This is not huge enough a number to make me understand the delay you
encounter. I have 87 albums in the largest genre I found, and they show up
in about 1-2 seconds on a Via C3/1GHz (Linux, though). Windows XP on a
P4/2.66GHz serves them instantly, no noticeable delay at all.

Not much of help, I guess, but you wanted numbers :-)

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
SlimString Translation Helper (http://www.herger.net/slim/)

Robin Bowes
2005-10-12, 08:27
Michaelwagner said the following on 12/10/2005 15:17:
> Robin Bowes Wrote:
>
>>If the core code is broken out into separate threads/processes with
>>clearly defined interfaces then each process can be written in whatever
>>language you like. I think each core element of the code should have its
>>own process/thread rather than just one as you suggest. 6 processes
>>would be not much harder to implement than 2.
>
>
> In theory I agree with you.
>
> In practice, I was looking at what is practical and achieveable in a
> short time and with limited staff resources. I wasn't advocating
> writing our own generalized scheduler/dispatcher. I was advocating
> running 2 copies of perl, one with the time-critical stuff, one with
> the rest. And prioritize the time-critical one higher. Let the
> operating system dispatch the two of them.

I'm not necessarily advocating writing our own scheduling code - that's
what the operating system is for!

> You don't want to have 6 because you don't want 6 operating system
> processes running.

Why not? If there is a need for 6 processes then why not have 6
operating system processes?

Some of the best software I use is written by djb (http://cr.yp.to).
Daemontools, ucspi-tcp, qmail, etc. Lots of small programs that do a
specific task well. YOu get the functionality by chaining the processes
together, e.g. to start the qmail smtp listener you use something like:

exec /usr/local/bin/softlimit -m 3000000 \
/usr/local/bin/tcpserver -v -R -l "$LOCAL" \
-x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 \
smtp /var/qmail/bin/qmail-smtpd 2>&1

That's softlimit running tcpserver (which handles the tcp
communications) running qmail-smtpd.

Logging is done by piping the output of this process to yet another process.

If slimserver were written in a similar way it would make development
and maintenance much easier.

R.
--
http://robinbowes.com

If a man speaks in a forest,
and his wife's not there,
is he still wrong?

Richie
2005-10-12, 08:58
> I'd be very glad if someone above who stated that SlimServer
> performance was acceptable on a (preferably not hugely specced) Windows
> machine could use the *remote* to call up Browse Genres > A Genre With a
> Lot of Albums > All Albums, and let me know if performance is fine with
> this menu choice.
>
> Unfortunately this is a favourite menu choice of mine but I cannot use
> it at all.
>
> MC

If I choose Browse Music > Browse Genres > Rock > All Albums from the
Squeezebox2 using the remote, the list appears with no detectable (< 1
second) delay. There are 513 albums in this genre. Using SS6.2
nightlies on Win XP SP2 with an Athlon 1.4GHz with 768MB RAM.

Richard

ModelCitizen
2005-10-12, 09:15
If I choose Browse Music > Browse Genres > Rock > All Albums from the Squeezebox2 using the remote, the list appears with no detectable (< 1 second) delay. There are 513 albums in this genre. Using SS6.2 nightlies on Win XP SP2 with an Athlon 1.4GHz with 768MB RAM.
RichardThanks for this. If it's not too much trouble, could either you or Michael tell me if the listing renders as fast if it is the first menu you navigate to after you've stopped and started SlimServer, or even, if there is any noticeable time difference at all? I can't see why this should make a difference but it appears as if it might for me. It'd be useful if you say which version off SS you are using too, as I have just been told that the latest 6.2 nighlies (or 6.2 beta) have improved code in it. I am using the stable (maintenance?) 6.1.2 release.
Thanks
MC

Richie
2005-10-12, 09:31
> > If I choose Browse Music > Browse Genres > Rock > All Albums from the
> > Squeezebox2 using the remote, the list appears with no detectable (< 1
> > second) delay. There are 513 albums in this genre. Using SS6.2
> > nightlies on Win XP SP2 with an Athlon 1.4GHz with 768MB RAM.
> > RichardIf it's not too much trouble, could either you or Michael tell me if the
> listing renders as fast if it is the first menu you navigate to after
> you've stopped and started SlimServer, or even, if there is any
> noticeable time difference at all? I can't see why this should make a
> difference but it appears as if it might for me.
> Thanks
> MC

I just tried it, stopped slimserver, restarted and the response was
just as quick. I couldn't tell any difference.

Richard

Dan Sully
2005-10-12, 11:07
* ModelCitizen shaped the electrons to say...

>I don't understand why, for me, most of the browse functions work well
>while some almost always crash the music and leave me waiting.
>I'd be very glad if someone above who stated that SlimServer
>performance was acceptable on a (preferably not hugely specced) Windows
>machine could use the *remote* to call up Browse Genres > A Genre With a
>Lot of Albums > All Albums, and let me know if performance is fine with
>this menu choice.

If I recall, in a previous thread (or maybe this one), you said that you were
running 6.1.x. Please upgrade to the 6.2 nightlies - the browse genres issue
has been fixed there.

-D
--
<nil> It sucks to discover that you are the foremost authority on some set of things when you've got a problem.

Free Lunch
2005-10-12, 13:33
On 10/12/05, Patrick Dixon
<Patrick.Dixon.1ws52n (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
> I also think it would be useful to be able to cancel tasks that are
> taking too long: I seem to regularly accidentally ask the server to
> play 'everything' (I'm pretty stupid, I know), and my server literally
> goes away for minutes! It's usually quicker for me to ssh in and
> restart slimserver than wait for it to come back of it's own accord.

That isn't stupid. Stupid is not being able to do that.


FL

ModelCitizen
2005-10-12, 15:04
If I recall, in a previous thread (or maybe this one), you said that you were running 6.1.x. Please upgrade to the 6.2 nightlies - the browse genres issue has been fixed there.
-DDid that. And updated firmware. Slimserver took more than three seconds to respond to any request via the remote with the new version. Since then I have been trying to revert to my previous SS version, without success so far (lots of Squeezebox can't find SlimServer).
MC

Triode
2005-10-12, 15:11
>> Did that. And updated firmware. Slimserver took more than three seconds
>> to respond to any request via the remote with the new version. Since
>> then I have been trying to revert to my previous SS version, without
>> success so far (lots of Squeezebox can't find SlimServer).
>> MC
>

Is this after allowing the server to rescan all of your music (which may take quite a while with a large library). As the database
version changes between releases it is likely that at startup with a new version it needs to rescan the whole library to build a
consitent new database.

I would be interested in seeing what the Server Response Time graph in 6.2 shows after rescanning has completed [in Server and
Network Health].

Jess Askey
2005-10-12, 15:13
I have an under powered machine and here are my delay scenarios...

PII 366 Celeron, 384M RAM, 320gig UDMA-100 driver with PCI UDMA-100
Controller
745 Albums, 12353 Songs
Linux Mandrake 9.2 - BIND9, Postgresql, Slimserver

I have my folders organized in the root music folder like this

Christmas (xmas music only here, don't want it mixed in with my other stuff)
Books (Books on tape, Pimsleur Language Rips, etc)
Elise (Kids music for my daughter)
Music (The master repository of all other music)
Lovewave (my band's music)

I typically play on my squeezebox, the entire 'music' folder shuffled by
song. So..

1. I navigate to 'Browse Music Folder -> Music' and hit 'Play' on my remote.
2. At this point, the sqeezebox freezes for about 45 seconds (CPU on
server is at 98%)
3. The display will show the first song playing but there will be no
music at this point. If I press 'Now Playing' I can see the current song
in the queue labeled as 'Playing' but not... and the song list count is
growing (song 1 of X, where X is increasing as the playlist is being built).
4. At this point, even tho the song is not playing and the Squeezebox
shows it as Playing, I hit Play and the song will then actually play.
5. After about 1-2 minutes of the song playing (playlist still
building), the music generally stops for about 1-5 minutes until the
playlist finishes building and then the song resumes where it halted.

At this point Im quite used to the routine so Im sure to start the
process about 5 minutes before I actually need music. I have been hoping
to upgrade my server but just have not had the time. However, the server
did work just fine with my Audiotron.

I just installed the 6.2 nightly last night to see if anything improved
but I have not been home yet to try. I will report back... Im excited to
hear that 6.2 may improve my delay issues.

MrC
2005-10-12, 15:18
PII 366 Celeron, 384M RAM, 320gig UDMA-100 driver with PCI UDMA-100
Controller
745 Albums, 12353 Songs
Linux Mandrake 9.2 - BIND9, Postgresql, Slimserver

1. I navigate to 'Browse Music Folder -> Music' and hit 'Play' on my remote.
2. At this point, the sqeezebox freezes for about 45 seconds (CPU on
server is at 98%)

Can you say... swapping!

Triode
2005-10-12, 15:21
Jess,

Can I suggest you try the Random Mix plugin that is part of 6.2. This provides an alternative way of randomly playing your music
collection without the performance problem of shuffled play (for long lists)

Goto Plugins->Random Mix and select relavent option and press play.

> I typically play on my squeezebox, the entire 'music' folder shuffled by song. So..
>

Michaelwagner
2005-10-12, 17:55
I'm not necessarily advocating writing our own scheduling code - that's what the operating system is for!
Absolutely.

If there is a need for 6 processes then why not have 6 operating system processes?
At least in the windows case, I'm sure there's a fair overhead to the windows perl support. I know, for instance, that the windows perl implementation creates a directory in temp with a bunch of run-time-compiled code with serialized names. How well this scheme scales is unclear to me. Anyone who has benchmarked it care to comment?

Michael

Michaelwagner
2005-10-12, 17:57
Can you say... swapping!
Yeah, that sounds like more memory, if you can add it easily, might be a quick fix to get out of the problem for now.

However, I think development efforts should be made to print the footprint of slim down so this isn't such a problem.

pfarrell
2005-10-12, 18:15
On Wed, 2005-10-12 at 17:57 -0700, Michaelwagner wrote:
> MrC Wrote:
> > Can you say... swapping!
> Yeah, that sounds like more memory, if you can add it easily, might be
> a quick fix to get out of the problem for now.

More memory is always good.
If you can't add it, change systems.

> However, I think development efforts should be made to print the
> footprint of slim down so this isn't such a problem.

Except that all software always grows as features are added.
I seriously doubt that a wimpy P2 with under 512 MB of ram will ever
again provide acceptable performance. Starter systems these days
have 512, and 1 gig is nothing.

Hardware is very cheap. It is just not a good engineering choice
for one niche product to fight the massive karma of most software.
Sometime soon, the SlimServer will need to be engineered for all
the dual CPU + dual hyperthread processors flowing around entry
level systems by Xmas 2006.

It is hard to develop rich software in limited hardware. The embedded
systems guys to it all the time, but they get paid serious
money to do it. The beauty of the SlimDevices design is that
the specialized hardware is slim and inexpensive, and you just
use any standard PC, Mac or *nix box you have.


--
Pat Farrell
http://www.pfarrell.com

Michaelwagner
2005-10-12, 18:15
I have an under powered machine and here are my delay scenarios...

PII 366 Celeron, 384M RAM, 320gig UDMA-100 driver with PCI UDMA-100 Controller
745 Albums, 12353 Songs
Linux Mandrake 9.2 - BIND9, Postgresql, Slimserver

the server did work just fine with my Audiotron.
One of the things you have to understand is that the Audiotron had it's own processor doing one segment of the work you have now added to this computer. Under the audiotron scenario, the server was just a file server. MP3 tag scanning, and keeping the resulting 'database' was done on the audiotron itself. Also the web server. Under the slim scenario, all of this is now on the processor. Especially during tag scanning, the resource footprint is considerably higher.

After the 6.2 upgrade, if things still need improvement, here are some things to consider:
1. add more memory - if you're running out of memory, it'll swap and add to your I/O load, exactly when you need the I/O to be faster, it'll be slower.
2. check your swapping configuration. I'm not familiar with your operating system, but all O/Ses prefer contiguous fast swap areas.
3. if you can't add more memory, or can't add enough more, consider buying another fast disk (can be much smaller) and dedicate it to swap.

Tell us how it goes ...

Michael

Jess Askey
2005-10-12, 18:21
It actually doesn't bother me that much at this point since the machine
truly is a dog and I woudln't expect slimserver to run very well on it.
Certainly, improvements in slimserver would be nice, but Im a perfectly
happy customer right now. I used to OC the machine to 550Mhz but it
doesn't seem to like that anymore (probably the power supply filter caps
drying out). I just tried my fresh 6.2 Nightly install from last night
and things are actually substantially snappier... no real delays over 1
second at this point so far. So... THANK YOU SLIM TEAM!! (yeah, Im
shouting) :-)



Triode wrote:

> Jess,
>
> Can I suggest you try the Random Mix plugin that is part of 6.2. This
> provides an alternative way of randomly playing your music collection
> without the performance problem of shuffled play (for long lists)
>
> Goto Plugins->Random Mix and select relavent option and press play.
>
>> I typically play on my squeezebox, the entire 'music' folder shuffled
>> by song. So..
>>
>
>

gingerneil
2005-10-12, 23:59
Hmm...
Reading this entire thread has somehow managed to put me off my plans of setting up a linkstation solution when I move house!
Current library is only 251 albums with 3357 songs by 402 artists. Anyone care to comment on how a linkstation might perform with 2 SB2s streaming ??
I VERY rarely use the web interface.

max.spicer
2005-10-13, 05:03
Whenever I've done an upgrade that has forced a server rescan, it's never told me that's what it's going to do. My player becomes totally unresponsive during a rescan, which I imagine would be quite alarming if you didn't know what was going on. It's certainly not the first impression of the new version that you want users to have!

Max


>> Did that. And updated firmware. Slimserver took more than three seconds
>> to respond to any request via the remote with the new version. Since
>> then I have been trying to revert to my previous SS version, without
>> success so far (lots of Squeezebox can't find SlimServer).
>> MC
>

Is this after allowing the server to rescan all of your music (which may take quite a while with a large library). As the database
version changes between releases it is likely that at startup with a new version it needs to rescan the whole library to build a
consitent new database.

I would be interested in seeing what the Server Response Time graph in 6.2 shows after rescanning has completed [in Server and
Network Health].

ModelCitizen
2005-10-13, 06:44
Whenever I've done an upgrade that has forced a server rescan, it's never told me that's what it's going to do. My player becomes totally unresponsive during a rescan, which I imagine would be quite alarming if you didn't know what was going on. It's certainly not the first impression of the new version that you want users to have!
Max Triode was right. I did not realise that a rescan had been forced as the app did not inform me this was going to happen. I know it's been raised before but some sort of progress indicator would be very useful too.
MC

max.spicer
2005-10-13, 07:43
At the very least, it needs to be made very obvious to the user via release notes and, preferably, a large bit of text next to the download link! I wonder how many people have tried a 6.2 build, noticed the slow performance, assumed that that was what they should expect from 6.2 and so given up?

Max


Triode was right. I did not realise that a rescan had been forced as the app did not inform me this was going to happen. I know it's been raised before but some sort of progress indicator would be very useful too.
MC

Michaelwagner
2005-10-13, 08:03
I think the hope was that scanning would improve and this would not be necessary. I know they are trying to improve scanning performance. But in the mean time, I think a message, on the unit as well as at the web interface, that scanning is occurring, would be a very wise thing. I'm sure people have been ticked off by it, because, as several people have pointed out, it's part of the first impression.

Triode
2005-10-13, 12:03
As a suggestion - how about the welcome screen showing something differerent when a player is turned on and the server is scanning?

>
> At the very least, it needs to be made very obvious to the user via
> release notes and, preferably, a large bit of text next to the download
> link! I wonder how many people have tried a 6.2 build, noticed the slow
> performance, assumed that that was what they should expect from 6.2 and
> so given up?
>
> Max
>
> ModelCitizen Wrote:
>> Triode was right. I did not realise that a rescan had been forced as the
>> app did not inform me this was going to happen. I know it's been raised
>> before but some sort of progress indicator would be very useful too.
>> MC

ModelCitizen
2005-10-13, 12:12
Yehaaaaaah!
6.2 has sorted my problems. I'be been playing with SS for about 2 hours now and am really impressed. Now I can browse all menus perfectly quickly using the remote and all seems to be going very, very well indeed. I'd just like to say a huge great thank you to the people who worked to get this going. This really has made my decade!

Just for those who might think that SlimServer needs a large amount of hardware, this is the current spec for my dedicated (and so far very stable) SlimServer laptop:

Dell Latitude 500 Mhz P3, 192mb RAM.
Windows XP Home SP2 (fresh install) - all extraneous Windows stuff uninstalled or turned off, generally slimmed down as much as possible, disabled all unused hardware and services, only runs SlimServer, priority given to background services, no firewall, no virus checkers, no software, no power saving, defragged before placing in draw and forgetting about it).

Total machine RAM usage (Commit Charge) is stable at 113mb. Processor usage during playing hovers between 3% and 6%. However processor usage jumps to 100% when I choose a big menu item (i.e. Genres > Ambient > All Albums, which holds 155 flac albums) but does this for less than a second and then the menu displays (i.e pretty instant in my book).
All music is flac. Squeezebox2 is currently wired.
Library stats: 817 albums with 9086 songs by 1200 artists
Music is held in Maxtor OneTouch 300gb USB drive via USB 1.

Ha ha. I can't believe how happy I am! At last I can sell the Naim CDX!
---------------------------------------------

Triode. I ran Server and Network Health as you asked. Here is the output. It's not perfect but doesn't appear worrying. I wonder how much running the web interface and the annoying refresh on the laptop server influenced the figures (I've just realised that there was also a second instance of the web interface open on my network at the time)? I ran it for about three quarters of an hour.

Player Performance : Squeezebox2
The graphs shown here record the long term trend for each of the player performance measurements below. They display the number and percentage of measurements which fall within each measurement band.
It is imporant to leave the player playing for a while and then assess the graphs.

Buffer Fullness
This graph shows the fill of the player's buffer. Higher buffer fullness is better. Note the buffer is only filled while the player is playing tracks.
Squeezebox1 uses a small buffer and it is expected to stay full while playing. If this value drops to 0 it will result in audio dropouts. This is likely to be due to network problems.

Squeezebox2 uses a large buffer. This drains to 0 at the end of each track and then refills for the next track. You should only be concerned if the buffer fill is not high for the majority of the time a track is playing.

Playing remote streams can lead to low buffer fill as the player needs to wait for data from the remote server. This is not a cause for concern.

< 10 : 47 : 2% #
< 20 : 1 : 0%
< 30 : 3 : 0%
< 40 : 2 : 0%
< 50 : 1 : 0%
< 60 : 4 : 0%
< 70 : 7 : 0%
< 80 : 4 : 0%
< 90 : 7 : 0%
< 100 : 2151 : 97% ################################################
>=100 : 0 : 0%
max : 99.999968
min : 0.000000
avg : 97.271767

Control Connection
This graph shows the number of messages queued up to send to the player over the control connection. A measurement is taken every time a new message is sent to the player. Values above 1-2 indicate potential network congestion or that the player has become disconnected.
< 1 : 28 :100% ##################################################
< 2 : 0 : 0%
< 5 : 0 : 0%
< 10 : 0 : 0%
< 20 : 0 : 0%
>=20 : 0 : 0%
max : 0.000000
min : -1.000000
avg : -0.035714


--------------------------------------------------------------------------------

Server Performance
The graphs shown here record the long term trend for each of the server performance measurements below. They display the number and percentage of measurements which fall within each measurement band.
Server Response Time
This graph shows the length of time between slimserver responding to requests from any player. It is measured in seconds. Lower numbers are better. If you notice response times of over 1 second this could lead to problems with audio performance.
The cause of long response times could be either other programs running on the server or slimserver processing a complex task.

< 0.002 : 31298 : 75% #####################################
< 0.005 : 7096 : 17% ########
< 0.01 : 112 : 0%
< 0.015 : 2368 : 6% ##
< 0.025 : 269 : 1%
< 0.05 : 35 : 0%
< 0.1 : 248 : 1%
< 0.5 : 175 : 0%
< 1 : 10 : 0%
< 5 : 12 : 0%
>=5 : 1 : 0%
max : 10.112766
min : -0.008646
avg : 0.004213

Timer Accuracy
Slimserver uses a timer mechanism to trigger events such as updating the user interface. This graph shows how accurately each timer task is run relative to the time it was intended to be run. It is measured in seconds.
Timer tasks are scheduled by the server to run at some point in the future. As only one timer task can run at once and the server may also be performing other activity, timer tasks always run slightly after the time they are scheduled for. However if timer tasks run significantly after they are scheduled this can become noticable through delay in the user interface.

< 0.002 : 1762 : 36% #################
< 0.005 : 1163 : 24% ###########
< 0.01 : 1745 : 35% #################
< 0.015 : 110 : 2% #
< 0.025 : 32 : 1%
< 0.05 : 19 : 0%
< 0.1 : 29 : 1%
< 0.5 : 44 : 1%
< 1 : 5 : 0%
< 5 : 18 : 0%
>=5 : 2 : 0%
max : 14.130860
min : 0.000001
avg : 0.020217

Timer Task Duration
This graph shows how long each timer task runs for. It is measured in seconds. If any timer task takes more than 0.5 seconds this is likely to impact the user interface.
< 0.002 : 2528 : 51% #########################
< 0.005 : 0 : 0%
< 0.01 : 5 : 0%
< 0.015 : 2362 : 48% #######################
< 0.025 : 18 : 0%
< 0.05 : 3 : 0%
< 0.1 : 0 : 0%
< 0.5 : 13 : 0%
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.296342
min : 0.000193
avg : 0.006775

---------------------------------------------------

Again. THANKS!!!!
Whoooooooooooooooo!

MC

Triode
2005-10-13, 12:27
> Triode. I ran Server and Network Health as you asked. Here is the
> output. It's not perfect but doesn't appear worrying. I wonder how much
> running the web interface and the annoying refresh on the laptop server
> influenced the figures (I've just realised that there was also a second
> instance of the web interface open on my network at the time)? I ran it
> for about three quarters of an hour.
>

Server looks healthy to me. Something happened once which took 10 seconds to complete, but as it is a once off I would say there is
nothing to worry about. [especially as you had two browser sessions open.]

Enjoy 6.2 ...

Free Lunch
2005-10-17, 18:35
Encouraged by the news that recent 6.2 nightly builds solved
performance issues, I tried the 10-12 nightly with my original
Slimp3.. Unfortunately, it was much worse than 5.4.1 with my 48K
track library.

Playback would stop as soon as I tried to access the main web
interface. Menu navigation also caused drop outs. This was while I
was playing FLAC files (so it would be transcoding). The server runs
on a dedicated linux box (XP2200 with 512MB). I did wait for the
rescan to complete.

So, back to 5.4.1... again... :-(
(which wouldn't run until I restored my original config files).

I've wanted to buy a squeezebox for a long while.. But it is hard to
do when 6.x doesn't work with my slimp3.

mherger
2005-10-17, 23:23
> Playback would stop as soon as I tried to access the main web
> interface. Menu navigation also caused drop outs. This was while I
> was playing FLAC files (so it would be transcoding). The server runs
> on a dedicated linux box (XP2200 with 512MB). I did wait for the
> rescan to complete.

This is definetly not normal behaviour. While most of my collection is MP3
I'm happily running slimserver on such low spec machines as a Via C3/600
to feed real streams to my SliMP3 - running mplayer -> lame transcoding.

Do you have some more details about what exactly you did when you
encountered the drop outs? What page? What menu on the player? etc. With
no information about problems there won't be a fix.

> I've wanted to buy a squeezebox for a long while.. But it is hard to
> do when 6.x doesn't work with my slimp3.

You could expect much better performance from a SB2 for at least two
important reasons: native FLAC support (no transcoding needed) and a huge
buffer memory.

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
SlimString Translation Helper (http://www.herger.net/slim/)

max.spicer
2005-10-17, 23:56
The first thing that 6.2 will do is trigger a full rescan of your collection. Whilst this is taking place, the performance will likely be terrible. However, if you let it get on with it and give it time to complete (probably a lot of time with that many tracks!), things should soon become nice and fast. There really needs to be a warning that this rescan is happening - if you don't use the web interface, you're none the wiser. Fortunately, the number of situations that will require another full rescan are getting fewer and fewer.

Max


Encouraged by the news that recent 6.2 nightly builds solved
performance issues, I tried the 10-12 nightly with my original
Slimp3.. Unfortunately, it was much worse than 5.4.1 with my 48K
track library.

Playback would stop as soon as I tried to access the main web
interface. Menu navigation also caused drop outs. This was while I
was playing FLAC files (so it would be transcoding). The server runs
on a dedicated linux box (XP2200 with 512MB). I did wait for the
rescan to complete.

So, back to 5.4.1... again... :-(
(which wouldn't run until I restored my original config files).

I've wanted to buy a squeezebox for a long while.. But it is hard to
do when 6.x doesn't work with my slimp3.

Michaelwagner
2005-10-18, 07:00
There is a server performance option about how many songs to do in a block (or some such wording). I was hoping it would make scanning performance better (or at least more disciplined). If it had an effect it was lost on me.