Re: [nslu2-linux] Re: Big endian vs Little endian and Network performance
- On Jul 2, 2006, at 11:31 AM, Yann E. MORIN wrote:
> Hello all!Why "Not the best option", do you mean you should be using a faster
> On Saturday 01 July 2006 000, David Given wrote:
>> fransmeulenbroeks wrote:
>> Is there any chance you could get hdparm and try this:
>> hdparm -t -T /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda
> Here are the results for my 3 drives attached to my slug.
> I'm running OpenSlug 3.10 on an de-underclocked slug.
> The first one I'm using as rootfs and swap device (not the best
> option, as it
> seems), and is an old 4GiB HDD I scavenged from my mate's old
> laptop. This one
> is directly attached to port 1 of the slug.
drive for root and swap ? What is the "best" option? Something like
>Oh Boy! Real World Numbers, this is what we need.
> The second and third HDDs are the real hosting devices, which store
> all my
> files (mail, movies, music, photos, ...). Those I need fast access
> to. They
> are attached to an un-powered USB hub, itslef connected to port 2
> of the slug.
> I also ran a netcat over the wire with direct connection between my
> PC and
> slug, a rather good cat-5 cable that was not bent that much.
> Turns out that even my slower drive (~56Mibps) is faster than the
> (~48Mibps). Repeated with different cables, shorter or in better
> 'shape', but
> no better.
> So I find that 80Mibps claim a bit hard to believe... :-)
You are seeing about what I am, although you have been far more
thorough in your measurements. Using "time" to time a file copy of
100MB to and from an NFS mount I am coming up with about the same as
you are, 45-48 Mbps. This is with a 2.5" notebook type drive, my next
step is to try with several different drives and USB chipsets, as I
had assumed that was the limiting factor.
But you're indicating it's the network that's limiting speed:
So perhaps the question is what is limiting the network speed? If the
limitation is on the slug end is it the slug itself ? (hardware) or
could the NIC drivers possibly be made better ? TCP/IP stack?
How do we go about determining which end is limiting the speed? I
guess by connecting to something else (PC-to-PC ?)
It's hard for me to see how any switch, "real" or otherwise, could be
faster than a pice of copper, even though I will grant that a lot of
consumer switches are crap - they have NICs that will ACK a "100
speed full-duplex" connection even though they have processing
engines that can't manage even half that.
But I don't think our friend reporting 80Mbs. is lying to us either.
I think he is really seeing those numbers on his screen, we just have
to figure out if they mean what they seem to mean or not :-)
On Monday 03 July 2006 002, Brian Wood wrote:
> [Don't know if changing the subject will preserve the threading or not]
Looks like it's OK. :-)
> On Jul 2, 2006, at 3:37 PM, Yann E. MORIN wrote:
> >> Something like this:
> >> http://www.geeks.com/details.asp?invtid=77P1636&cat=HDD
> > Hmm, donuts!... :-) Anyway i would not entrust flash-based hard-
> > drive, wether
> I'll grant all of that, but once I get the thing going I hardly touch
> swap at all, and that thing does seem *fast*, but I suspect the
> limiting factor is the IDE-USB transition, so it might not be any
> faster than a normal 4200 rpm drive.
So hand-adding swap only when you need it for sure (compilation, install
of packages, etc..) Yes, why not. Then that's not that bad. But still I'm
amazed at the figures they show. Seems pretty fast for flash.
> If the cycle number is correct on that, and they are "spreading the
> load", I could live with having to replace the drive every year, if
> it actually gave me a speed boost.
Surely they are doing wear-leveling on [dr]ecent flash memories.
> I suppose the only way to know for sure is to buy one and play with
> it, $99 for a 2GB, oh well, it's only money.
Be my guest. Tell us about your conclusions! :-)
> > Maximum load when receiving: 0.94. That's really, really _big_.
> > So what does that _mean_? It looks like we _are_ CPU-bound on the
> > slug, and thus
> > it can not even sustain receiving more than around 48Mibps. That is
> > _receiving_.
> I guess I'm not surprised, for <$100 :-)
Yes, I can't imagine with a 133Mhz slug... :-/ Anyway, that's a good buy,
and you get what you pay for: a good little hardware really easy to play with,
a NAS that will fulfill most of your desires reagarding file access (except if
you are dumb enough to have your /home on it (I am!)) and a little box that is
quite good-looking after all.
> > Looking at the WiKi, there is a section on using the DMA
> > accelerations from the
> > NPEs. That could help, but yet... :-/
> So it looks like 48Mibps is about it, and the most helpful
> improvement would probably be from a better network driver.
Such as an USB-to-ethernet adapter, as David suggests. But again, we might
see a bottleneck between usb-storage and usb-ethernet... :-/
Anyway, if anyone can conduct the same tests with such a device, please tell
> Much thanks for the information.
You're welcome. I was enlighten as well by this very instructive experiment.
At last I know how I can entrust my slug regarding file-serving speeds.
Yann E. MORIN.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ |
| --==< °_° >==-- °---.----------------: X AGAINST | /e\ There is no |
| web: ymorin.free.fr | SETI@home 3808 | / \ HTML MAIL | """ conspiracy. |