North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
RE: Peering point speed publicly available?
Latency does have a impact on TCP transfers, now granted the difference between a oc-3 and oc-192 is negligible, but if you stack a lot of T1 connections back to back its going to be a factor in your max throughput across the path. (Stats below might not exactly be accurate...snipped from another site) DS3: (1500 bytes * 8 bits/byte) / 44040192 bits/sec = .27 ms (approx) DS1: (1500 bytes * 8 bits/byte) / 1572864 bits/sec = 8 ms (approx) DS0: (1500 bytes * 8 bits/byte) / 65536 bits/sec = 183 ms (approx) If you don't think it does then run some ftp transfers end to end with 1ms of delay, and with 100ms, 200ms, 500ms, 1000 ms I never said that .002 microseconds is going to have a noticeable difference, but those 10ms - 20ms hops starts to add up. As well as propagation delay as you stated. -C -----Original Message----- From: Richard A Steenbergen [mailto:firstname.lastname@example.org] Sent: Thursday, July 01, 2004 7:30 PM To: Cody Lerum Cc: Tony Li; email@example.com; firstname.lastname@example.org; email@example.com Subject: Re: Peering point speed publicly available? On Thu, Jul 01, 2004 at 07:05:51PM -0600, Cody Lerum wrote: > > Work with the network operators on each side of the link to determine > the speed/load. For the most part if they really want your business, > they will be able to provide something. Actually, many larger peering relationships come with contracts which explicitly forbid them from telling you any details about link capacity or utilization, or in some cases even acknowledging that peering exists. They might tell you anyways though. :) For the most part, it is hope for descriptive DNS or bust. For the most part, DNS is not descriptive (especially on peering links). :) > The main reason link speed maybe important to me would serialization > delay on the circuit. OC-768 should be much lower latency than a > T1...unless your are at the end of the queue :-) Once you get past 10Mbps, serialization delay is measured in fractions of a millisecond. This has absolutely no impact on TCP performance, compared to speed of light delays (like from oh say a 50ft patch cable). > Latency is probably be your primary concern for large TCP transfers > anyway. I think that you are very confused about how TCP works. > > 4 t3-1-2-0.ar2.SEA1.gblx.net (126.96.36.199) 20.436 ms 18.309 ms > > 17.605 ms <------------DS3 > > 5 so1-0-0-2488M.ar4.SEA1.gblx.net (188.8.131.52) 17.607 ms 16.982 > > ms 16.971 ms <-----OC-48 > > 6 p3-3.IR1.Seattle-WA.us.xo.net (184.108.40.206) 17.864 ms 19.491 ms > > 17.181 ms Name: p3-3.IR1.Seattle-WA.us.xo.net Address: 220.127.116.11 Name: 18.104.22.168.ptr.us.xo.net Address: 22.214.171.124 Sometimes you can find descriptive DNS on the other side of the PTR, and sometimes you find missing data. In this case, there is no speed description at all. The p3-3 interface indicates that this is a PoS interface, probably Cisco, and the IR designation on XO indicates a peering router. Educated hunch based on what the traffic levels between 3549 and 2828 in Seattle probably are... OC3? -- Richard A Steenbergen <firstname.lastname@example.org> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)