# How Fast is a T1? really.

Discussion in 'VOIP' started by john, Nov 29, 2004.

1. ### johnGuest

Hi all:

I just successfully turned up a T1 from NYC, US to Manila, Philippine.
Both routers are Cisco 2600.

The ping time is about 268ms, every time.

My questions:

How fast is a T1 really? we're going to do VOIP and we're going
to use g723 codecs and we want to know how many "agents" can
be on the T1. I heard someone once said that a T1 is about 200k
per second.

What is the usual ping time from here to a country like Philippine or
India, anyone knows?

Thank you all!.

john, Nov 29, 2004

2. ### Erik FreitagGuest

Well, a T1 is 24*64K=1536Kbs + 8Kbps for telco overhead, but I think
simplifying assumptions (speed of light in fiber at around 2/3 vacuum =
200000 km/s, no latency in telco equipment), this means that the network
distance from New York to Manila is about 33000 - 34000 miles. Seems a bit
long for a planet with a 24000 mi diameter, unless you're going the long
way 'round. So there's probably a bit more latency in the network hardware
than 0, or your carrier's equipment or your own network is a bit slow.

The point is that latency is basically distance sensitive, not bandwidth
sensitive. A circuit running at or near capacity may have longer latency
than the same circuit running at low utilization, but that circuit has a
minimum latency determined by distance and equipment. As long as you're
running over fiber or copper, you're limited by the 200000 km/s number.

You're question caused me to do an Internet search on comparative T1
latencies for different carriers and distances. I could not find a good
reference. I would appreciate a pointer if anyone has one (also for T3).

Erik Freitag, Nov 29, 2004

3. ### John R. LevineGuest

I just successfully turned up a T1 from NYC, US to Manila, Philippine.
No kidding, the air distance is about 8500 miles. 1/4 second sounds
about right for a geosync satellite hop. It's hard to imagine why
you'd get a satellite link with the glut of fiber, but it should be

John R. Levine, Nov 29, 2004
4. ### Erik FreitagGuest

Got a correction from
I was wrong, and this is correct, so the "network distance" is really
16500 - 17000 miles. Or about twice the actual distance, so it still
sounds a bit slow. Do you have engineering documents from your carrier?
They might have some hints.

Erik Freitag, Nov 29, 2004
5. ### johnGuest

Hi all:

Thanks for the fascinating information. I could ask the carrier to see
what they have. Is there something specific that I can ask from them

Maybe I should set up an ftp server on the US or Manila side and
do around 10-20 ftp sessions and average out the result to find the
"real" speed.

TIA.

John.

john, Nov 29, 2004
6. ### ScoobyGuest

My first assumption was that this must be an internet T1 with VPN. However,
reading again it seems like you have installed a private T1??? I would
think that would be a very expensive proposition. If so, first check the
throughput on the circuit. If it is being heavily utilized, then you would
see higher ping times - QOS would probably fix this. If there is low
traffic, check with your telco to see what they have for an SLA. I'd assume
that they would be surprised to hear these results and you should
troubleshoot together with them to figure out where the problem is - it

One consideration is - what else are your routers doing? While 2600's (even
the older models) are plenty of router to handle a full T1, if it has too
many other things it is doing, it could degrade your system performance.

BTW - FTP tests will not show usability for IP Telephony, although they
might signal other bigger problems. Since TCP is just happy to have the
packets arrive in any order with high latencies, what you are experiencing
may not affect the transfer much - some, but not a lot. On the other hand,
such high latency with IP Telephony would cause serious jitter. Even with
QOS, the calls are likely to be very poor quality given your current
situation. Throughput and latency are very different issues.

An interesting/funny article for the Shark Tank fans out there:

http://www.computerworld.com/departments/opinions/sharktank/0,4885,97552,00.html

Scooby, Nov 29, 2004
7. ### Erik FreitagGuest

guarantee for this T1. Loading up the circuit with a lot of ftp sessions
will tell you how bad the latency can get (it will go up as you congest
the circuit), but it will never go below the minimum for the circuit,
which looks to be about 268 ms (or 134 ms one-way).

You could ask them for their network documentation - somewhere, deep in
the archives, they have a text document or drawing (or set of them) that
shows each leg of the T1, and the equipment at each end. You can also ask
them to test the T1, but NOCs are usually only set up to check
connectivity and clocking, not latency - if that's what you're worried

One of the carriers I've worked with guaranteed 80 ms for continental US
Internet traffic as long as it stayed on their network, and I think 100 ms
for traffic within western europe. They had no guarantee latency between
US/Europe (or US/Asia/Pacific).
getting a full T1 worth of bandwidth, the ftp test might work. You could
start a lot (5-6) of largish (1000 byte) 100000 packet ping sessions. Do a
couple of show interface commands while the sessions are running and see
if you get to 1500000 bits/second or so. This is closer to testing just
the T1. If you use ftp, you're also testing your servers, their disks, and
the internal network leading up to the T1.

Erik Freitag, Nov 29, 2004
8. ### T. Sean WeintzGuest

