T1 speed

kendalle01 · ‎02-03-2005

we have a dedicated t1 between offices...

I'm doing a test using vsftpd 1.1.3...

is 90-100 KB/s an acceptible speed. My math is bad but I thought...

1.5 MB/s on a T1 is around 1536 KB/s. Hmmm....

Georg Pauwen · ‎02-03-2005

Hello,

I assume you are using Cisco routers...by default, the actual available bandwidth is 75%, since 25% is used for control traffic. This means 1175 KB in your case, which is still much more than what you seem to get. I would get with your provider, have them check if that dedicated T1 is really dedicated. Oversubscription is a common practice...I have also had a case where the provider had accidentally configured all traffic as lowest priority, which caused the (E1 in this case) connection to be really really slow...

Regards,

GP

Aaron Harrison · ‎02-04-2005

75% of the bandwidth available for use?

Surely that isn't true? You have a soft limit of 75% of the bandwidth available for QoS (i.e. priority queuing or whatever) but this is there to stop control traffic being starved... and event that limit can be changed...

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

smif101 · ‎02-03-2005

Well if you are downloading at 100KB/s that is actually 800Kbps. Remember computers transfer at the byte level so you have to multiply that by 8. As far as this being a good download speed between computers that has many factors, like the computers themselves, the protocol being used and other traffic across the WAN link. What I would do is check the utilization on the T1 while downloading a file that is pretty large and see if it goes close to 100%.

frennzy · ‎02-03-2005

A T1 has a maximum bit rate of 1.544Mbit/s.

Bit rate has no one-to-one connection with how much data (actual payload) you can transfer. It's not a fixed 75%, as mentioned above...there is no 'reserve' for overhead. Overhead is a function of MTU, fragmentation, type of data, and nature of data requests, among other things.

A good rule of thumb is to take your line bit rate (in this case, 1.544Mbit) and divide by ten. This accounts for a decent 25% overhead rate. In you case, this would mean you should see an maximum average payload rate of 150KB (note the upper case 'B', for bytes) per second.

If you aren't getting that, then there could be several reasons. There could be errors on the line. There could be other transfers competing for bandwidth. The client or server could be running into a local bottleneck of some kind (disk thrashing, lack of memory, out of buffers, etc).

You'll need to get a better look at what is actually traversing the link to know which is the case.

edited: typo...decnet to decent...don't want to confuse anyone.

kendalle01 · ‎02-04-2005

OK, in my research here's where I discovered my error. In telecom speak a 1.54 Mbit/second is 1,540,000 bits per second (telecom uses multiples of 1,000 and not 1024).

I opened an vsftpd session between my local office and the remote site over the dedicated T1. I then used the following command to send data.

ftp > put "| dd if=/dev/zero bs=1024 count=1024" /dev/null

Here's an example of the numbers and math I crunched out.

the following was sent in 41 seconds...

4194304 byte file * 8 bits/byte is 33554432 bits

1.54 Mbits * 1000 kilobit/Mbit * 1000 bit/kilobit is 1,540,000

So a 33554432 bit file / 1,540,000 bits / sec = 21.7885 seconds

Without any overhead I should be able to send that file in about 22 seconds versus 41 seconds.

frennzy · ‎02-04-2005

Quote: 'Without any overhead....'

But you do have overhead. So let's remove 25% of the available bit rate...which leaves us with about 1158000 bits per second. Your file now looks like it should take about 29 seconds.

Now, add in the fact that since this is an active, existing link, you are going to have constant traffic in the form of OS broadcast/announcements, routing protocol updates (possibly), other inter-router communications such as CDP, etc. Each of those things takes up a portion of the bandwidth. It's also entirely possible that the link is being used to transmit other user's data (email, files transfers, client-server application data, etc).

Furthermore, it's possible that the routers on each end of the link are doing some form of traffic shaping, QoS, or other data transfer behavior modification.

It's *also* possible that the link isn't actually a full T1...

To my mind, in a production environment, the data transfer rate you are getting is pretty decent.

Do you own/have access to the router themselves? If so, you can check the interface statistics to get a more detailed view of what is going on.

kendalle01 · ‎02-04-2005

Thank you for all your help. I simply wanted to reassure myself that my math wasn't way off and that the numbers sounded reasonable. XO still will be checking the lines and I will look into the interfaces at the routers themselves.

Kevin Dorrell · ‎02-04-2005

Just weighing in with a couple of points.

