Slim Devices SB2 disappointment & SB for sale.

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Jason

    Slim Devices SB2 disappointment & SB for sale.

    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

    #2
    Slim Devices SB2 disappointment & SB for sale.

    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.
    >>

    Comment

    • Patrick Delamere

      #3
      Slim Devices SB2 disappointment & SB for sale.

      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.
      >>>

      Comment

      • Sally Shears

        #4
        Slim Devices SB2 disappointment & SB for sale.

        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)

        Comment

        • Phil Karn

          #5
          Slim Devices SB2 disappointment &amp; SB for sale.

          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.

          Comment

          • Sally Shears

            #6
            Slim Devices SB2 disappointment &amp; SB for sale.

            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.
            >
            >

            Comment

            • Jack Coates

              #7
              Slim Devices SB2 disappointment &amp; SB for sale.

              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!

              Comment

              • Phil Karn

                #8
                Slim Devices SB2 disappointment &amp; SB for sale.

                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

                Comment

                • Jack Coates

                  #9
                  Slim Devices SB2 disappointment &amp; SB for sale.

                  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.
                  >




                  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!

                  Comment

                  • michael

                    #10
                    Slim Devices SB2 disappointment &amp; SB for sale.

                    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

                    Comment

                    • Michael Peters

                      #11
                      Slim Devices SB2 disappointment &amp; SB for sale.

                      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.

                      --

                      Comment

                      • Phil Karn

                        #12
                        Slim Devices SB2 disappointment &amp; SB for sale.

                        Jack Coates wrote:

                        > http://www.google.com/search?hl=en&l...on&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

                        Comment

                        Working...