Darrell, I guess you're right about the T1. Assuming that only about 1 mbps of true throughput is achieved, 26 minutes is easily within the realm of possibility. I just downloaded a 4MB file over a T1 (and it's shared by quite a number of folks). It took 31 seconds. Extrapolating, 200MB / 4MB = 50 x 31 sec = 1550 sec / 60 = ~26 min.
Huh! Checking that math, 200MB = 208,715,200 bytes = 1,677,721,600 bits / 1 mbps = ~1678 seconds / 60 = ~28 minutes. Huh! Tuning the TCP stack is always a good idea. However, assuming your example of 80ms RTT, here's where you should start having problems: throughput = window size / RTT throughput = ?? standard Microsoft window size = 65,536 bytes or 524,288 bits RTT = 80ms or .08 sec 524,288 / .08 = 6,553,600 So up to ~6.5 mbps (w/ 80ms RTT), TCP flow control probably isn't an issue. I think that's what you were saying. But, as we all agree, that sucks for a T3. Further indication that there's a bottleneck somewhere beyond the immediate connectivity... Darrell Newcomb wrote: > > ""Priscilla Oppenheimer"" wrote in > message > news:[EMAIL PROTECTED] > > s vermill wrote: > > > > > > Nate wrote: > > > > > > > > We've run a bandwidth test on our DS3 with nothing > connected > > > to > > > > it but a > > > > workstation (and obviously a router/pix). We went to > > > > testmyspeed.com as > > > > well as dslreports.com. We both got very good bandwidth > tests > > > > (upward 6m/s) > > > > however in transferring a 200m file to/from a workstation > > > > behind the > > > > connection, we got over 30 minutes while our existing T1 > got > > > 26 > > > > minutes. > > > > Anyone mind explaining this phenomenon? Just a side > note, we > > > > have no > > > > encryption between GRE tunnels. Thanks in advanced. > > > > > > > Since he said he tested with those other tools and got 6m/sec > (I guess he > > meant 6 megabits per second which is OK, thought not great), > the file > > The above is what I key'ed in on as the last test transfer he > had done over > the new path. Which is why I had originally suggested to tune > tcp(the URL's > below the jokes were seen weren't they?) since a single tcp > session at 6Mbps > crossing the continent(country) could be within expectations. > In most stock > tcp's and a 80ms RTT he would need a packet loss rate near > .02%(.0002) to > get 6Mbps. Nothing unrealistic about those numbers and it > seemed to me > someone just wanted to see 40+ Mbps numbers. But I overlooked > the part > about 30minutes over the DS3. > > Regarding the concerns about the 26 minute T1 transer. Maybe > I'm a little > too sleep deprived from doing datacenter moves, but I don't see > the issue > with.... > 26minutes for a 200MB(bytes) file is roughly 1Mbps, don't > forget overhead > too. That's completely within norm for a single TCP session > between two > reasonably distant endpoints bandlimited by a T1. > > Back to the DS3 being slower for this one. As everyone has > been saying > break down the problem. My guess would be you've got some > major performance > inhibiting thing like a duplex mismatch somewhere and by being > able to ramp > up transmit speeds quicker the session is smacked back down due > to the > loss(from duplex mismatch). What might be the simpliest > suggestion for > testing is to start up the file transfer and while it's running > do a > traceroute(large packet size if you could) from one end-host to > the far end > and see if you notice a place of particularly high loss to go > look at. > > My appologies for overlooking the note about 30minute 200MB > transfer over > DS3(not T1), > Darrell > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=65935&t=65790 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
