Yeah, try copying a 12 meg msfc .bin over a WAN link that has latency of
125ms.  So I only get to send 8 packets per seccond each as 512 bytes.
(1000ms/125ms = 8)  

tftp at the application layer is the one who sends the acks.  For some
reason I can't do a a "copy flash ftp".  I'm guessing because I don't have
anonymous login allowed on my ftp? Does that sound right?

Tim


> -----Original Message-----
> From: Chuck Larrieu [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, October 23, 2001 12:44 AM
> To:   [EMAIL PROTECTED]
> Subject:      Re: Slow wan link. TCP traffic "ok", UDP not okay. Please
> help! [7:23853]
> 
> validating this thought, I have had reason to upgrade my router pod IOS
> images of late. Cisco's router Software Loader uses TFTP to copy new
> images
> into flash via a direct ehternet to ethernet connection. copying 16 meg
> images takes an inordinate amount of time, especially considering there
> are
> only two devices on the network involved.
> 
> it would appear, then, that the router writes each packet to flash before
> requesting the next packet. at least that goes a long way towards
> explaining
> why the copies take several minutes on a 10baseT link with just the two
> devices connected via a crossover cable.
> 
> thanks for the insight
> 
> Chuck
> 
> 
> ""Priscilla Oppenheimer""  wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > One more (serious!) comment. I asked a protocol guru about the question
> of
> > TFTP being so slow. He agreed with the poster that the TFTP throughput
> > seems awfully low, but he agreed with me too that TFTP is not optimized
> for
> > throughput. He also mentioned one other stupidity with TFTP
> > implementations. He said that some actually write the 512-byte block of
> > data to the hard disk before ACKing and asking for the next block. So a
> > slow hard disk would cause problems.
> >
> > TFTP and UDP don't have a PSH bit like TCP has. With TCP, the sender
> would
> > output a bunch of data and then perhaps set the PSH bit which would tell
> > TCP to give the data (in RAM) to the application. At that point, you
> might
> > see a short hiccup as FTP wrote the data to the hard drive (not
> necessarily
> > because FTP could still keep the data in memory until the session is
> > closed; it's implementation-dependent.)
> >
> > TFTP is also implementation-dependent, but with some implementations,
> it's
> > one block at a time that is written to storage and then ACKed before
> more
> > data is sent.
> >
> > Since FTP works well, you have proof that the problem isn't with the
> > network. Can't you pass this onto the server or application people!? ;-)
> >
> > Priscilla
> >
> > At 02:34 PM 10/18/01, Priscilla Oppenheimer wrote:
> > >At 02:23 PM 10/18/01, Ouellette, Tim wrote:
> > > >Priscilla,
> >
> >
> >
> > > >
> > > >Thanks for the response.   Any idea as to why the TFTP protcol over
> our
> > WAN
> > > >will run at 4k/sec and FTP at 165k/sec.  I just figured that the
> smaller
> > > >packet size of UDP would help.
> > >
> > >Nope. That would not help. It would make the throughput worse.
> > >
> > > >  I also thought that UDP is connectionless and
> > > >thefor requires no ACKS.
> > >
> > >TFTP has ACKs.
> > >
> > > >   Other sites on our WAN I can transfer large files
> > > >via TFTP and they run at very good speeds.
> > >
> > >Have you done the same sort of comparison  of FTP versus TFTP at those
> > >sites. I bet FTP has much better throughput.
> > >
> > > >I'm just concerned about this one
> > > >site. Any other ideas?
> > >
> > >See the message from Phil Barker. It made some good points about TFTP
> and
> > >UDP in general not being tuned for WANs. The next step would be to put
> a
> > >Sniffer on it and see what's really happening. But there may not be
> > >anything abnormal happening. TFTP just kinda sucks.
> > >
> > >
> > > >Tim
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Priscilla Oppenheimer [SMTP:[EMAIL PROTECTED]]
> > > > > Sent: Thursday, October 18, 2001 1:23 PM
> > > > > To:   [EMAIL PROTECTED]
> > > > > Subject:      Re: Slow wan link. TCP traffic "ok", UDP not okay.
> Please
> > > > > help! [7:23391]
> > > > >
> > > > > This list either filters my answers or mangles them.
> > > > >
> > > > > I'll make another try here. It it comes out mangled again, I'll
> post
> it
> > > > > somewhere on my Web site when I have time.
> > > > >
> > > > >
> > > > > TFTP is a trivial protocol running on top of a trivial protocol
> (UDP).
> > >You
> > > > >
> > > > > shouldn't expect it to have good throughput.
> > > > >
> > > > > TFTP uses a block size of 512 bytes. The protocol is a
> command/reply
> > > > > (Ping-Pong protocol) with no windowing, flow control, etc. The
> protocol
> > > > > looks like this:
> > > > >
> > > > > Write Request->
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > If there are any problems, the application-layer TFTP notices a
> missing
> > > > > ACK
> > > > > and retransmits.
> > > > >
> > > > > FTP, on the hand uses TCP. It looks more like:
> > > > >
> > > > > SYN my segment (packet size) is 1500
> > > > > SYN ACK my segment size is also 1500
> > > > > ACK
> > > > >
> > > > > GET (FTP command), TCP receive window is 8,192 (or whatever)->
> > > > >
> > > > > Hey All. I was wondering if someone could help me out with a
> problem
> > i'm
> > > > > >working on. It's very weird to me and I can't find any reason why
> this
> > > > > may
> > > > > >be happening other than possible a Queuing issue. Please comment.
> > > > > >
> > > > > >           I've done some testing to show the response issues
> from
> > > > > spikinisse
> > > > > >to an auburn hills tftp/ftp box.  When a 9 meg
> > > > > >         file is copied from one of the 6509's in Spijkenisse
> using
> > tftp
> > > > > we
> > > > > >see a speed of 4k/sec (9041904 bytes copied in 2251.956 secs
> (4016
> > > > > >bytes/sec)
> > > > > >         However, when I ftp'd a 2meg file from a server in
> > Spijkenisse
> > > > > to
> > > > > >the same server in Auburn Hills, I see a speed of 166k/sec
> (2024013
> > >bytes
> > > > > >sent in 12
> > > > > >         seconds (166.12 Kbytes/s)   Seeing as in Spijkinisse it
> is
> > > > > >approximately 8pm and they have 4 E1's, there should not be an
> issue
> > >with
> > > > > >over-utilization.
> > > > > >         It intrigue's me as to how a UDP based application
> (tftp)
> can
> > > > > have
> > > > > >such a ridiculously slow speed of 4k/sec and a TCP based
> application
> > > > > (ftp)
> > > > > >has an
> > > > > >         average speed (considering 4 e1's) of 166k/sec.
> > > > > >
> > > > > >         Spikinisse has a group of E1's to the cloud and our site
> in
> > > > > Auburn
> > > > > >Hills has a full DS3 to the cloud.
> > > > > >
> > > > > >Spik is in the Netherlands, and Auburn Hills is in the US.  Any
> more
> > > > > >information I need to provide?
> > > > > ________________________
> > > > >
> > > > > Priscilla Oppenheimer
> > > > > http://www.priscilla.com
> > >________________________
> > >
> > >Priscilla Oppenheimer
> > >http://www.priscilla.com
> > ________________________
> >
> > Priscilla Oppenheimer
> > http://www.priscilla.com




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=24006&t=24006
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to