Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Web Development

How Many Subscribers Should Share a Modem?


May00: Algorithm Alley

Moheb is president of E1 Development, an ISP and content provider in Roswell, NM. He can be contacted at [email protected].


How many subscribers should share a modem? This is a question I've seen more than once on the isp-nt @isp-nt.com mailing list, and it is usually followed by posts from ISP veterans quoting numbers they see working in their own operations. Clearly, maximizing the number of subscribers per modem is desirable because, after all, this is how most ISPs make money -- leasing an upstream connection and a bunch of phone lines, and letting several users share lines.

However, oversubscribing lines can result in busy signals and unhappy customers. Undersubscribing lines, on the other hand, can result in the ISP falling below the number of subscribers per phone line needed to make the business profitable. That we can get away with not allocating one phone line per subscriber is based on two considerations -- not all subscribers connect at the same time every day, and not all who do connect download at the same time (I'm assuming that the upload-to-download data rate is small). However, it is hard to determine what the optimum ratio of subscribers per phone line should be. It depends on many parameters, such as the size of the subscriber community, their on-line habits, the composition of the community (business or personal accounts), and the like. For instance, if all someone does everyday is check e-mail and watch stocks, then, as long as there is a large block of time over which everybody goes online (for example, 12 hours or so), you can get away with maybe as high as 12 or more subscribers per phone line. If subscriber connection time is long, but staggered enough not to overlap tremendously, the situation is not too bad.

On the other hand, if a bunch of subscribers stay alive by, say, pinging the server continuously (that is, issuing ping -t myisp.com at a DOS prompt), ISPs will have problems. In this article, I'll present a statistical model based on a stochastic method to quantify the aforementioned situation and provide some guidelines to obtain an optimum ratio. I must stress that the model is not comprehensive and by no means deterministic; that is, it just shows the probability of subscribing at a certain ratio without resulting in busy signals. However, the model does provide a good framework for further and more complex studies accounting for as many parameters as possible to simulate real-life situations. Finally, I'll present the C source code (available electronically; see "Resource Center," page 5) for this study so that you can run it with your own parameters.

Currently Used Ratios

At present, most ISPs use anywhere from 5:1 to 12:1 subscriber/modem ratios, depending on location and subscriber population. It also appears that 4 Kbits/sec. per dial-up is a widely accepted ratio in the ISP industry. This means that if you have a T1 connection to an upstream provider at a rate of 1544 Kbits/sec., you need approximately 1544/4.350 phone lines. Furthermore, if you share each phone line among eight subscribers, you end up with 350×8=2800 subscribers, which is a sizable population for a single T1 line upstream. Putting it to mathematical form, if Udr is the nominal upstream data rate, then the number of phone lines required, Nph, is:

Nph=Udr -- 4

The total number of subscribers, Ns, then becomes:

Ns=Nph×8=Udr×8=2×Udr

-- -- 4

The factor of 2 in this equation is not a constant and has a strong dependence on the Udr. In other words, there is a good chance that a significant number of the 128 subscribers of an ISP with 56 Kbits/ sec. upstream connection will face busy signals, whereas a much smaller fraction of 2800 subscribers of an ISP with a T1 line upstream connection would have the same experience. The following model will show why such a fairly intuitive proposition may be true.

A Statistical Model

My statistical model is fairly simple and presumes the following:

1. All users will be connected at random times during a long block of time, T.

2. During the time, T, each user will go online several times on a random basis and spend anywhere from a minimum Tminon to a maximum Tmaxon online.

3. Each online time interval is followed by an offline period that could be anywhere from a minimum Tmaxoff to a maximum Tmaxoff.

This model has certain limitations. For example, it assumes that all users have similar habits in terms of getting on the Internet: They all come home at, say, 7 pm everyday and get on the Internet several times until they go to bed at, say, 12 pm. Figure 1 is a schematic demonstration of the model, where thick lines indicate on-line intervals. Clearly, this scenario is not exactly what happens in reality: People have different social habits even in the same locality. Some are Internet crazed, while others might not even check e-mail for several days. This can also change from day to day. If a significant fraction of subscribers are local businesses, you are dealing with two blocks of time (say, from 9 am to 5 pm and from 5 pm to 12 pm), and you should also account for dinner time. However, despite all these limitations, the study comes up with very plausible numbers that encourage further analysis along the same methodology.

Following these assumptions, the mean, m, and the standard deviation, s, for the online and offline intervals can be calculated as follows:

m=Tmax+Tmin

-- -- -- -- -2

s=Tmax-Tmin

-- -- -- -- -- --

2.58×2

The factor 2.58 comes from the following property of a normal distribution:

P(m-2.58s<X£m+2.58s)=99%

where P is the probability that a random number X is within the aforementioned limits (99 percent), which covers almost all of the data. The normal distribution covers the range -·<X<·, which is not practical to compute and has to be clipped somehow. These inequalities show that we are clipping the normal distribution to include 99 percent of all possibilities. Figure 2 demonstrates the limits schematically. For every subscriber in this study, we calculated the online and offline intervals in Figure 1 by using a random-number generator. The random numbers generated were normally distributed with m=0 and s=1 (standardized random numbers). The actual time intervals, X , were then calculated by a change of variables:

X=sZ+m

where Z is the generated standardized random number, and m and s were calculated from the minimum and maximum time intervals as described previously. All numbers falling outside the 99 percent range were rejected and the random-number generation was repeated until acceptable numbers were obtained. For every subscriber, we calculated a random offline interval followed by a random online interval until we reached the total block of time, T. Once all offline and online intervals were calculated for all subscribers, we divided T by a number of samples, say, Nsamp and counted how many subscribers were online at each sampling point. Figure 3 shows the calculations obtained for 1000 and 100 subscribers. We assumed that individual users spend a minimum of 1 and a maximum of 10 minutes online every time they dial-up. We also assumed that users spend a minimum of 1 and a maximum of 60 minutes offline in between their online times. The total time for user activity was assumed to be four hours. The curves indicate the probability density function, P(x) that a certain percentage of the total users, x, are online simultaneously. Hence, the two curves are comparable and the areas under them are equal since:

10 P(x)dx=1

It is interesting that the two curves have almost the same mean value -- approximately 15 percent. This indicates that, at any given time, the maximum probability is that 15 percent of the total number of users (approximately one out of every seven users) is online. It is therefore reasonable to share one phone line between every seven users. However, with the decrease in the total number of users, the curve becomes fatter and shorter, which indicates that there is considerable probability that as many as 25 percent of the users may be online at the same time. Hence, a small ISP (planning for 100 subscribers to start with, for example) is wise to initially order more phone lines, so that as few as four subscribers share a line and no one gets annoyed with busy signals. As the customer base grows, the ISP can slow the rate of ordering of new phone lines. The model can also predict what happens when users stay alive for longer periods of time. Figure 4 shows the same curves for 1000 and 100 subscribers, only this time the maximum time a user may be online is doubled. The mean value in both cases has increased to almost 25 percent, which indicates that almost 70 percent more phone lines are required to sustain the same level of performance. This could seriously damage the ISP's profitability and even push it out of business completely.

Conclusion

Despite many predictions of doom and gloom for mom-and-pop ISPs, they continue to flourish in local communities. For a start-up ISP to take off and for an existing one to continue its profitability, it is important to order downstream phone lines conscientiously. The study presented here provides a good guideline, albeit one based on a simple model to simulate the offline and online times each subscriber might reasonably spend daily. The model provides a good starting point for more sophisticated studies accounting for many more realistic parameters, including variations in subscriber habits, type of subscriber (business or home), and so on.

I am writing the source code for this study in a Java applet so that anyone can run it with their own parameters. In the meantime, you can e-mail me at [email protected] for a copy of the source code in C.

Acknowledgment

I am indebted to Professor S.B. Pope of Cornell University who introduced me to his elegant application of stochastic methods in scientific problems. The thought of this study was originated after a discussion with my colleague, Don Donigan at E1DEV. I also benefited from many discussions with Manny Khavari, another of my colleagues at E1DEV.

DDJ


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.