OK here goes..
Setup.
2 SB2's wired and 1 SB1 wireless
Cisco AP-350
Dell 3024 Sw
Sun Enterprise 3000 - 6 250Mhz Ultra Sparc - 3 gig mem.
10 73 gig scsi Seagate barracuda 16meg cache, Soft Raid 5.
600gig MP3 store/250gigs Mp3 - 40,000 songs
perl 5.8.5
lame 3.96.1
Slimserver 7-31 nightly
Solaris 10
90% of hardware was "in stock" before I got into Slim.
Up til the 6.1 release the web interface was pretty slow and browsing
folders was also very painful especially when entering a directory with
a large number of subdirectories. However I had not had any problems
with drop outs with the exception of some wireless issues that were
taken care of.
With the latest releases the response from the SqueeezeBoxen is almost
instantaneous and the Web UI is also greatly accelerated. Granted if I
go apesh*t with the remote it will eventually choke for a second or 5
but after that it goes back to normal and zips through the menus with
the exception of Playlist and maybe search but I can't say for sure
cause I don't use search. I'm at work right now streaming from home at
64K, SSH'd to the server and FTPing a 215meg Mp3 to the same volume that
my MP3's are stored and it has only dropped once for a few
seconds(network issue). At work I'm on a single T-1 that is shared by
300 other people and at home I have a basic 384/1.5 DSL. At home I can't
remember ever having a drop out where the server was at fault.
I often sync all 3 players as well as playing different streams on each
player. I also stream to work pretty much 24hours a day and its always
nice to come to work in the morning at hear that the music is still
playing day after day. Also faithful alarm clock. Except for that one
morning with the new release, playlist problem, now I make sure(at
night) that the alarm still works after upgrading.
Process stats current
When just streaming to one player remotely (xmms) -> 1.1%
When streaming to one player with WebUI open 2-5%
When rescanning 15-20% - players are slow to respond but no drop outs.
LAME is at about 4-5% when streaming remotely.
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
13097 root 4128K 3008K sleep 20 0 0:10:03 5.0% lame/1
13106 wr420 8928K 3320K sleep 43 0 0:02:42 2.8% sshd/1
11058 root 76M 72M sleep 59 0 15:22:09 1.1%
slimserver.pl/1
13107 wr420 3288K 1976K sleep 59 0 0:00:16 0.3% sftp-server/1
13136 wr420 4768K 4440K cpu10 59 0 0:00:03 0.2% prstat/1
13130 wr420 8160K 2824K sleep 59 0 0:00:00 0.0% sshd/1
461 root 8440K 3496K sleep 59 0 0:17:59 0.0% dtgreet/1
416 root 12M 6904K sleep 59 0 0:16:55 0.0% Xsun/1
105 root 4272K 2944K sleep 59 0 0:03:46 0.0% nscd/25
10931 root 3632K 2120K sleep 59 0 0:01:05 0.0% nmbd/1
182 root 2296K 1056K sleep 100 - 0:05:53 0.0% xntpd/1
7 root 8384K 1408K sleep 59 0 0:03:56 0.0% svc.startd/12
380 root 1992K 192K sleep 59 0 0:00:00 0.0% smcboot/1
322 root 3808K 2016K sleep 59 0 0:00:06 0.0% syslogd/13
214 root 2120K 664K sleep 59 0 0:00:01 0.0% ttymon/1
99 root 2520K 8K sleep 59 0 0:00:00 0.0% syseventd/15
199 daemon 2584K 272K sleep 59 0 0:00:00 0.0% rpcbind/1
109 daemon 4296K 1840K sleep 59 0 0:00:09 0.0% kcfd/3
213 root 4992K 952K sleep 59 0 0:01:03 0.0% inetd/4
215 root 2080K 144K sleep 59 0 0:00:00 0.0% ttymon/1
202 daemon 2840K 272K sleep 59 0 0:00:00 0.0% statd/1
Total: 56 processes, 160 lwps, load averages: 0.41, 0.41, 0.40
>
> 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
The information contained in this e-mail is strictly confidential and for the
intended use of the addressee only; it may also be legally privileged and/or
price sensitive. Notice is hereby given that any disclosure, use or copying
of the information by anyone other than the intended recipient is prohibited
and may be illegal. If you have received this message in error, please
notify the sender immediately by return e-mail. All e-mail sent to this
address will be received by Acacia Pacific Holding's e-mail system and is
subjected to archiving and review by someone other than the recipient.
Acacia Pacific Holdings has taken every reasonable precaution to ensure that
any attachment to this e-mail has been swept for viruses. We accept no
liability for any damage sustained as a result of software viruses and
advise you carry out your own virus checks before opening any attachment.
_______________________________________________
Discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
