--> Trying to FTP a 125 MB file in 80 sec. or less
--> an ATM WAN.
--> Has anybody done this and if yes, can they share
Khalid, Fuad <email@example.com>
Make sure you place the file on /tmp and copy it to
/tmp on the other serverto reduce any disk io.
Gary Mulder <firstname.lastname@example.org>
ATM 155Mb has a typical bandwidth of 10MB/sec so in an
*ideal* environment a 125MB file should take less than
15 seconds. This gives you a baseline.
You're looking for a thruput of about 1.5MB/sec which
should be eminently doable, even over a WAN. The FTP
client and server (unless they are heavily overloaded
or very slow) should not be the bottlenecks,
nor should the ATM WAN (again unless it is saturated),
therefore have a look at how many routers you are
sending through using traceroute.
To get an idea of what the maximum thruput between
you're client and server try installing Netperf, which
can give you some very useful statistics
Seth Rothenberg <SROTHENB@montefiore.org>
is it compressed?
If NOT, I have a thought - depending how much CPU
power /disk space is available.
I do have experience in using FTP to/from a pipe.
you could do something like
ftp -n remotehost << EOF <
user remoteuserid remotepassword
put - remotefile.gz
You might also look at wu-ftpd, which may be able to
do the compressing or uncompressing on the fly. We
don't have wu-ftpd nstalled yet.
Stout, Logan <ldstout@MediaOne.com>
that would be really... really fast.. if your receive
and send buffers and packet sizes are already cranked
up.. and you have fiber channel or at least ultra LVD,
then its still going to be tight. the big factors here
are..drive speed (which can be made a nonissue if you
load the file into ram.) and system speed. the next
question is, how fast is your atm link.. I mean how
fast is it REALLY? bearing in mind that megabits per
second is a lot less than megaBYTES per second. Is
your ATM link in use for other tasks when it happens?
Anyway, to get back to your original questions, make
sure your nic's MTUS are set right for this
connection, make sure your disk is fast enough to
sustain that kind of throughput. if you dothat to both
sides, and crank up your ftp server (and client) to
take in the largest packets and largest send and
receive buffers you can. If it still doesn't work, I
don'tknow the answer..
Assuming that you have an OC-3 (155 Mb/s ATM link)
this should notbe a problem. How long is it taking
and what is the speed of your link?
Caparrosso, Nelson T.
To achieve that transfer time for said sized file, you
would need to have at least a 15 Mbps (Megabits/sec)
WAN link. And from the loks of it, your only choice is
a ATM link
Gary Jenson <email@example.com>
I have a couple of machines with gigabit ethernet, and
I can ftp whatever size file I wish at 22MByte /
second, just the speed data comes off/on the disks.
125MB in 80 Seconds should be very doable. That is
about 15Mbit/second, which you should be able to get
with anything better than 10base T.Just my random
Biondi, Michael <firstname.lastname@example.org>
Sure, why not. This is only ~ 1.5Mb per sec, so
around a T1. What is your ATM running on?
Geoffrey Press <GeoffreyP@Tforce.com.au
Without sounding very sarcastic, you need at least a
Jonathon W. Ross <email@example.com
With OC-3 you could do it in about 10 seconds.
If you want to guarantee that your connection will get
that much bandwidth you could use Committed Access
Rate feature on your router (Cisco).
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
U BEFORE POSTING please READ the FAQ located at
. and the list POLICY statement located at
A To submit questions/summaries to this list send your email message to:
A To unsubscribe from this list please send an email message to:
E and in the BODY type:
R unsubscribe sun-managers
. unsubscribe sun-managers firstname.lastname@example.org
L To view an archive of this list please visit:
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:14 CDT