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).

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.