Re: [nslu2-linux] Re: Best File System For Streaming MP3 Files
- Jon Smirl wrote:
>No trouble playing MP3s, I'm just a little surprised with what I read
> On 12/31/07, ragacycle <alcoheca@...
> <mailto:alcoheca%40googlemail.com>> wrote:
> > --- In firstname.lastname@example.org
> <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?
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
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.