PDA

View Full Version : Slim Devices SB2 disappointment & SB for sale.



Jason
2005-03-16, 09:38
The overwhelming majority of users do not seem to have the problems you have
with the server crashing or grinding to a halt.

It sounds like it might be worth your time to try Slimserver on another
machine.

> -----Original Message-----
> From: discuss-bounces (AT) lists (DOT) slimdevices.com
> [mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Phil Karn
> Sent: Wednesday, March 16, 2005 9:37 AM
> To: Slim Devices Discussion
> Subject: [slim] Slim Devices SB2 disappointment & SB for sale.
>
> Danny Rego wrote:
>
> > Ummm...as does Windows XP (although the more geek-sided may
> refuse to
> > believe that)....what's your point?
>
> Slimserver is open source, so Linux is the closer analogue.
> Windows XP is 1) proprietary and 2) owned by Microsoft, so it
> has its excuses for being so unreliable.
>
> > Making slim server less user-friendly/ugly would be a very
> dumb move.
> > Besides, after a bit of tweaking off the bat, slimserver runs
> > reliably, unless you are one that enjoys downloading the latest
> > nightlies...then you're asking for it.
>
> Little is less user friendly than a massive package of Perl
> code that crashes frequently in a mass of cryptic Perl error
> messages. Or just grinds slowly to a halt for no apparent
> reason, gobbling all CPU time until it has to be restarted manually.
>
> This is on a Linux machine with ECC memory and RAID disks
> that otherwise runs flawlessly for months. So it's not hardware.
>
> > v5.4.1 runs beautifully on my Windows XP machine...so on a decent
> > linux machine, I would only imagine how smooth it would run.
>
> I see various nightly versions of 5.4.x, but nothing
> officially labeled 5.4.1. If this is supposed to be the most
> stable release, recommended for those that want reliability
> over features, it should be labeled and distributed as such.
>

Patrick Delamere
2005-03-16, 09:52
I'd ditto that. My Slimserver runs flawlessly 24/7.

Patrick



Jason wrote:

>The overwhelming majority of users do not seem to have the problems you have
>with the server crashing or grinding to a halt.
>
>It sounds like it might be worth your time to try Slimserver on another
>machine.
>
>
>
>>-----Original Message-----
>>From: discuss-bounces (AT) lists (DOT) slimdevices.com
>>[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Phil Karn
>>Sent: Wednesday, March 16, 2005 9:37 AM
>>To: Slim Devices Discussion
>>Subject: [slim] Slim Devices SB2 disappointment & SB for sale.
>>
>>Danny Rego wrote:
>>
>>
>>
>>>Ummm...as does Windows XP (although the more geek-sided may
>>>
>>>
>>refuse to
>>
>>
>>>believe that)....what's your point?
>>>
>>>
>>Slimserver is open source, so Linux is the closer analogue.
>>Windows XP is 1) proprietary and 2) owned by Microsoft, so it
>>has its excuses for being so unreliable.
>>
>>
>>
>>>Making slim server less user-friendly/ugly would be a very
>>>
>>>
>>dumb move.
>>
>>
>>>Besides, after a bit of tweaking off the bat, slimserver runs
>>>reliably, unless you are one that enjoys downloading the latest
>>>nightlies...then you're asking for it.
>>>
>>>
>>Little is less user friendly than a massive package of Perl
>>code that crashes frequently in a mass of cryptic Perl error
>>messages. Or just grinds slowly to a halt for no apparent
>>reason, gobbling all CPU time until it has to be restarted manually.
>>
>>This is on a Linux machine with ECC memory and RAID disks
>>that otherwise runs flawlessly for months. So it's not hardware.
>>
>>
>>
>>>v5.4.1 runs beautifully on my Windows XP machine...so on a decent
>>>linux machine, I would only imagine how smooth it would run.
>>>
>>>
>>I see various nightly versions of 5.4.x, but nothing
>>officially labeled 5.4.1. If this is supposed to be the most
>>stable release, recommended for those that want reliability
>>over features, it should be labeled and distributed as such.
>>

