A Crash Course on Network Bandwidth Metrics?

Kind of Blue asks: "I work for a small software development company in India, providing development services for a company in UK. We connect to the UK client through VPN; and our correct staff strength is around 13. We are going in for a major upgrade in our internet connection — and owing to the size of the firm, cannot afford the services of a networking expert/consultant. Hence I, a layman, have been asked to look into the matter and decide on the ISP and the bandwidth. I have a vague idea about the required bandwidth — it must be around 512 kbps(remember, it's India I am talking about!) and must be a persistent connection, since we use source control softwares connecting to servers in the UK. There doesn't seem to be a 'networking for dummies' kind of resource on the web. No one seems to talk of network metrics anywhere. So, can Slashdot give me a crash course in what I need to know?" "Our present ISP gives us a DSL connection of 512 kbps on 1:4 sharing. There are frequent disconnections; and hence loss of work while code check-ins. As we are increasing in strength, I am also looking at more bandwidth. But what bamboozles me is how are these things measured? Will I get a better bandwidth if I take a 512 leased line on 1:2 sharing? When the staff doubles, should I upgrade to a 512 connection on 1:1 sharing or must I take 1 Mbps on 1:4 sharing?(There's a huge price gap between the 2 here in India) In any case, how does one decide the optimum bandwidth required for a bunch of 15 developers on VPN and Source control?"

Comments

Measure twice, cut once

[edmudama]

it must be around 512 kbps(remember, it's India I am talking about!) and must be a persistent connection, since we use source control softwares connecting to servers in the UK.

Have you actually measured how much bandwidth your source control software application consumes? To me that'd be the very first step, before you look into upgrading from one voodoo number to another. Real data is very often the key to good decisions.

Re:Measure twice, cut once

[Bastian]

Keep in mind - [i]bandwidth is not the same thing as speed.[/i] If your transfers are small enough that you're never really filling the pipe (as is probably the case if most of what you're doing is talking to a source code control system), then adding bandwidth won't make a bit of difference. It would be like using a box truck to pick up a your groceries.

For the kinds of usage patterns that source code control systems generate, latency is most likely going to make a bigger difference.

The classic example is the old saying, "Never under-estimate the bandwidth of a van full of tapes." It's true - the bandwidth of such a system would be incredible compared to what most people are used to working with. It's just that the latency for, say, a connection between Inda and the UK would be measured in days.

Re:Measure twice, cut once

[shigelojoe]

It would be like using a box truck to pick up a your groceries.

The internet is not a big truck! It's a series of tubes!

Seems silly to me.

[onion2k]

Unless there are also developers in the UK constantly accessing the code repository there's no good reason to use source control outside of your office. It'll be considerably cheaper to buy a small server with a RAID array, stick Subversion on it, and put it on your network, than it would be to be transfering files all the time. If the company in the UK that you work for insist on having control of the code then write something that syncs diffs between your local repository and the UK nightly/a few times a day/hourly/whatever. 13 coders aren't likely to be checking in more than a couple of megabytes of changes every hour.

Note: SVN/CVS/SourceSafe/whatever can probably do this already, IANAEIVS (I am not an expert in versioning systems).

Re:Seems silly to me.

[shalinmangar]

It usually happens that the company which is outsourcing to India wants all the source code in their own control. The reasons are easy to see: Firstly, they always have the code even if the deal is cancelled midway and Secondly, they can easily see the activity of the developers.

Subversion.....

[Anonymous Coward]

One thing you could look at is to use subversion as your source control system, as it only transfers diffs accrss the network so is very good with low bandwidth connections.

Staff levels

[Anonymous Coward]

and our correct staff strength is around 13

So after adding in your incorrect staff, you get a total of?

How much data are they pushing onto the source control server? Why not just move the source control server to India?

Contention ratios only help to ensure that you get the full 512Kb/s, it won't increase your reliability I wouldn't think. You will have to increase your total bandwidth size, not just change your contention ratio when you get more staff.

Quick thing on sharing

[QuantumRiff]

Will I get a better bandwidth if I take a 512 leased line on 1:2 sharing?

Yes and No. Right now you are setup on a 512K/s line, shared with up to 4 other customers. This means that if Customer A is using 400k/s, and Customer C is using 100k/s, then customers b and c get to share 12k/s. (without getting into the discussion of prioritizing and QOS, I'm way oversimplifying) Or, depending on the setup, each of you might be setup to only get 128k/s when all of you are using your connection. Now, if its the first case, and you have one other customer that is hogging all your traffic, then you will benifit from moving to a 1:2, or even just getting rid of them on the same circuit. However, the only way to be sure that you have 512k/s if you need it is to make sure you have your own connection, and a garuntee from the ISP. (in the US, these are called "Business class" DSL circuits in many areas) It will be MUCH more expensive.

That's easy...

[solid_liq]

Why don't you just outsource your development work to the U.S.? Then you won't have to worry about bandwidth.