|
Grex > Coop9 > #8: Get a 56K Line Instead of a T1? |  |
|
| Author |
Message |
dpc
|
|
Get a 56K Line Instead of a T1?
| 
Nov 17 15:35 UTC 1996 |
I propose an alternative to getting a T1: Getting a 56K
line.
Presently we are running 64 ptys, plus our dialins, and
the System is close to full all the time. This load causes a slowdown
in data processing, leading to both glacial progress in bbs and
large "ping" times over the Internet link.
I think getting a T1 is overkill. Last night at the Grex
potluck I was told a T1 is equivalent to a 1.5 Meg line. Presently
Grex has a 28.8K line. So we are considering getting an Internet
link which has *over 50 times* the capacity of our present link!
Is this really necessary? I think not.
M-Net's system is similar. We have 64 ptys plus dialins.
We provide about 1300 hours per day of service, according to "ttyuse".
We have a 56K link which is *fast*, even under this large load.
And the 56K link is *underutilized,* running at about 40%
of capacity. The Arbornet Board just voted to cut it back to 28.8K
or 33K because we can't afford the expense.
Since Grex has more problems with I/O processing than M-Net,
it seems that the best choice would be a 56K line. I can't see
the need for a T1.
|
| 62 responses total. |
scg
|
|
response 1 of 62:
|
Nov 17 15:55 UTC 1996 |
A 56K line would cost us almost as much as a T1 would, assuming the offer we
think we may be getting comes through, for a tiny fraction of the capacity.
Given the current saturation on our 28.8 link, there is no reason to think
that a 56K line wouldn't end up pretty saturated almost right away.
|
robh
|
|
response 2 of 62:
|
Nov 17 16:35 UTC 1996 |
In fact, I have no reason to believe that a 128 kbps line wouldn't
become saturated immediately, or within a few days at most.
Fifty times that bandwidth sounds good to me, if (and only if)
we can afford the hardware that we need to manage it.
|
ajax
|
|
response 3 of 62:
|
Nov 17 18:07 UTC 1996 |
Dave, there are two special considerations that make a T1 more attractive
than other options. They are that an ISP has offered us free Internet
service for a 56K leased line or a T1 line (but not ISDN), and that two
donors have each pledged $100/month if we get a T1 (but not 56K or ISDN)
for at least one year. If not for both of these, then the T1 discussion
certainly wouldn't make sense, but given that information, you'll probably
see at least why it's being discussed.
Here's an estimate of the cost for the first year of service. If we
keep any for multiple years, installation and annual costs may be reduced,
but the big donors are committed for just one year.
56K leased 64K ISDN 128K ISDN 1536K T1
---------- -------- --------- --------
Install 300 200 200 600
Equipment 300 500? 500? 700?
One year Ameritech 2000 500 500 3700
One year ISP 0 3200 6000? 0
One year big donors -0 -0 -0 -2400
--------------------------------------------------------------
Net cost $2600 $4400 $7200 $2600
While a 128K line might still be saturated, I'd still favor it over a T1
if we could get free ISP service, because it would be much more in keeping
with our income, it would be a mammoth improvement, and it would let us
test the theory that better bandwidth will increase donors and members.
|
krj
|
|
response 4 of 62:
|
Nov 17 18:53 UTC 1996 |
Dave, when you say that M-net's 56K is running at 40% of capacity,
how is that being measured? Is that peak load, or average?
Peak measured over what interval?
|
chelsea
|
|
response 5 of 62:
|
Nov 17 20:04 UTC 1996 |
Is the ISP asking us for anything in return for their
contribution of the T1 service?
|
dpc
|
|
response 6 of 62:
|
Nov 17 23:08 UTC 1996 |
Ken, those figures come from TS Taylor at last week's Arbornet BoD
meeting. Sorry, I don't know exactly how this was measured.
To both Robs--what makes you think that a 128K line might
become saturated? Frankly, I just can't conceive that Grex has
the immediate potential for 4 times the Internet traffic than it's
now carrying.
Thanx for the comparison table, Rob (ajax)! I can see the
attractiveness of a T1.
|
dang
|
|
response 7 of 62:
|
Nov 17 23:27 UTC 1996 |
I can easily see grex using 4 times the current capicity, seeing as we use
well over the current capicity as it is measured by everyone else on the net.
If any other system I've heard of had as much lag and as poor ping times as
Grex does, they'd consider themselves past saturation point and overdue for
a link upgrade. Another huge advantage of the T1 is that we no longer have
to worry about upgrading the link for a long time, but can concentrate on many
other things.
|
robh
|
|
response 8 of 62:
|
Nov 18 02:42 UTC 1996 |
Re 6 - Many reasons: (a) We frequently have a waiting list
for folks telnetting in, if we increased our bandwidth we would
likely increase the numbr of people who could come in at once;
(b) We would also lessen other restrictions (probably) such
as allowing graphics files on Web pages, or maybe even (shudder)
offering POP access; (c) Most importantly, a faster system will
just be more attractive and draw more users, along with their
mail/Web pages/FTP sessions/what have you. A lot of potential users
leave when they realize how slow it is here, if the system sped up
more and more users would join us until the system was slow again.
(At which point some of those users might decided to leave, but the speed
increase from their departure would be pretty small.)
|
nephi
|
|
response 9 of 62:
|
Nov 18 03:09 UTC 1996 |
> To both Robs--what makes you think that a 128K line might
> become saturated? Frankly, I just can't conceive that Grex has
> the immediate potential for 4 times the Internet traffic than it's
> now carrying.
I don't know if you telnet into Grex, or if you otherwise use the
Internet link here, but during the evenings, pings to Grex have
been averaging around 10000ms from the measurements I've taken.
Some response times have been over 30 seconds, and there is almost always
packet loss when I do these. This, all when pings to ICnet
from my locale are running at less than 100ms with no packet loss.
I am quite certain that we would saturate a 64k link the very day
we got it, although average response times would probably stay
below 1000ms for a week or three.
And we wouldn't immediately saturate a 128k link. But there is
a significant fraction of our community that aren't coming around
because they can't tolerate waiting between 5 and 30 seconds
before each of their keystrokes are echoed. If we upgraded to a
128k link they would come back quickly making our CPU the next
possible bottleneck, and I'm sure that our current Sun 4/200 can
swamp a 128k link.
But you're right in a way. We could easily use a 128k link for
at least a year or two and a couple CPU upgrades before it
becomes unusable. It would do us fine. However, we don't have
any ISP offers for free ISDN and we aren't likely to be getting
one anytime soon. Grex has asked approximately a dozen ISP's
for reduced pricing for ISDN and I believe that the cheapest
offer we got was about $150/month or $175/month. This is in
addition to the cost of the ISDN service from Ameritech, which
would put us right back at $190/month or $220/month, plus
Ameritech installation costs.
As it is, we can get a connection that is twelve times as fast
for just $30 more per month, with no installation fees from
Ameritech. Besides this, about 30 donors big and small offered
to pay for the entire first year of Ameritech fees for this.
We have a whole year to raise funds to pay for the second year,
and one of the donors has stated that s/he is willing to
continue into future years as well, if it proves necessary. I
have no doubts that Grex can afford this for the whole 5 years
if it continues to want to.
(P.S. This is taken from a ping to Grex that I just ran for a
minute, followed by a ping to ICnet for reference:
[mike@mtvernon1 ~]$ ping cyberspace.org
PING cyberspace.org (152.160.30.1): 56 data bytes
64 bytes from 152.160.30.1: icmp_seq=0 ttl=244 time=15153.2 ms
64 bytes from 152.160.30.1: icmp_seq=4 ttl=244 time=12472.0 ms
64 bytes from 152.160.30.1: icmp_seq=6 ttl=244 time=14182.9 ms
64 bytes from 152.160.30.1: icmp_seq=10 ttl=244 time=10319.2 ms
64 bytes from 152.160.30.1: icmp_seq=11 ttl=244 time=9579.0 ms
64 bytes from 152.160.30.1: icmp_seq=13 ttl=244 time=10689.7 ms
64 bytes from 152.160.30.1: icmp_seq=14 ttl=244 time=11031.1 ms
64 bytes from 152.160.30.1: icmp_seq=16 ttl=244 time=10061.1 ms
64 bytes from 152.160.30.1: icmp_seq=20 ttl=244 time=7701.2 ms
64 bytes from 152.160.30.1: icmp_seq=22 ttl=244 time=7798.9 ms
64 bytes from 152.160.30.1: icmp_seq=23 ttl=244 time=7431.5 ms
64 bytes from 152.160.30.1: icmp_seq=25 ttl=244 time=6003.3 ms
64 bytes from 152.160.30.1: icmp_seq=27 ttl=244 time=7941.2 ms
64 bytes from 152.160.30.1: icmp_seq=28 ttl=244 time=15091.1 ms
64 bytes from 152.160.30.1: icmp_seq=29 ttl=244 time=18463.2 ms
64 bytes from 152.160.30.1: icmp_seq=31 ttl=244 time=16936.6 ms
64 bytes from 152.160.30.1: icmp_seq=32 ttl=244 time=16359.4 ms
64 bytes from 152.160.30.1: icmp_seq=33 ttl=244 time=17392.8 ms
64 bytes from 152.160.30.1: icmp_seq=34 ttl=244 time=16482.4 ms
64 bytes from 152.160.30.1: icmp_seq=35 ttl=244 time=20613.3 ms
64 bytes from 152.160.30.1: icmp_seq=38 ttl=244 time=19682.4 ms
64 bytes from 152.160.30.1: icmp_seq=39 ttl=244 time=18731.6 ms
64 bytes from 152.160.30.1: icmp_seq=41 ttl=244 time=16788.4 ms
64 bytes from 152.160.30.1: icmp_seq=43 ttl=244 time=15606.3 ms
64 bytes from 152.160.30.1: icmp_seq=45 ttl=244 time=13763.4 ms
64 bytes from 152.160.30.1: icmp_seq=48 ttl=244 time=13508.9 ms
64 bytes from 152.160.30.1: icmp_seq=50 ttl=244 time=13705.5 ms
64 bytes from 152.160.30.1: icmp_seq=55 ttl=244 time=11220.4 ms
64 bytes from 152.160.30.1: icmp_seq=57 ttl=244 time=10083.8 ms
--- cyberspace.org ping statistics ---
69 packets transmitted, 29 packets received, 57% packet loss
round-trip min/avg/max = 6003.3/13268.7/20613.3 ms
[mike@mtvernon1 ~]$ ping ic.net
PING ic.net (152.160.101.1): 56 data bytes
64 bytes from 152.160.101.1: icmp_seq=0 ttl=246 time=22.5 ms
64 bytes from 152.160.101.1: icmp_seq=1 ttl=246 time=21.9 ms
64 bytes from 152.160.101.1: icmp_seq=2 ttl=246 time=28.0 ms
64 bytes from 152.160.101.1: icmp_seq=3 ttl=246 time=31.6 ms
64 bytes from 152.160.101.1: icmp_seq=4 ttl=246 time=37.0 ms
64 bytes from 152.160.101.1: icmp_seq=5 ttl=246 time=28.6 ms
64 bytes from 152.160.101.1: icmp_seq=6 ttl=246 time=18.4 ms
64 bytes from 152.160.101.1: icmp_seq=7 ttl=246 time=21.5 ms
64 bytes from 152.160.101.1: icmp_seq=8 ttl=246 time=37.0 ms
64 bytes from 152.160.101.1: icmp_seq=9 ttl=246 time=28.0 ms
64 bytes from 152.160.101.1: icmp_seq=10 ttl=246 time=26.1 ms
--- ic.net ping statistics ---
11 packets transmitted, 11 packets received, 0% packet loss
round-trip min/avg/max = 18.4/27.3/37.0 ms )
|
nephi
|
|
response 10 of 62:
|
Nov 18 03:15 UTC 1996 |
Bleah. I just spent about a half-hour trying to enter that.
First, I used Backtalk (since interactive response from Grex
is so bad), but that timed out due to the absurd lag. Then,
I logged in and spent about ten minutes or so just getting
here, and another 5 minutes or so waiting for the "paste"
to finish. And all this was done with a load average that
always under 10, that I could tell. Right now it is seven-
something.
|
ajax
|
|
response 11 of 62:
|
Nov 18 08:25 UTC 1996 |
> To both Robs--what makes you think that a 128K line might
> become saturated?
Actually, I don't think it necessarily would be, and don't think it's
a big deal even if it were. I said "while it might still be saturated"
in response to RobH's comment. I think if a 128K link were managed as
frugally as our 28K link, it would be fine. By that, I mean retain web
page limits, pty limits, mail quotas, continue trying to reduce ftp usage,
and so on. And if it were saturated, it would still be moving over 4
times as much data as we currently move, which would be a vast improvement.
|
steve
|
|
response 12 of 62:
|
Nov 18 15:05 UTC 1996 |
Spending the money on a 56K line when a T1 is such a small amount
more is insane, to put it bluntly.
The board / staff would have to answer to a rather disgusted user base
if that happened, I'd think.
|
scg
|
|
response 13 of 62:
|
Nov 18 16:46 UTC 1996 |
It's worth repeating, before people get too ahead of themselves, that we still
don't have a definite offer from the ISP. It looks likely that if we go to
them saying that we're ready to do it, we can probably get it from them, but
it isn't a sure thing.
|
ajax
|
|
response 14 of 62:
|
Nov 18 16:59 UTC 1996 |
Can someone clarify whether the offer is firm or not before the
board meeting? There's also still the issue of how what equipment
will be needed, which greatly affects our costs.
|
popcorn
|
|
response 15 of 62:
|
Nov 18 17:54 UTC 1996 |
I'm trying. I'm not getting responses to e-mail.
|
mdw
|
|
response 16 of 62:
|
Nov 18 23:53 UTC 1996 |
Grex is currently using a 28.8K modem based PPP link. The modem link
does error detection & correction, and data compression. All modern
high speed modems do. Because of this transmission overhead, there is
extra lag. It takes about 100 milliseconds for a piece of data to go
through the modem. On the other hand, the data compression is a big
win. Text data (such as most e-mail, party, conferences, etc.)
compresses very well, so a compression ratio of 2:1 is very doable. So,
even though a minimum round trip time of 250 ms isn't so hot, we should
still be managing a throughput of about 5k bytes/s or so total.
A 56k line does not need error correction, and does not do data
compression (typically). This results in much better round trip delays
- < 20 milliseconds. Note however, that the modem based PPP link
schedules interactive traffic (telnet, etc.) ahead of non-interactive
traffic (smtp, ping), and network congestion if the link is nearly fully
used can easily greatly exceed link delay. Unfortunately, the lack of
data compression hurts throughput, and a 56k line is not capable of more
than about 5k bytes/s.
There's no question but that indeed a 56k line will look 2-4 times
better than a 14.4K modem link. Compared to a 28.8k modem link, though,
the comparison is much harder. In certain respects (theoretical max
throughput) the two are a dead heat. The 56k line has better round
trips, although this might not be noticable once the line were used.
The 56k line would have a slight advantage if we stored many pictures,
or compressed data files for ftp. The 28.8k modem link has a definite
cost advantage.
In most respects, the difference is less than a factor of 2. It may be
helpful to keep a human factors issue in mind: human beings do not
generally notice a difference of speed that is less than a factor of
two. It's quite clear that on grex, we're definitely using *all* the
available network bandwidth, & that our users will no trouble using more
if it were there. So I would expect that our users would quickly use up
any improvement in network capacity of a 56k line, & it is very doubtful
that the system would seem any faster to most users.
Some extra factors to consider: grex almost certainly processes much
more mail than m-net (so comparing the two is almost apples & oranges
here). M-net has not yet had time to "grow into" their 56k line. Also,
the original author of this item may have a fiduciary interest
concerning the speed of grex's internet link.
|
dpc
|
|
response 17 of 62:
|
Nov 19 03:08 UTC 1996 |
Interesting stuff about 28.8K vs 56K, mdw! And I don't have a
fiduciary interest, just an interest as a member of Grex. I hope
Grex doesn't "over-purchase".
|
albaugh
|
|
response 18 of 62:
|
Nov 19 05:19 UTC 1996 |
Net lag has "never" been a problem for me. I'll accept that it *has* for
other folks. What *has* been a problem for me is entering a command and
waiting "*a long time*" for any response. *That's* a CPU overload, not a
network problem. Putting in a T1 (or a 56K line for that matter) and opening
up more tty's for more connections, *without* speeding up the CPU & increasing
the RAM (if necessary), makes no sense.
|
scg
|
|
response 19 of 62:
|
Nov 19 05:54 UTC 1996 |
That's why we are planning on upgrading the CPU.
|
srw
|
|
response 20 of 62:
|
Nov 19 08:18 UTC 1996 |
We are planning to upgrade the cpu, but waiting a long time for a response
may or may not be CPU load. It could still be caused by the link. If it
happens when the load average is low, it probably is the link.
Grex does need a faster CPU, and we are not likely to increase the number
of people connected to it unless the load averages can be kept out of the
stratosphere. Regardless of the speed of the link.
|
davel
|
|
response 21 of 62:
|
Nov 19 11:24 UTC 1996 |
I'm guessing that Kevin means he dials in, & it's hard to see how net lag
could be the cause in that case, Steve.
|
steve
|
|
response 22 of 62:
|
Nov 19 14:33 UTC 1996 |
The speed of the link is so slow, that Grex often trails echoing what I type
by
10 words or more. I'm typing blind right now. It has
gotten so bad that I've not done work on Grex when I've
had extra minutes at work, because
it takes so long to do anything that I can't reasonabley get anything
done.
I don't want to see more pty's added 'till we get more CPU and staff for
handlig problems.
After that, we can, but not till then.
|
scg
|
|
response 23 of 62:
|
Nov 19 19:48 UTC 1996 |
128K ISDN is now looking a lot more likely than the T1, at this point.
|
krj
|
|
response 24 of 62:
|
Nov 20 00:55 UTC 1996 |
I would assume, then, that Rob's guesstimate of $6K for the ISP
charges for ISDN (response #3) has been revised?
|