slow TCP connections due to very different speed of segments?
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||||||||
|
Posted by on March 10, 2005, 5:08 am
Please log in for more thread options Hello group/list, I've checked the FAQ but I couldn't find any reference to this issue. Our campus LAN is mostly Gigabit Ethernet fiber and 100 Mb/s UTP distribution, but we still have some distribution done to remote parts of the campus done over LRE (long range Ethernet), which is much like a "local DSL". It's supposed to give 10Mb/s under the best conditions AFAIK. People from these remote locations complain that traffic to servers on the core network is very slow. I've ruled out problems at client or server side. I've tested file transfers across the LRE segment and across the Gb Eth. segment. Their speeds were close to the expected max, so this (I guess) rules out problems on the segments themselves (esp. the LRE). I'm starting to wonder whether the big drop in speed between the two segments isn't the root cause (I mean, a 1Gb/s and a 10Mb/s segment). Would Ethernet gurus be so kind to comment? (I'm a poor system admin, acting as a network admin!). The exact topology is as follows: (Core LAN) | [Cisco Catalyst 4006 L3 switch] | 1Gb/s Eth fiber | [SMC L2 switch] | 100 Mb/s UTP | [Cisco LRE 29xx switch] | phone cable | [LRE end equipment] | 100 Mb/s UTP | (client PC) Thanks in advance for any comment, tip etc. NOTE: the From: e-mail address is a dead one. Please post. Greets, _Alain_ | ||||||||||||||||
|
Posted by on March 10, 2005, 4:32 pm
Please log in for more thread options There is no issue with the speed mis-match that you describe. TCP was designed to operate in that environment and as is witnessed by the internet and other WANs does actually does so. Performance problems are always tricky, if you don't know quite a lot about how this stuff works and can use tools like packet sniffers and interpret the results it could be quite difficult. 1. The absolute first thing is to check the counters on all of the equipment to see of there are errors accumulating. Fix them. Any on Ethernet will most likely be caused by duplex mis-match. The error rate is basically zero on this kit now and less than 1 in a million is OK. TCP is very good at recovery and can hide much higher rates. On LANs most ports have zero errors *ever*. 2. Make sure that the performance is not actually as designed. This is much harder. For example some users may complain that windows file copies are very slow when they drag a directory across the link. It casn take many net transactions to get even one file across so the performance degrades quite quickly with hops and or other latency and or slow links. Eg to copy a file windows might do: I made the details up but it is pretty close (I think). Hello is filex there - wait on reply Hello are you still there - wait on reply Open file - wait on reply Close file - wait on reply Open file - wait on reply Read first block - wait on reply there was only one block so: Close file - wait on reply. Thats 7 transactions just to copy one tiny file. Windows also keeps its explorer widow up to date so that can be another load of transfers. You can see this with a sniffer^h^h^h^h^h^h^h Ethereal. I am now a convert. FAB. | ||||||||||||||||
|
Posted by Robert Redelmeier on March 10, 2005, 4:49 pm
Please log in for more thread options
alainjean@ifrance.com wrote: Gee ... people complain? :) > I've ruled out problems at client or server side. I've
> tested file transfers across the LRE segment and across the > Gb Eth. segment. Their speeds were close to the expected max, Both directions? When users were complaining? I typically run ttcp and ping > I'm starting to wonder whether the big drop in speed between
> the two segments isn't the root cause (I mean, a 1Gb/s and a > 10Mb/s segment). AFAIK, ethernet itself isn't the issue, but that Crisco bridge may be. TCP/IP has a discovery mechanism that can work well, but hasn't always been well implemented (especially MS-Win9*). I also believe some of the newer p2p apps use UDP. You may need to sniff the link. It gets into Quality-of-Service issues, but if someone is hogging that 10 Mb/s line, everyone else will suffer. Paradoxically worse (latency) if the Crisco or LRE has big buffers. -- Robert | ||||||||||||||||
|
Posted by Rick Jones on March 11, 2005, 1:09 am
Please log in for more thread options
> It gets into Quality-of-Service issues, but if someone is hogging
> that 10 Mb/s line, everyone else will suffer. Paradoxically worse > (latency) if the Crisco or LRE has big buffers. Of course, if the buffers are too small - say smaller than they typical TCP windows being used, a burst of traffic from the fast side may fill the buffers and overflow. Checks of the statistics might be in order - both netstat on the end systems and link-level on each side of that 10 Mbit/s pipe (or anywhere there is a speed change I suppose). rick jones -- The computing industry isn't as much a game of "Follow The Leader" as it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose." - Rick Jones these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... | ||||||||||||||||
|
Posted by on March 10, 2005, 10:45 pm
Please log in for more thread options
Thanks to you Robert, FAB, Rick for all the input. I'll do another pass of investigation based on your comments, but here are a few more words on this, though: - duplex mismatch: I've checked this all along the path, no duplex mismatch (esp. the UTP link between the SMC and the Cisco LRE switch) - this problem seem to happen all the time. When I've done my tests, I've used ftp transfers (from Unix boxes, so that I know at least that the ftp server is decent). Yes, the slowness was in both directions, although, as expected, download was always signficantly faster than upload. Ping times were normal. I'll try ttcp too, thanks. - I've concentrated on one complaint from one user who's making ftp transfers only... we don't allow P2P on the University campus anyway :-) - the LRE links are not shared, so no one can be hogging them My guts feeling is that somehow data gets pushed too fast over the fast link and that either of the SMC or Cisco LRE switches drop frames. I understand that normal TCP window mechanisms should take care of that, but I suspect that they don't, somehow, and I'm not sure how to check this (where can I find something about this in netstat output BTW?). Any new hint is welcome, I'll followup after a new round of checking counters and such. Greets, _Alain_ | ||||||||||||||||
| Similar Threads | Posted |
| slow TCP connections due to very different speed of segments? | March 10, 2005, 5:08 am |
| UTP 'segments' | March 10, 2005, 11:41 am |
| repeaters recreate signals to other segments, why not reflections? | September 12, 2007, 3:17 pm |
| Slow down of internet service | November 27, 2005, 7:08 pm |
| Using Jumbo Frames & Gigabit - Actual BPS is slow ! | September 17, 2004, 10:39 am |
| slow smtp issue/packet capture | December 18, 2006, 10:24 am |
| killing ethernet connections | October 28, 2005, 2:02 am |
| multiple connections between 2 switches | October 30, 2007, 5:45 am |
| Dropped packets/broken TCP connections | August 23, 2006, 9:48 am |
| VLAN 2 Internet Connections. Send PC's down 1 ISP, VoIP phones down 2nd ISP | April 1, 2006, 8:08 am |
| baffling speed problem | July 23, 2005, 5:52 am |
| Network Speed Question | September 2, 2006, 5:31 am |
| network card speed | February 8, 2007, 10:32 am |
| Software to test network speed? | September 9, 2004, 9:05 pm |
| Speed limit of Fast Ethernet | November 22, 2005, 7:39 am |
> to servers on the core network is very slow.