Patrick Delamere
2005-03-16, 09:54
Maybe I should also mention that I run SuSE Linux 9.2..............

Patrick Delamere wrote:

> I'd ditto that. My Slimserver runs flawlessly 24/7.
>
> Patrick
>
>
>
> Jason wrote:
>
>>The overwhelming majority of users do not seem to have the problems you have
>>with the server crashing or grinding to a halt.
>>
>>It sounds like it might be worth your time to try Slimserver on another
>>machine.
>>
>>
>>
>>>-----Original Message-----
>>>From: discuss-bounces (AT) lists (DOT) slimdevices.com
>>>[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Phil Karn
>>>Sent: Wednesday, March 16, 2005 9:37 AM
>>>To: Slim Devices Discussion
>>>Subject: [slim] Slim Devices SB2 disappointment & SB for sale.
>>>
>>>Danny Rego wrote:
>>>
>>>
>>>
>>>>Ummm...as does Windows XP (although the more geek-sided may
>>>>
>>>>
>>>refuse to
>>>
>>>
>>>>believe that)....what's your point?
>>>>
>>>>
>>>Slimserver is open source, so Linux is the closer analogue.
>>>Windows XP is 1) proprietary and 2) owned by Microsoft, so it
>>>has its excuses for being so unreliable.
>>>
>>>
>>>
>>>>Making slim server less user-friendly/ugly would be a very
>>>>
>>>>
>>>dumb move.
>>>
>>>
>>>>Besides, after a bit of tweaking off the bat, slimserver runs
>>>>reliably, unless you are one that enjoys downloading the latest
>>>>nightlies...then you're asking for it.
>>>>
>>>>
>>>Little is less user friendly than a massive package of Perl
>>>code that crashes frequently in a mass of cryptic Perl error
>>>messages. Or just grinds slowly to a halt for no apparent
>>>reason, gobbling all CPU time until it has to be restarted manually.
>>>
>>>This is on a Linux machine with ECC memory and RAID disks
>>>that otherwise runs flawlessly for months. So it's not hardware.
>>>
>>>
>>>
>>>>v5.4.1 runs beautifully on my Windows XP machine...so on a decent
>>>>linux machine, I would only imagine how smooth it would run.
>>>>
>>>>
>>>I see various nightly versions of 5.4.x, but nothing
>>>officially labeled 5.4.1. If this is supposed to be the most
>>>stable release, recommended for those that want reliability
>>>over features, it should be labeled and distributed as such.
>>>

Sally Shears
2005-03-19, 07:58
Same here... 5.4.1 on Mac OS X.

I want to say "Thank you" to the beta-pioneers.

-- Sally

On Wed, 16 Mar 2005 17:52:13 +0100, Patrick Delamere
<slimdevices (AT) delamerelocal (DOT) homeip.net> wrote:
> I'd ditto that. My Slimserver runs flawlessly 24/7.
>
> Patrick

--
Sally Shears (a.k.a. "Molly")
SallyShears (AT) gmail (DOT) com -or- Sally (AT) Shears (DOT) org
(was sshears (AT) theWorld (DOT) com)

Phil Karn
2005-03-21, 00:19
Jason wrote:
> The overwhelming majority of users do not seem to have the problems you have
> with the server crashing or grinding to a halt.
>
> It sounds like it might be worth your time to try Slimserver on another
> machine.

Perhaps I did overstate the unreliability of the 5.4 code. What I said
certainly *does* apply in spades to all of the 6.x versions I've tried
recently. None of them were at *all* usable.

