Hi,
We are using Samba to transfer files from our main production server on the
east coast of Australia (NSW) to a site on the west coast, a distance of
some 5000 kms. Although we are using a 32MB ATM comms link we are
experiencing significant delays. Some consultants in the west gave us the
explaination cotained in the attached letter. Could you please confirm that
this is indeed the case and if there is anything that could help.
<<Samba at Western Diagnostic Pathology>>
> Regards,
>
> Rodney Tinsley
>
> Rodney Tinsley
> Mayne IT
> Western Diagnostic Pathology
> 74 McCoy Street
> MYAREE WA 6154
[EMAIL PROTECTED]
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
--- Begin Message ---
Hi Rod -
Andrew Howell requested that I examine the Samba performance of Perth
<-> Sydney compared to access within Sydney - specifically with relation
to the relative speed of copying files at the two locations.
When a file is copied using the Windows SMB protocol, besides sending
the actual file data, several setup and control transactions occur.
There is a significant difference between the two.
Briefly, file data is transferred in a stream. The significance of this
is that the sender does not wait for acknowledgement (within a limit) of
a transmitted segment before sending the next. The setup and control
transactions, however, must be acknowledged and/or responded to before
the next message is sent.
Samba averages about 10 control transactions (so 10 requests and 10
responses) per file transferred.
In Sydney, where the RTT (round-trip time) between offices is around
10ms, there is, therefore, about 100ms per file spent in protocol
overhead. In Perth it's five times as bad - with an RTT of 50ms, around
500ms is spent in protocol overhead. Add another 10ms in Sydney and
50ms in Perth for the transit time of the first segment of the file
(this is not a transaction, just straight-out delay in waiting for data
to start to arrive).
With small files (say around 10K), the protocol overhead is much more
significant than the actual file transmission for long delay links.
Assuming an ethernet sized MTU (1500 bytes), the data payload per segment
will be a maximum of 1460 bytes - so a 10K file will be sent in seven or
eight segments. If these were placed on the wire as fast as possible,
then the data transmission would take, say, 80ms on a 2Mbps link at full
speed, or 100ms in normal low-load circumstances. In Sydney the protocol
overhead and initial segment delay was 110ms and in Perth a huge 550ms.
Thus the total time to transmit a file might be 210ms in Sydney vs 650ms
from Sydney to Perth.
So you can expect copying files from Sydney to Perth to take about three
times as long as copying files within Sydney.
If you would like us to show this in some actual file copies, we'll need
packet dumps (collected with a tool like tcpdump or ethereal) from the Samba
server for a copy within Sydney and a copy from Perth.
I don't feel that there's any value in looking at other devices in the
network
path unless there are other issues which are yet unexplained. The RTT of
50ms
Sydney <-> Perth is very good indeed. It's only a few milliseconds worse
than
the theoretical limit imposed by the speed of light in fibre.
--
Stephen Darragh
Technical Director
Informed Technology
Ph: +61 8 9380 4244 Fax: +61 8 9380 4354
--- End Message ---
