cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
722
Views
0
Helpful
9
Replies

Utilizing T1 Bandwidth

c-p
Level 1
Level 1

Hi,

Currently, we have a T1 that is underutilized and we pass mass amounts of data through each office vie NetBIOS file transfers (drag and drop type stuff through Windows Explorer). In this case, I'm wondering how I can force the T1 to take up more channels when passing traffic between offices in order to get better throughput than my current 170k/sec rate.

Setup: We have a Point to Point T1 between offices 3 blocks away. Both routers are 1700 series w/CSU-DSU built-in. IOS is 12.1 (8a) on both with 24576K/8192K bytes of memory.

Another approach I'm researching is to break up the files in order to distribute the work through more channels on my T1 line. For example, instead of using a DAP like product, I'd like to use either the router or the CSU/DSU to break up up the files in order to spread the copy process (over my T1 between offices) to more channels.

In all recommendations from Cisco, the papers/books reference Queuing to prioritize traffic, but this does not quarantee bandwidth usage, only that my higher priority traffic will go through first. I'm specifically looking to utilize more channels to pass traffic on a per copy basis eith by allocating more channels to my traffic (NetBIOS in this case) or by breaking up the files and distributing the load across more channels. I would imagine if someone could write an app that does this for FTP downloads, Cisco would have someone out there who knows how to do this with Cisco routers.

Does anyone have any clues on this?

Thanks everyone,

Chris Palazzolo

9 Replies 9

svermill
Level 4
Level 4

How are you measuring your throughput?

We use MRTG to measure the traffic between the routers.

Both side have a typical 2 gig copy process running at about 170k/sec

If we start abother copy process, it will run about the same.

-CP

MRTG by default measures bandwidth in bytes vs. bits. When you say "about the same" do you mean that what you see on MRTG stays the same or do you mean that an eqaul amount of additional bandwith start being consumed? 8 x 170 = 1360 -- very nearly a T-1. There is an option that can be set in your MRTG config file to change from bytes to bits.

To be honest, I measure at least two ways: MRTG and AnalogX's NetSTAT Live. Both show up as 170kb/sec (or around that measurement).

The key here is to divide a normal copy process (say a set of folders equaling 1 gigabit in size) across more channels on the T1 to utilize it more or dedicate a certain amount of bandwidth for specific NETBIOS traffic.

Thanks,

c-p

As has been pointed out, Netstat Live is in bytes by default also. As for channelizing your T-1, that isn't really feasible. The 24 timeslots are from the old voice channel days. When you use a T-1 for purely digital traffic (non-frame relay of course), it is one big multiplexed pipe. I suspect that you are getting full utilization as it is now. Why don't you do some quick math and time the transfer. I suspect that you'll find the file transfers much more quickly than what youf calculations for a 170 kbits transfer would be. It will probably be around 15 minutes vs. the 2+ hours it would take at 170 kbits/sec.

Regards

faheyd
Level 1
Level 1

Hi Chris,

Please check if you are measuring bits or bytes, both MRTG and X use BYTES out of the box. If this is true, 170KB x 8bits = 1.3Mbits per second, not bad on a 1.544Mbit channel, considering protocol overhead, acks/nacks etc.

faheyd
Level 1
Level 1

Chris,

Could you please FTP that file and tell us what your bandwidth utilization is?

c-p
Level 1
Level 1

I wanted to complete this topic out.

After the adivse from everyone, we realized the T1 line is measured in bits (not bytes) and our line speed is doing well for us. I didn't realize it and overlooked that part.

Thanks to everyone for their help,

c-p

c-p,

That is very kind of you to write back and close things out. So many times people just drop off the air once they find the problem.

Best regards,

Scott