fastest network protocol

Hi,

What would be the fastest way (ftp, nfs, scp, ...) to distribute large files
(2GB) to 10-20 clients simultaneously? Both the server(s) and the clients
would be running some kind of Linux distro (not all the same though).

E.T.

Hi Erik,

> What would be the fastest way (ftp, nfs, scp, ...) to distribute large files
> (2GB) to 10-20 clients simultaneously? Both the server(s) and the clients
> would be running some kind of Linux distro (not all the same though).

I have no experience with scp, but usually FTP will be the fastest way to
transport files. When looking at the real file transfer, there is no overhead
by FTP since the two boxes use a direct TCP-connection for data transport.
Prtocol overhead should also be very small with FTP.

NFS does some more complex things and anything with 'secure' in name (like scp)
will surely have more overhead (at least it might eat up more cpu time while
encrypting things....well i haven't dealt with scp so far).

I think the more important question is about your infra-structure.
If your server has only one harddisk and one NIC (i'm asuming you want to
distribute the files in LAN), all simult. transfers will have to go through
that NIC and come from that hard disc.

I'm pointing to the hard disc because i don't know how intelligent your server
proggi (e.g. FTP server) is....it should only read the file once and use memory
cache for serving the different clients.....if it does not your HDD will be a
terrible bottleneck, if your server tries to access differnt parts of the file
in parallel.
Well usually server proggies or at least the linux OS is intelligent enough to
use caching.......but the efficiency greatly depends on how close the requests
from your clients arrive (if one client comes 1 minute later, it will be most
likely the case, that the requested data is no longer in RAM and so the
server has to read the file from the beginning while trying to serve other
clients with other parts of the file: see above, no HDD will like that).

The NIC thing is also important. If you use a hub to connect all your machines,
there is no real good way to speed up overall transfer. E.g. when you serve n
clients one after another, you will have full bandwidth per clients, but it
takes n transport cycles.
If you assume, transfering 1 file with full bandwidth will take time t,
the total time to spread the files will be n*t (of course).

If you serve all n clients in parallel, the best case would be, that every
client can use (full Bandwidth)/n to get tha data.
Well, if you sum it up, you will again end up at the amount of n*t.
But be sure, when using a hub, this best case will hardly be happening.
Ethernet packets will collide which might lead to a real drop in Ethernet
bandwidth.......so in teh case of a hub the best idea _might_ be,
serving only one client at a time.

If you have a switch to connect your machines, you have a good option to speed
up the transfer. Its done iteratively.
A usual switch can hold up indiependent (e.g. collision free) ethernet
connections between indienpendent host pairs (A <-> B and C<->D).

So you start serving the files from your original server (A) to one client box
(B). Now you have 2 potential servers (if you run the server proggie
on box B, too :-).
Now serve client C from server A and client D from server B.
This should be possible without any HDD or NIC issue.
After this you have 4 potential servers........and so on.
Maybe your switch will not be able to handle as much parallel connection as
would arise if you continue this game a litte bit.......but some benchmarking
and maybe the doc of the switch will help in finding out the optimum solution.

Uh, a lot of things i wrote. I apalogize if that's not interesting to you.
But the basic problem behind your question is very interesting to me, so......

Bye

Ralf

On Thu, 22 Apr 2004 11:25:05 +0200, Erik Thijs <(E-Mail Removed)> wrote:
> Hi,
>
> What would be the fastest way (ftp, nfs, scp, ...) to distribute large files
> (2GB) to 10-20 clients simultaneously? Both the server(s) and the clients
> would be running some kind of Linux distro (not all the same though).

scp can use compression to transfer some files up to more than twice the
speed of your network connection (especially over ppp, pppoe, cable,
wireless). However, there may be less difference if the files are already
compressed (zipped) first, or if possible transfer rate would tend to
exceed hard disk capabilites.

--
David Efflandt - All spam ignored http://www.de-srv.com/

Erik Thijs <(E-Mail Removed)> writes:

> What would be the fastest way (ftp, nfs, scp, ...) to distribute large files
> (2GB) to 10-20 clients simultaneously? Both the server(s) and the clients
> would be running some kind of Linux distro (not all the same though).

Not enough info. Are you going to distribute the files across the
Internet, or is it on your LAN? In the latter case, maybe think of
udp instead of tcp. Also, is this something like streaming? If so,
can you afford te lose some packets (think audio/video vs. datafile)?

I agree with other posters that ftp will be a good bet.

Vilmos

Vilmos Soti wrote:

> Erik Thijs <(E-Mail Removed)> writes:
>
>> What would be the fastest way (ftp, nfs, scp, ...) to distribute large
>> files (2GB) to 10-20 clients simultaneously? Both the server(s) and the
>> clients would be running some kind of Linux distro (not all the same
>> though).
>
> Not enough info. Are you going to distribute the files across the
> Internet, or is it on your LAN? In the latter case, maybe think of
> udp instead of tcp. Also, is this something like streaming? If so,
> can you afford te lose some packets (think audio/video vs. datafile)?
>

Purpose is to restore images from a central server over the LAN. Streaming
is not an option and packet loss (UDP) will screw up the data...

At the moment we restore using a Windows share and a DOS client, but DOS
client and network drivers don't always work well together, so I'm looking
for an open source alternative (linux and network drivers go together
better in most cases).

E.T.

Erik Thijs wrote:

> Hi,
>
> What would be the fastest way (ftp, nfs, scp, ...) to distribute large
> files (2GB) to 10-20 clients simultaneously? Both the server(s) and the
> clients would be running some kind of Linux distro (not all the same
> though).
>
> E.T.
Hi,

well, I might be in the wrong ng at the moment, but there is this killerapp
called Ghost, from Norton I think. It can multicast, so I already managed
to set up 8 PCs simultaneously in about 15 minutes! The floppies to boot
are created from Ghost, and it is very fast and simple, many drivers
included. This is MickySoft only, though.

Alex

On Thu, 22 Apr 2004 16:59:25 +0200, Erik Thijs wrote:
> Purpose is to restore images from a central server over the LAN. Streaming

Maybe nc(1) and dd(1) can team up to do this. On each destination
machine start a listening nc piped through dd:
# nc -p 65432 | dd of=/dev/hda # optionally pipe through gzip or bzip2
Then on the server, ... uh, honestly I'm not sure how to do this. Maybe
tee(1) with FIFO's? nc can do multiple ports, but AFAICT only one
destination host. Soooo ... iptables DNAT?

I know this can work. I also know it has to be the fastest possible
means of data transfer, since the only network protocol overhead is
that of TCP itself.

Play with it, and post your solution. Good luck.
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply

Erik Thijs <(E-Mail Removed)> wrote:
> What would be the fastest way (ftp, nfs, scp, ...) to distribute large files
> (2GB) to 10-20 clients simultaneously? Both the server(s) and the clients
> would be running some kind of Linux distro (not all the same though).

If you really want the fastest way, and you really mean simultaneously,
then I'd suggest that you consider rolling your own multicast/broadcast
scheme.

One simple approach would be to transmit (e.g.) 4 KB in each UDP
packet. Each client would determine which packets it had (not) received,
and at the end of the broadcast would ask for specific packets to be
retransmitted. You could write the file on the fly, and then go back and
"fill in" the missing 4KB holes.

Chris

Erik Thijs <(E-Mail Removed)> wrote:

> Purpose is to restore images from a central server over the LAN. Streaming
> is not an option and packet loss (UDP) will screw up the data...

I _strongly_ urge you to use System Imager. It can (in the newer
versions) use reliable multicast using a tool called flamethrower.
I've only used it unicast though myself, but I wouldn't want to use
anything else, as its so fast to update the clients.

www.systemimager.org

--
Cameron Kerr
(E-Mail Removed) : http://nzgeeks.org/cameron/
Empowered by Perl!