5.4.0 does usually stay up for a day or two, and as long as I don't try
to add stuff to the database it usually works modulo occasional, long
and unexpected pauses in responding to even trivial commands from the
remote control or the web interface, and unexplained and sometimes long
interruptions while playing back FLAC files over a 100 Mb/s wired
connection. Renicing the tasks up a few points usually gets rid of the
pauses, but only at the expense of impairing other interactive processes
on the same machine whenever slimserver does crunchy things like
rescanning the music database.

Speaking of which, when I add something to the database, or merely
change a FLAC tag, I don't even bother with the "rescan" button as I
know it probably won't work correctly. I just blow away the database and
rebuild it from scratch.

This is an otherwise solidly reliable 4U rackmount 3.2 GHz Pentium 4
running Linux 2.6.11, with 2 GB of ECC memory and 2.3 TB of EIDE and
SATA disk storage organized into RAID-1 and RAID-5 arrays. With that
much memory, I don't bother with a swap partition, so VM thrashing is
not a problem. The Antec box is loaded with big cooling fans, and
internal temperatures are well controlled.

Sally Shears
2005-03-21, 08:31
Phil, you CERTAINLY have enough hardware for this!

I'm running 5.4.0 and 5.4.1 just fine on much less hardware. No
hiccups, no crashes, it's the family music system. Just runs, like I
would expect for HiFi gear.

I suggest a test... Take one of your old machine, do a straight-up
default linux installation and put a few hundred songs on it. I don't
know if it's your mixed drive types, the RAID, or the "no-VM" that's
causing the problem, but it's something that's causing the problems.
Or, post some logs here.

It IS frustrating when things don't work.

-- Sally

On Sun, 20 Mar 2005 23:19:20 -0800, Phil Karn <karn (AT) ka9q (DOT) net> wrote:
>
> 5.4.0 does usually stay up for a day or two, and as long as I don't try
> to add stuff to the database it usually works modulo occasional, long
> and unexpected pauses in responding to even trivial commands from the
> remote control or the web interface, and unexplained and sometimes long
> interruptions while playing back FLAC files over a 100 Mb/s wired
> connection.

> This is an otherwise solidly reliable 4U rackmount 3.2 GHz Pentium 4
> running Linux 2.6.11, with 2 GB of ECC memory and 2.3 TB of EIDE and
> SATA disk storage organized into RAID-1 and RAID-5 arrays. With that
> much memory, I don't bother with a swap partition, so VM thrashing is
> not a problem. The Antec box is loaded with big cooling fans, and
> internal temperatures are well controlled.
>
>

Jack Coates
2005-03-21, 08:44
Phil Karn wrote:
....
> This is an otherwise solidly reliable 4U rackmount 3.2 GHz Pentium 4
> running Linux 2.6.11, with 2 GB of ECC memory and 2.3 TB of EIDE and
> SATA disk storage organized into RAID-1 and RAID-5 arrays. With that
> much memory, I don't bother with a swap partition, so VM thrashing is
> not a problem. The Antec box is loaded with big cooling fans, and
> internal temperatures are well controlled.
>

You might want to do some research on modern virtual memory
management... swap is necessary no matter how much RAM you have. Anyway,
I haven't seen how many tracks you have, but that machine is about four
times more than the average Slimserver installation runs on. If you want
to troubleshoot instead of complain, please post the following:

vmstat 1 25

cat /proc/`pidof slimserver`/status

top (preferably sorting by memory usage, press shift-M).

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

Phil Karn
2005-03-21, 18:44
Jack Coates wrote:

> You might want to do some research on modern virtual memory
> management... swap is necessary no matter how much RAM you have.

I disagree. I see no reason for a swap partition when you already have
far more physical RAM than most swap partitions used to be, and tasks
never fail because of memory exhaustion.

Swap partitions are also a potentially serious security hazard;
passwords, encryption keys and other sensitive cleartext information
have been known to persist on them for years.

> Anyway,
> I haven't seen how many tracks you have, but that machine is about four
> times more than the average Slimserver installation runs on.

