From: Andrew Lee Lissitz (alissitz@corvil.com)
Date: Tue Apr 12 2005 - 18:35:11 GMT-3
I meant start a ping with the average packet size, not file size .... sorry
for the typo...
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Andrew Lee Lissitz
Sent: Tuesday, April 12, 2005 5:32 PM
To: 'Wayne Bellward'; 'Dillon Yang'; 'Cisco certification'
Subject: RE: File Transfer Speeds
Hey All,
Wayne, assuming that you are using the default window size, what is the OS
of the PCs? If you have edited the registry and changed the window size,
what is it? Do you know the end to end latency during the transfer?
While ping is not the best tool to determine latency, please start a ping of
the same size as the average file size for your transfer. FTP should try
and use the largest MSS it can, so pinging 1400 would be fairly true.
The theoretical max transfer speed is determined by the window size (WS) and
round trip time (RTT), so knowing these values are important. Here is the
formula for this: BW = RTT / WS.
Not to be annoying with these next questions, have you verified duplex and
speed settings for the PCs and switch ports? Is either the switch or PC hard
coded for speed and duplex? A duplex mismatch can slow a transfer to a
crawl... Are there any errors listed on the switch interfaces? The Netstat
command will show you errors (retransmissions) on the PCs
From what I understand, TTCP will allow you to poll the routers for latency
numbers. I have never used this
If your company apps run on TCP, then using TCP is a good choice for
testing... FTP is a greedy app, and will try and consume all available BW.
When testing throughput, FTP is a good choice because of its nature.
Wayne, do you know what BW your apps need? Kindest Regards Wayne and all,
Andrew Lee Lissitz
908.303.4762
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Wayne Bellward
Sent: Tuesday, April 12, 2005 10:55 AM
To: Dillon Yang; Cisco certification
Subject: Re: File Transfer Speeds
Hi Dillon,
The aim of the scenario was to emulate a LES10 circuit, hence the 10Mb Full
Duplex. I have now spoken to a to a few people and it would seem as Chris
Larson points out tcp based file transfer is a poor way to measure
performance. Someone has recommended TTCP utility
www.pcausa.com/Utilitie<http://www.pcausa.com/Utilities/pcattcp.htm>
s/pcattcp.htm <http://www.pcausa.com/Utilities/pcattcp.htm> either way this
is a subject I'm going to have to do some reading up on. If anyone has any
recommendations I'd be glad to hear them.
Many Thanks
On Apr 12, 2005 2:51 PM, Dillon Yang <dillony@gmail.com> wrote:
> Hi, Wayne:
>
> I can not understand the "10Mb Full duplex crossover" on 3550! Maybe
> you used a wrong cabling that caused the speed down. You'd show the
> interface to know whether there is lost packets.
>
> HTH
> dillon
>
>
> On Apr 12, 2005 7:11 PM, Wayne Bellward <wbellward@gmail.com> wrote:
> > Hi All,
> >
> > I have two 3550EMI's connected via a 10Mb Full duplex crossover, the
> > link is a 802.1q trunk and I only have about four VLANS running. When
> > I do an FTP of a 10Mb binary file between two hosts one on each switch
> > in different VLANS I get file transfer speeds of about 50KBs. If I
> > put the hosts on the same 3550 I get transfer speeds of about 85KBs,
> > CEF is enabled but either way I would expect to get transfer speeds
> > much greater than those I am getting.
> >
> > The 3550 has a 8.8Gbps switch fabric and a throughput of 4.4Gbps can
> > anyone explain to me why this is happening? I don't think there is a
> > problem with the switches or the hosts but get the impression I am
> > missing a fundamental aspect of switching.
> >
> > Many Thanks,
> >
> > Wayne
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue May 03 2005 - 07:54:57 GMT-3