Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!mtuxo!mtune!codas!uflorida!ukma!david From: david@ms.uky.edu (David Herron -- Resident E-mail Hack) Newsgroups: comp.protocols.tcp-ip Subject: ftp hang while trying to talk to cu20b.columbia.edu Message-ID: <8377@g.ms.uky.edu> Date: 17 Feb 88 07:25:46 GMT Distribution: na Organization: U of Ky, Math. Sciences, Lexington KY Lines: 60 I'm experiencing some strange hangs while attempting to ftp files from cu20b. Specifically, the pattern is that I make the connection, log in as anonymous and david@ms.uky.edu as the password. Then I start transferring some data (either a directory listing or an actual get command) and after some short time (approximately 15K worth of data has been transmitted) the transfer hangs and stops doing things. Running tcpdump to watch things and telling it to restrict itself to the ftp port, sure enough the packets simply stop going by after a time. The local machines I have tried this from are an 11/750 with deuna running mtxinu 4.3+nfs (we're one MR behind the current version), uXavII's with DEQNA's and the same OS, Sun 3/something running 3.4, and uVaxStation2000's with whatever the ether hardware is and the next-to-current version of Ultrix. Our sequent didn't know how to reach that network so I wasn't le to try from that machine. Using ping, I get an response times like 250 ms at best, 2500 ms at worst, and 600-700 avg and with packet lossage at somewhere between 5% to 30% depending on the tides, or some other somewhat unrelated/unknown effect. I'm doing these transfers at night most recently at 3AM on a saturday morning. Our net is an ethernet attached to a proteon p4200 ip router which is the gateway to suranet/nsfnet. From there we go through some gateway in wash dc (maryland?) to get to net 10. One thing we've noticed recently on our net is something which may be rwho related broadcast storms. I haven't traced this down yet, but will be doing some tracing on this in the next couple of days. One thing I notice from ping is that occasionally there are bursts of packets being lost and surrounding the lost packets are long ping times. um, some hard facts gathered with ping. I watched for about 5 or 6 minutes just now. Every minute like clockwork we'd experience some packet loss, and generally for the next 20-30 seconds the ping time would be much worse than the rest of the time. But there was enough variance in the details of what happened, as well as variation in other parts of the minute, that it's not completely clear what is happening. I did see one extreme example in that time where we lost about 40 packets and didn't have ANY pings come back for about 30-40 seconds. This does seem to be extreme lossage ... however, isn't tcp supposed to be able to handle loss of packets and do re-transmissions? Why is tcp getting wedged? Or possibly is it something in the way that ftp works? (I must admit that I know very little about how ftp operates other than it runs using two tcp channels, one for data transfers and the other for commands). Any ideas? -- <---- David Herron -- The E-Mail guy <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- It takes more than a good memory to have good memories.