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=23853&t=23853 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
