Loading ...
Sorry, an error occurred while loading the content.

Re: [nslu2-linux] Re: Best File System For Streaming MP3 Files

Expand Messages
  • Alasdair Campbell
    ... No trouble playing MP3s, I m just a little surprised with what I read about the NSLU2 being a good performer with data transfers. I was hoping the bottle
    Message 1 of 7 , Jan 1, 2008
    • 0 Attachment
      Jon Smirl wrote:
      >
      >
      > On 12/31/07, ragacycle <alcoheca@...
      > <mailto:alcoheca%40googlemail.com>> wrote:
      > > --- In nslu2-linux@yahoogroups.com
      > <mailto:nslu2-linux%40yahoogroups.com>, Bluechip <csbluechip@...> wrote:
      > > >
      > > > First of all remember that your hard drive will ALWAYS be a LOT
      > > > faster than the USB wire it is talking down, so more important than
      > > > the speed of your hard drive is the speed of the USB. Then, of
      > > > course, you transfer the data over a 100Mbit network ...which is
      > > > about 20% the speed of USB.
      > > >
      > > > So long as your hard drive can read data a little faster than
      > > > ethernet can send it, hard drive speed [or rather, data transfer
      > > > thereof] will NOT matter.
      > >
      > > Do you know why when I run hdparm on my attached PATA drive in a
      > > USB2.0 enclosure the speed from hdparm on the slug is 8.5 MBps while
      > > from my desktop it's closer to 30 MBps ?
      > >
      > > This is with unslung firmware: V2.3R63-uNSLUng-6.8-beta.
      >
      > I just tried this with my own desktop/NSLU2 pair and there is quite a
      > difference. This isn't a problem with the file system on the device.
      >
      > I get 34.70MB/sec for cached reads (278Mb/sec). The link is capable of
      > 480Mb/sec. So that is a 50% loss somewhere. Some is lost in protocol
      > overhead but not 50%.
      >
      > For buffered reads I see 9.51MB/sec. I know the disk is capable of 40MB/sec.
      >
      > Most likely explanation for the drop from 40MB to 9.51MB is the tiny
      > microcontroller in the USB disk enclosure. It may not be fast enough.
      > Another likely culprit is that the NSLU2 is too slow to keep up with
      > the revolutions of the disk and is being forced to wait for another
      > revolution before the sector reappears. I don't know how hdparm
      > requests its IO, is it one big request or lots of little ones?
      >

      No trouble playing MP3s, I'm just a little surprised with what I read
      about the NSLU2 being a good performer with data transfers. I was hoping
      the bottle neck to be the 100Mbps Ethernet link, otherwise why bother
      with the high speed usb 2.0 controller in the slug's design?

      The enclosure was used for both hdparm tests so unless I'm mistaken that
      can't be a factor.

      However... I've hijacked this thread so perhaps I should do more
      research and post a new message if needs. hdparm is actually spitting
      out some rubbish when I run it without any switches

      happy new year
    • Shane Kerr
      All, ... I also found Samba to be slow. For Linux clients connecting to the NSLU2 I use NFS for file sharing - performance is a lot better. I run Samba at the
      Message 2 of 7 , Jan 2, 2008
      • 0 Attachment
        All,

        On Mon, Dec 31, 2007 at 05:27:18PM +0000, Bluechip wrote:
        >
        > In my experience SaMBa is the culprit for sharing speed ...On my
        > xbox it is PAINFUL (although I think this is something to do with
        > XBMC too) ...if you can, try a different protocol ...if streaming to
        > XBMC, ccxstream is a good option :)

        I also found Samba to be slow. For Linux clients connecting to the
        NSLU2 I use NFS for file sharing - performance is a lot better. I run
        Samba at the same time for sharing to Windows clients.

        --
        Shane
      Your message has been successfully submitted and would be delivered to recipients shortly.