As I just posted in another message, I count 17,115 files in two
separate 200GB filesystems built from RAID-5 partitions spread across 5
300GB SATA disks, with an additional disk as a hot spare.

homer$ vmstat 1 25
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
1 0 0 58992 298524 1134372 0 0 29 8 23 33 43
1 56 0
0 0 0 58992 298524 1134372 0 0 0 0 1023 1054 0
0 100 0
0 0 0 58992 298524 1134372 0 0 0 36 1028 1073 1
0 100 0
0 0 0 58992 298524 1134372 0 0 0 60 1062 1092 0
0 100 0
0 0 0 58992 298524 1134372 0 0 0 0 1021 1059 1
0 100 0
0 0 0 58992 298524 1134372 0 0 0 0 1020 1059 0
0 100 0
0 0 0 58992 298524 1134372 0 0 0 0 1018 1048 0
0 100 0
0 0 0 58992 298524 1134372 0 0 0 36 1031 1088 0
0 100 0
0 0 0 58840 298524 1134372 0 0 0 105 1045 1080 0
0 98 1
0 0 0 58840 298524 1134372 0 0 0 0 1021 1051 0
0 100 0
0 0 0 58840 298524 1134372 0 0 0 0 1025 1055 0
0 100 0
0 0 0 58840 298524 1134372 0 0 0 0 1020 1051 1
0 100 0

[this is a little unusual in that I normally have two copies of
Seti@Home running -- this is a hyperthreaded 3.2 GHz P4 -- but the Boinc
server has been off the net for several days, and my machines have run
out of work. Those tasks are always niced to 19 and consume minimal memory.]

homer$ more /proc/1410/status
Name: slimserver.pl
State: S (sleeping)
SleepAVG: 98%
Tgid: 1410
Pid: 1410
PPid: 1
TracerPid: 0
Uid: 0 1008 0 1008
Gid: 0 0 0 0
FDSize: 256
Groups:
VmSize: 98800 kB
VmLck: 0 kB
VmRSS: 95240 kB
VmData: 94804 kB
VmStk: 84 kB
VmExe: 996 kB
VmLib: 2756 kB
VmPTE: 132 kB
Threads: 1
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000011080
SigCgt: 0000000080004007
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 0000000000000000
homer$ top - 17:34:46 up 5 days, 6:08, 1 user, load average: 0.00,
0.01, 0.00
Tasks: 110 total, 1 running, 109 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3% us, 0.0% sy, 0.0% ni, 99.2% id, 0.3% wa, 0.0% hi, 0.2% si
Mem: 2076460k total, 2019228k used, 57232k free, 298616k buffers
Swap: 0k total, 0k used, 0k free, 1134960k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1410 slimserv 15 0 98800 93m 2204 S 0.7 4.6 77:48.69
slimserver.pl
1356 mysql 16 0 127m 15m 2804 S 0.0 0.8 0:00.54 mysqld

4082 karn 15 0 10308 7476 3884 S 0.0 0.4 0:02.74 emacs

1467 asterisk 18 0 38568 5852 3580 S 0.0 0.3 0:01.08 asterisk

20875 proxy 15 0 7648 5360 1628 S 0.0 0.3 0:01.77 squid

1785 www-data 15 0 6808 4236 2868 S 0.0 0.2 0:00.03 apache-ssl
[...]


[obviously slimserver has quite an appetite for memory. However, it's
still only a small fraction of the 2GB on the system.]

I note several other slimserver related tasks on the system:

homer$ ps -elf | grep slimserver
5 S slimser 1410 1 1 75 0 - 24700 - Mar16 ?
01:17:52 slimserver
0 S slimser 1443 1410 0 76 0 - 406 - Mar16 ?
00:00:00
/usr/local/slimserver/Bin/i386-linux-thread-multi/mDNSResponderPosix -n
SlimServer -t _http._tcp -p 9000
0 S slimser 1444 1410 0 76 0 - 406 - Mar16 ?
00:00:00
/usr/local/slimserver/Bin/i386-linux-thread-multi/mDNSResponderPosix -n
SlimServer -t _slimhttp._tcp -p 9000
0 S slimser 1445 1410 0 76 0 - 406 - Mar16 ?
00:00:00
/usr/local/slimserver/Bin/i386-linux-thread-multi/mDNSResponderPosix -n
SlimServer -t _slimcli._tcp -p 9090

