| Author |
Message |
kalev-
Guest
|
 Posted:
Thu Dec 09, 2004 7:11 pm Post subject:
transfer speed over gigabit LAN? |
|
|
Assuming sequential transfer actually very large files:
From what I recall you'll get about 6MB/s or 7MB/s -ish transfer speeds over
100Mbit ethernet. (From memory)
What can be expected over gigabit LAN (single HDs)?
Ie: x10: 60-70MB seems too high? The seq. transfer rate on IDE disks isn't
it around 20-40MB/sec anyways ? Am I close to what can be expected? (I'm
assuming very litte file fragmentation, and huge files)
--
Every day above ground is a good day |
|
| Back to top |
|
 |
ernest
Guest
|
| Posted:
Thu Dec 09, 2004 9:17 pm Post subject:
Re: transfer speed over gigabit LAN? |
|
|
| Quote: | Assuming sequential transfer actually very large files:
From what I recall you'll get about 6MB/s or 7MB/s -ish transfer
speeds over
100Mbit ethernet. (From memory)
What can be expected over gigabit LAN (single HDs)?
Ie: x10: 60-70MB seems too high? The seq. transfer rate on IDE disks
isn't
it around 20-40MB/sec anyways ? Am I close to what can be expected?
(I'm
assuming very litte file fragmentation, and huge files)
|
Yeah, you're bottlenecked by your single HD. SCSI can be faster but
IDE will be around 20-40MB. Get RAID-0 with 2 disks will approx.
double your speed. On the other hand a single thread is not helping
either.
Ernest
| Quote: |
--
Every day above ground is a good day |
|
|
| Back to top |
|
|
Guest
|
| Posted:
Thu Dec 09, 2004 10:46 pm Post subject:
Re: transfer speed over gigabit LAN? |
|
|
In article <31r1mcF3ecmf9U1@individual.net>, kalev- <you.wish@duh.net> wrote:
| Quote: | Assuming sequential transfer actually very large files:
From what I recall you'll get about 6MB/s or 7MB/s -ish transfer speeds over
100Mbit ethernet. (From memory)
|
Then your bottleneck is something other than the Ethernet. I've seen
reliably 10 MB/sec and a little over.
| Quote: | What can be expected over gigabit LAN (single HDs)?
|
Again, this is only a sensible question if you have removed all other
bottlenecks, and the gigE network is your tightest bottleneck. I have
personally run reliably at 88 to 95 MB/sec. I hear war stories of
people who have gotten near 100 MB/sec, and I find those perfectly
believable.
This requires two CPUs in the data server, a good RAID engine
(dedicated hardware for that), and an array of server-class disk
drives. With top-end commodity hardware, it might be doable with 3GHz
CPUs, without a hardware RAID assist, and with two or three good IDE
or SATA drives, but I'd feel more comfortable trying to get to those
numbers with serious hardware.
| Quote: | Ie: x10: 60-70MB seems too high? The seq. transfer rate on IDE disks isn't
it around 20-40MB/sec anyways ?
|
If you are serving a single IDE disk, then your bottleneck will
clearly NOT be the gigE network. With a single SCSI disk, you can get
up to 50-60 MB/sec. I have not even measured what an IDE disk can do
(I'm not personally interested in that).
| Quote: | Am I close to what can be expected? (I'm
assuming very litte file fragmentation, and huge files)
|
The fact that you are even talking about file fragmentation and huge
files indicates that you are measuring file system throughput. In
many cases, this will mean that the network is not the real
bottleneck. In particular, if you use a really bad network transfer
protocol (NFS, CIFS) or a really slow backend filesystem (some Unix
filesystems are still ancient Berkeley), then there is little chance
of maxing out the hardware (either the network or the harddisk).
The above numbers are for a really good (state-of-the-art) cluster
filesystem, using iSCSI as the transfer protocol on the wire. Note
that this requires significant CPU power just for handling the network
stacks. Assume that both on the client and server side, about 1-2 GHz
of x86-class CPU will be dedicated to stack processing (TCP, iSCSI,
file system) at gigE speed. A TOE or iSCSI HBA would probably help,
but I didn't have one.
To repeat one more time: In most real-world scenarios, using commodity
hardware and few drives, gigE will not be the limiting factor in
network file service or network storage service. This is particularly
true if you use stupid network file system protocols like NFS or CIFS.
--
The address in the header is invalid for obvious reasons. Please
reconstruct the address from the information below (look for _).
Ralph Becker-Szendy _firstname_@lr_dot_los-gatos_dot_ca.us |
|
| Back to top |
|
|
Yura Pismerov
Guest
|
| Posted:
Fri Dec 10, 2004 7:05 pm Post subject:
Re: transfer speed over gigabit LAN? |
|
|
_firstname_@lr_dot_los-gatos_dot_ca.us wrote:
| Quote: |
To repeat one more time: In most real-world scenarios, using commodity
hardware and few drives, gigE will not be the limiting factor in
network file service or network storage service. This is particularly
true if you use stupid network file system protocols like NFS or CIFS.
|
Hmm... I wonder why my NetApp that runs that "stupid" NFS pumps 70MB/s... |
|
| Back to top |
|
|
Guest
|
| Posted:
Fri Dec 10, 2004 10:34 pm Post subject:
Re: transfer speed over gigabit LAN? |
|
|
In article <cpcaei$u0u$1@bfos.tucows.com>,
Yura Pismerov <ypismerov@tucows.com> wrote:
| Quote: |
_firstname_@lr_dot_los-gatos_dot_ca.us wrote:
To repeat one more time: In most real-world scenarios, using commodity
hardware and few drives, gigE will not be the limiting factor in
network file service or network storage service. This is particularly
true if you use stupid network file system protocols like NFS or CIFS.
Hmm... I wonder why my NetApp that runs that "stupid" NFS pumps 70MB/s...
|
I said "commodity" above.
Because a NetApp is not commodity hardware. And it is usually more
than a few drives. Actually, even more importantly, one factor I left
out in the previous post: The NetApp doesn't use commodity software
either. Their filesystem is wonderfully well designed for NFS service
(reading the white papers about it is recommended for anyone
contemplating file system or storage server design). And their OS is
not a commodity item either, but custom-designed for this purpose.
And their NFS and CIFS servers have been carefully crafted and tuned
through over a decade of hard work by many brilliant people. What you
get out of the free NFS/CIFS servers that come in your commodity OS is
a different kettle of fish.
You also pay for this. You can buy a no-name brand dual-CPU x86 with
6 or 10 drives for $X, and run a commodity OS (Windows, Linux) on it.
You can buy the equivalent NetApp (dual CPU, same number and size of
drives), but you'll pay considerable more than $X for it. But it will
serve NFS much better than the commodity hardware. TANSTAAFL.
On the other hand, if for cost reasons you are stuck with the
commodity hardware and software, I would use a storage protocol other
than NFS (or CIFS for that matter), to best utilize the hardware.
--
The address in the header is invalid for obvious reasons. Please
reconstruct the address from the information below (look for _).
Ralph Becker-Szendy _firstname_@lr_dot_los-gatos_dot_ca.us |
|
| Back to top |
|
|
Faeandar
Guest
|
| Posted:
Sat Dec 11, 2004 1:27 am Post subject:
Re: transfer speed over gigabit LAN? |
|
|
On Fri, 10 Dec 2004 17:34:21 -0000,
_firstname_@lr_dot_los-gatos_dot_ca.us wrote:
| Quote: | In article <cpcaei$u0u$1@bfos.tucows.com>,
Yura Pismerov <ypismerov@tucows.com> wrote:
_firstname_@lr_dot_los-gatos_dot_ca.us wrote:
To repeat one more time: In most real-world scenarios, using commodity
hardware and few drives, gigE will not be the limiting factor in
network file service or network storage service. This is particularly
true if you use stupid network file system protocols like NFS or CIFS.
Hmm... I wonder why my NetApp that runs that "stupid" NFS pumps 70MB/s...
I said "commodity" above.
Because a NetApp is not commodity hardware. And it is usually more
than a few drives. Actually, even more importantly, one factor I left
out in the previous post: The NetApp doesn't use commodity software
either. Their filesystem is wonderfully well designed for NFS service
(reading the white papers about it is recommended for anyone
contemplating file system or storage server design). And their OS is
not a commodity item either, but custom-designed for this purpose.
And their NFS and CIFS servers have been carefully crafted and tuned
through over a decade of hard work by many brilliant people. What you
get out of the free NFS/CIFS servers that come in your commodity OS is
a different kettle of fish.
You also pay for this. You can buy a no-name brand dual-CPU x86 with
6 or 10 drives for $X, and run a commodity OS (Windows, Linux) on it.
You can buy the equivalent NetApp (dual CPU, same number and size of
drives), but you'll pay considerable more than $X for it. But it will
serve NFS much better than the commodity hardware. TANSTAAFL.
On the other hand, if for cost reasons you are stuck with the
commodity hardware and software, I would use a storage protocol other
than NFS (or CIFS for that matter), to best utilize the hardware.
|
not sure why you don;t like NFS, CIFS I can see but not NFS. As a
protocol it's as fast as fiber channel and scsi, the network stack
adds some latency but not enough to say it blows.
~F |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in