HP3000-L Archives

April 1999, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Stigers, Greg [And]" <[log in to unmask]>
Reply To:
Stigers, Greg [And]
Date:
Wed, 21 Apr 1999 14:38:13 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (27 lines)
X-no-Archive:yes
Due to our move over the course of four weeks into a new building, our
project's NT ftp server (a 486 66!) could be unavailable for one night. So
we tested using smbclient to put the 130MB binary file on an NT workstation
(PII 266) NTFS share as well, to evaluate its usefulness as an alternative.
I thought that someone else might find the results interesting, possibly
even useful, although your mileage will vary. Here are the numbers:

ftp to the NT server:
 130532431 bytes sent in 1207.25 seconds (105.59 Kbytes/sec), 235.308 FTP
CPU seconds
and the smbclient put to NT workstation:
 putting file ../FTPFILES/BAT1 of size 130532431 bytes as \BAT1 (96.8448
kb/s) (average 96.8448 kb/s)

The throughput was only slightly lower, 8.28%. Too bad smbclient doesn't
(AFAIK) offer better recovery or setting variables, as ftp does. I cannot
guess what difference the processors make, although that is not our
'bottleneck' in this process. If the processor speeds are significant, then
ftp's advantage begins to look significant.

Also, I cannot readily tell the condition of the network traffic during
nightly batch processing, although experience tells me that it is
non-trivial, and can change during a twenty minute file transfer. I * may *
be afforded the opportunity to test more, so feedback and recommendations
are welcome, off list or on.

ATOM RSS1 RSS2