Apparently the clients are currently all quiet (I'm not at home).

--Phil

Jack Coates
2005-03-21, 20:55
Phil Karn wrote:
> Jack Coates wrote:
>
>> You might want to do some research on modern virtual memory
>> management... swap is necessary no matter how much RAM you have.
>
>
> I disagree. I see no reason for a swap partition when you already have
> far more physical RAM than most swap partitions used to be, and tasks
> never fail because of memory exhaustion.
>

whatever floats your boat.

> Swap partitions are also a potentially serious security hazard;
> passwords, encryption keys and other sensitive cleartext information
> have been known to persist on them for years.
>

http://www.google.com/search?hl=en&lr=&c2coff=1&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&q=linux+encrypted+swap+partition&btnG=Search

Again, a fun theoretical argument -- or are you saying this box has a
lot of untrusted root-level users who are frequently working in shells
on it? I know my server won't let me do anything of the sort without
being root.

>> Anyway, I haven't seen how many tracks you have, but that machine is
>> about four times more than the average Slimserver installation runs on.
>
>
> As I just posted in another message, I count 17,115 files in two
> separate 200GB filesystems built from RAID-5 partitions spread across 5
> 300GB SATA disks, with an additional disk as a hot spare.
>
> homer$ vmstat 1 25
.... evidence of a completely idle server snipped for brevity ...
>
> Apparently the clients are currently all quiet (I'm not at home).
>
> --Phil

OK, I give -- the key here, as you identify in another message is that
you're playing FLACs, and with that fact I think there's just not a lot
to do except for SB2 and its bigger buffer. Buffer starvation could
theoretically be slowed or alleviated by reducing other tasks. For
instance, I bet your vmstat looks like a few miles of bad road when
you're browsing those 17K tracks on two ATA drives through the Web UI or
rebuilding the cache. In theory a bunch of componentry could be isolated
off into other processes so it would be non-blocking, but in the end
your performance would still be questionable (UI and streaming and data
management rely on each other and are going to block, sooner or later).
You could try prioritizing traffic (tc) and processes (nice), but at the
end of the day I'm guessing that it's probably not going to work unless
you transcode to a lossy format on the fly.

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

michael
2005-03-22, 12:46
Phil Karn <karn (AT) ka9q (DOT) net> writes:

> Jack Coates wrote:
>
>> You might want to do some research on modern virtual memory
>> management... swap is necessary no matter how much RAM you have.
>
> I disagree. I see no reason for a swap partition when you already have
> far more physical RAM than most swap partitions used to be, and tasks
> never fail because of memory exhaustion.

While this makes perfect sense in theory, the linux kernel (among
others) is written with the expectation of having a swap space, and it
makes decisions about scheduling, caching and memory management based
on that assumption. If you really want to run it without a swap space
and maintain performance, you need to tweak the kernel settings a bit.
Start with a google on "swappiness" and go from there.

-michael

Michael Peters
2005-03-23, 15:26
On Tue, 22 Mar 2005 11:46:10 -0800, michael <michael (AT) fallenangel (DOT) com> wrote:
> Phil Karn <karn (AT) ka9q (DOT) net> writes:
>
> > Jack Coates wrote:
> >
> >> You might want to do some research on modern virtual memory
> >> management... swap is necessary no matter how much RAM you have.
> >
> > I disagree. I see no reason for a swap partition when you already have
> > far more physical RAM than most swap partitions used to be, and tasks
> > never fail because of memory exhaustion.
>
> While this makes perfect sense in theory, the linux kernel (among
> others) is written with the expectation of having a swap space, and it
> makes decisions about scheduling, caching and memory management based
> on that assumption. If you really want to run it without a swap space
> and maintain performance, you need to tweak the kernel settings a bit.
> Start with a google on "swappiness" and go from there.

In the 2.6 kernel you can use a swap file instead of a swap space and
it allegedly (I haven't tried) is just as fast.

Swap space is not just for a lack of memory.
Things in memory that have not been used get written to swap, so that
free memory in swap can be used to be instantly ready for new apps (or
reading back apps that were swapped) and can be used for disk read
cache.

The disk read cache gives you a huge performance boost, if a file has
been read and is in the cache - then the OS does not need to go to
disk for it again when it is requested again. This is why you want
swap even if you have plenty of memory for the apps you run - it
allows your memory to be used efficiently, no waste.

If you neglected to set up a swap partition, look into setting up a swap file.

--
http://mpeters.us/

Phil Karn
2005-03-23, 20:40
Jack Coates wrote:

> http://www.google.com/search?hl=en&lr=&c2coff=1&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&q=linux+encrypted+swap+partition&btnG=Search

I'm aware of the various ways to encrypt a swap partition. They are
obsolete in this age of cheap, large RAM modules.

> Again, a fun theoretical argument -- or are you saying this box has a
> lot of untrusted root-level users who are frequently working in shells
> on it? I know my server won't let me do anything of the sort without
> being root.

No, I'm the box's only interactive user, though it also runs web and
mail services that my wife also uses. However, the machine sits in my
house, not a co-lo, and is thus potentially vulnerable to physical
theft. I use encryption as appropriate to protect my employer's
information and other sensitive information, but that can be rendered
ineffective if encryption keys can persist on an unencrypted swap device.

> OK, I give -- the key here, as you identify in another message is that
> you're playing FLACs, and with that fact I think there's just not a lot
> to do except for SB2 and its bigger buffer.

Yes, clearly things are stressed by my large collection of FLACs and the
relatively small buffer in the SB1. But...

> Buffer starvation could
> theoretically be slowed or alleviated by reducing other tasks. For
> instance, I bet your vmstat looks like a few miles of bad road when
> you're browsing those 17K tracks on two ATA drives through the Web UI or
> rebuilding the cache. In theory a bunch of componentry could be isolated
> off into other processes so it would be non-blocking, but in the end
> your performance would still be questionable (UI and streaming and data
> management rely on each other and are going to block, sooner or later).
> You could try prioritizing traffic (tc) and processes (nice), but at the
> end of the day I'm guessing that it's probably not going to work unless
> you transcode to a lossy format on the fly.
>

This will work not just in theory, but also in practice. I have a fair
bit of experience in networking and real-time applications, and I'm
convinced that carefully restructuring and reprioritizing the server
tasks and threads responsible for real-time playback -- and separating
them from non-real-time operations such as managing the database and
driving the UI -- could completely eliminate *all* playback interrupt
problems, even with my many big FLAC files and a small SB1 playback buffer.

My LAN is a combination of switched 100-Base-T and 1000-Base-T segments
that are never loaded anywhere near capacity. (Yes, it's also quite
reliable; I've measured my packet latency and loss rates, and they're
always near zero or zero, respectively.) My server has plenty of all the
required resources (disk I/O bandwidth, CPU cycles and RAM) to decode a
FLAC file and buffer the raw PCM far ahead of the playback pointer in
the SB. So there's simply no fundamental reason why playback
interruptions should ever occur.

The problem with the existing server, just as you point out, is that the
real-time and non-real-time server functions are bundled into the same
tasks and threads, and insufficient attention has been paid to meeting
real-time-critical playback requirements. Yes, the bigger buffer in the
SB2 will definitely help (I have one on order) but I disagree that it's
the only way or even the best way to solve the problem.

Phil