Firstly, I think the 25% for overheads is just a distraction. It is a conventional amount used by EIGRP and some QoS when making their cacluations. It does not mean that the interface will necessarily have 25% overheads - it's just a rule of thumb. If you have no routing protocols, you will have almost zero overheads, and you will be able to use the line up to well over 90%.

Secondly, I don't think banwidth is the limiting factor here at all. I think it is much more likely that the flow-control window is closing on your (single) FTP session, in which case end-to-end latency is much more the limiting factor.

(That is, assuming you do not have any queue drops or CPU limitations on the way.)

I reckon you are getting a pretty good throughput for a single FTP. If you really want to hammer the bandwidth, you need to run several FTPs and other traffic all at the same time, preferably to a variety of different destinations, and still keep an eye out for discards.

Kevin Dorrell

Luxembourg

scottmac · ‎02-05-2005

Get a copy of "QCheck" from ixia.com. It's free.

Qcheck should be loaded on two PCs (endpoints). Qcheck will give you stats for throughput, latency, and packet drop and will test the entire link between the endpoints.

As mentioned, there are more factors to the transfer of information than just a single link "speed."

QCheck is pretty accurate ... it's the baby brother of Chariot; an application used in the industry for performance testing and modeling (Big Bucks $$$).

You should also be able to get bandwidth / utilization reports from your provider (either by calling the support center or possibly on the web).

Is this "T1" a point-to-point, or Frame-Relay? If it's frame-relay, what is the CIR?

Many frame providers are policing their clouds pretty tightly these days. If you run a sustained burst above CIR, some of the traffic can be / will be dropped causing re-transmissions (with an apparent slowdown of the traffic). If this is the case, you may want to (you should) implement traffic shaping to pace the traffic such that you do not violate "excessive burst."

Good Luck

Scott

Kevin Dorrell · ‎02-06-2005

But be aware of the limitations of Qcheck when testing bandwidth. Here is the FAQ:

http://www.ixiacom.com/support/q_check/faqs.php#LowResults

Note that it limits its data to 1 Mbps, and many TCP implementations have a maximum TCP window of 8 KB.

On the subject of the TCP window (again), 8KB is equivalent to about 40 milliseconds of transmission time on your T1. What do you reckon the round-trip delay is (including store-and-forward latencies) in your test setup?

Kevin Dorrell

Luxembourg

scottmac · ‎02-06-2005

Kevin:

The FAQ says it only sends a MegaByte of data, and that the Windows default TCP window is 8K. Here's the quoted text from that FAQ:

[Quoted from the Ixia FAQ]

"Qcheck, so as not to swamp your network, is intentionally designed to generate small, brief data flows; it's limited to a single connection and sends no more than 1 MB of data. "

and

"The TCP Receive Window is a TCP/IP stack configuration parameter. Many TCP/IP stacks ship with a default value of 8 KBytes. "

[end of quoted text]

Certainly, QCheck is not the be-all, end-all testing suite ... but for free, it does a pretty good job for LANs and WANs for a quick status check.

There is also no (programatic) reason that you can't run multiple endpoints to stress the link and see which computers "win" the bandwidth during contention.

If the endpoints are running with 8K window sizes, it'll affect all of the data, not just the QCheck stuff.

There's a utility available at http://www.broadbandreports.com called "Dr TCP" that will allow the user to change the TCP/IP defaults without having to get into RegEdit and hacking the registry.

I know you know this stuff; I'm just trying to clarify it for the newer folks. Your posts are top-notch (and appreciated!).

FWIW

Scott

Kevin Dorrell · ‎02-06-2005

Scott,

Thanks for that information. I'm sorry if I came across as a bit dismissive of the tools. It wasn't intended - I'm just reacting a bit negative at the moment for some reason.

In fact, both QCheck and DrTCP are both quite new to me. QCheck does look like a valid tool for assessing network performance, and in fact it would be useful for some traffic studies I want to do, as soon as I get properly back into gear.

And I take their point about limiting the data to avoid too much impact on live networks.

Thanks again for your comments.

Kevin Dorrell

Luxembourg

kendalle01 · ‎02-07-2005

Well, the end of the saga? I contacted our provider, XO and between themselves and SBC they shook the line several times and now we're doing 175 KB/s.

If I look at a sample file that I sent in bits...

33554432 and divide by bandwidth 1,540,000-gives me roughly 21.8 seconds that (barring any restrictions) I should transmit that file

I'm doing around 23 seconds so I'm pretty happy.

Thanks for all the responses; every one of them was helpful.