Ping latency has nothing to do with the speed of the line. Latency has
to do with the speed of routers and switches on the route.

Sincve I seriously doubt you actually have a pt to pt T1 between the US
and phillipines, you must be going over frame relay, atm, vpn, or
something. Need to know extacly how the T1 connects you to the
phillipines to be able to say why the latency is so high.

T. Sean Weintz, Nov 29, 2004
9. ### TobyGuest

Hi John

Firstly a true T1 is a point to point link and can not slow down or speed up
so without congestion causing delays inside the router due to queing or CPU
exhaustion all traffic should reach the destination in the same time.

The speed of a T1 link is 1.544M unchannelised or 1.536M if channelised into
24 slots.

As for RTD if this was a true T1 link and we can ascertain that the
local/remote routers are not under any processing strain due to any other
connections etc.and we were not trying to overutilise the link from time to
time (no queing) then this would not vary. The bulk of the RTD would be
propogation delay. i.e. distance related and can only be improved by
shortening the distance. I hear people whince here as we can't move the US
closer to the Philapines. The truth is though that the cable routing might
not be as straight as you think (but this is probably not your problem). All
assumtions in this news group have been based on your testing (quite
rightly) but can you confirm you are only testing the link by pinging the ip
address each end of the link. If this is a proper T1 link then there is no
real need to try to load the link for this as you cant slow down a T1 link,
the RTD should be pretty constant, again assuming no CPU/Queing problems.

Some good fellow on this thread has done a lot of maths and concluded that
this must be a really long routing to get the RTD you are getting. which is
good evidence that you havent got a dedicated link at all to the phillapines
but a T1 link to a service provider to be onwardly forwarded via frame
relay/ATM etc. This will mean that your traffic will get switching delays as
contract. One sure fire way of finding out if you have a point to point cct
is to change the encapsulation type at both ends from what ever you are
using to a different type and see if it still works (sensibly with a planned
outage of course). If you are running frame relay encapsulation though you
can have a good guess by looking at the config of the 2 routers. On a point
to point cct then one router must be running Frame-Relay Switching and also
this routers interface will also be running Frame-Relay Intf-type DCE. If
they are not you are using a frame relay network in-between each site with
switches etc. There are probably checks for other types of encapsulation
also but I can't advise here.

If you ascertain that you are in fact running through other networks then
to your voip traffic over the link. This can be done in frame-relay via 2
pvc's being used one for voip and the other for data. but this can only be
the I'm afraid it's back to shopping around.

Toby

Toby, Nov 29, 2004
10. ### stephenGuest

If this is a "real" T1, then it may be protected by SDH - the numbers look
more like the circuit could be going "the wrong way" around the world -
which is quite possible with sdh and a telco not forcing the shorter
path....
ask for the circuit routing, and expected latency - then check if it looks
close to what you expect.

if you have internet access at both sites - try a ping via the internet to
compare the results.

i have seen a european cross border circuit routed via the US after a fault
which gave similar differences between expected and actual latency.
this houldnt affect the latency, but the ping results may vary if you start
having Qing in the routers.

stephen, Nov 29, 2004
11. ### H Brett BolenGuest

H Brett Bolen, Nov 30, 2004
12. ### johnGuest

This is what the carrier emailed me back:

It was technically provisioned via our Freeway Service which is our direct
connection to LA.

Freeway runs on ATM over C2C-JUNC cable routes.

-John

john, Nov 30, 2004
13. ### Hansang BaeGuest

300ms to parts of Asia from US is not unreasonable. But if you're doing
bulk file transfer over high latency pipes, you need to consider RFC
1323.

--

hsb

"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
********************************************************************
Due to the volume of email that I receive, I may not not be able to
********************************************************************

Hansang Bae, Nov 30, 2004
14. ### T. Sean WeintzGuest

Which doesn't tell very much, other than it is not a true point to point
T1. For starters what the heck are "c2c-junc" cable routes? Google
search on that term turns up nothing.

The latency is obviously occuring in the ATM cloud. Since I am not
familial with the topology of their "freeway service", I can't tell you
where or why.

T. Sean Weintz, Nov 30, 2004
15. ### TobyGuest

should expect from the US to the Philapines. With Layer 2 switching such as
ATM they usually can provide maximum figures.

You can expect that a pure T1 whould be the fastest as there are no queues
to manage and virtually negligable multiplexing delays. ATM uses a shared
network and as such will induce switching/queing delays and these can be
expected although ATM switching is very fast and queing is only due to
congestion either on your access link or within the SP cloud. It is
provided as a cheaper alternative to dedicated point-point links as it is
shared but still the service provider should provission there bandwidth to
accomodate the traffic levels expected and only penalise the abusers.

If the SP is not providing what they have prommised get them to re-route the
ATM PVC. If they are remember we can't change the laws of physics and also
shouldn't expect perfection on a budget. Of course you would still have a
claim if the service has been mis-sold to you on these accounts.

Toby

Toby, Nov 30, 2004
16. ### James LewisGuest

I would suggest the iperf utility instead of ftp for testing throughput.

James Lewis, Dec 1, 2004