|
|
| Author |
Message |
| 25 new of 171 responses total. |
kentn
|
|
response 100 of 171:
| 
Dec 31 05:33 UTC 1994 |
So, what do we need to grow our Internet connection? This seems to
be one of those things that we dream about but have no clear vision or
plan of how to bring it about. If a T1 connection is way out, and
ISDN is too expensive, what are we left with? Is it time to start
pushing another fundraiser? What do we need?
|
steve
|
|
response 101 of 171:
|
Dec 31 05:42 UTC 1994 |
I'm not so sure that ISDN is completely out of our price range.
The neater things like T1 connects are truely out. But ISDN, and
possibly Merit aren't impossible for us.
For Merit, we know that $1000/yr ($83.33/mo) we can have a 56Kb
connection, if we can attach to an already existing piece of cable.
I've sent mail off to Merit to find out what it would cost for us
to give them a modem and for us to have a dedicated line into some
piece of equipment there. Once we find the right person, we can
even offer to not leach off a NAS line, but to install a router PC
that is just smart enough to route packets. Marcus's idea of a
floppy based UNIX would be just right for this. Since I sent the
mail to them just before Christmas break I don't expect to hear
back from them till late next week or so.
For ISDN, we need to talk to IC-Net and see just how much an
ISDN connection would cost us extra each month. I'll stick my
neck out and say that it would be $100 - $150 a month for an ISDN
connection. ISDN modei are ever decreasing in price, so I think we
could get one for $500 or less (last time I looked it there were
about $600).
|
rcurl
|
|
response 102 of 171:
|
Dec 31 06:52 UTC 1994 |
Say we had that ISDN connection: what would limit capacity then, and would
it be more, less or just as aggravating as the current limit for each
user?
|
kentn
|
|
response 103 of 171:
|
Dec 31 06:55 UTC 1994 |
Who's the "we" that should talk to IC-Net? Seems like we have two
tracks to investigate here, but we don't have quite enough information
to do anything...
Which of the two (ISDN or Merit) is preferred, and why?
|
mju
|
|
response 104 of 171:
|
Dec 31 08:19 UTC 1994 |
I believe John Remmers is our ICNet contact, so it would be him that
should talk to ICNet.
ISDN through ICNet would probably be preferred, since it's likely
cheaper than Merit and provides more than twice the bandwidth of
a 56Kbps leased line. OTOH, Merit is closer to the backbone than
ICNet is.
|
srw
|
|
response 105 of 171:
|
Dec 31 09:06 UTC 1994 |
There are multiple things that can cause the system to seems slow.
If the load average is high, it will seem slow to all users, whether
accessing via dialup or internet. The slowness will be noticeable
primarily when you do processing or disk activity, such as starting up
a program, doing a search, or something like that.
We had much higher load averages when we were using smail.
This problem is much better now with sendmail, but it could return.
The other main slowness factor is the net-lag. This lag is caused by
the bottleneck of the data flowing between Grex's router and ICnet.
It only affects those accessing Grex by the internet. It causes a jerkiness
in the rate of printed output. Sometimes (at its worst) it causes
long delays. When the netlag is not bad, access via the internet
is faster than by dialup. Usually the dialup is better.
This slowness is perceived mainly as a function of the amount of output
you are getting printed. Programs like lynx and menu, which spew much
more data are much harder to use in this environment. As STeve points out,
there are other factors than pty usage which contribute to this.
ISDN is 128kb/sec, and we are currently running at 19.2 to 28.8 depending
on line quality. If we relieve the bottleneck by improving the link to ISDN,
it is likely to increase the load averages, but at least that would affect
all users equally. Offloading functions from Grex would counter this some.
A faster CPU would counter this much more. These are very much a possibility
within a 1 year time frame. I think we should investigate ISDN at the moment.
|
danr
|
|
response 106 of 171:
|
Dec 31 13:47 UTC 1994 |
How about limiting the total number of users? Once we reach that limit,
we turn off newuser until someone can go reap inactive accounts. I fear
that a bigger pipeline will only mean more people will log in and bog
down the system, or is that fear unfounded.
The costs for a bigger pipeline ($83 for a Merit connection and $150/
month for an ISDN connection) sound manageable if putting in a bigger
pipeline is really what we want to do.
|
davel
|
|
response 107 of 171:
|
Dec 31 14:35 UTC 1994 |
I don't see that turning off newuser until inactive accounts can be reaped
will improve *anything* - except those specific functions that have to
scan /etc/passwd or /u (or /home or whatever it is at the moment). The
inactive accounts don't slow anything else down.
|
tsty
|
|
response 108 of 171:
|
Dec 31 14:49 UTC 1994 |
newuser isn't as much of the problem as it used to be - when it
was the primary problem - and even then, even the "thought" of
restricting newuser was met with gasps of "heathen."
The operating concept seemed to be the valid enough concept of
"let 'em all try, and if newuser crashes, let 'em try again if
they want to." Ok, only the strong and the lucky survive. I
understand that. AT least now, the sytem isn't crashing around
newuser.
Withe a few more staff-hours avaialable, and the precision with
which steve does a reap, (kudos), we would have fewer +inactive+
users.
But it's not the inactive user who clogs the pipe. Granted, someone
logging in +as+ a newuwer is active (for the moment) and clogs
the pipe, but i've never seen more than 4 newuser processes working
at the same time - a pittance compared to the 30+ active users
sharing pipe space.
I dont' see newuser as being the immediate problem although it
leads to the problem eventually, as we add active users.
|
tsty
|
|
response 109 of 171:
|
Dec 31 14:50 UTC 1994 |
#107 slipped in.
|
danr
|
|
response 110 of 171:
|
Dec 31 15:15 UTC 1994 |
The point is not that the newuser program makes Grex run slowly. The point
is that more users means more mail and other traffic. By restricting
the number of users we have at any one time, we would be limiting the
load on the system.
I'm not saying we should restrict the number of active users without
some investigation. We should ask these questions: How many users do
we currently have? How many are inactive? How many of those inactive
people are still getting mail here? What is the volume of that mail?
How many members rely on the Internet connection? How many users are
concerned about the performance of the system?
|
andyv
|
|
response 111 of 171:
|
Dec 31 16:00 UTC 1994 |
I prefer to improve the system so it can handle the increasing load with
acceptable performance standards. I don't know what those standards would
be, but the folks logging on dertermin a sort of standard when they decide
to go elsewhere because Grex's service isn't worth the agrivation. Other
places are having the same problems.
So the challenge as I see it, is to raise more money and spend it on upgrading
the system fast enough to stay ahead of the wave of new users and at the
same time keeping the quality better than the other systems out there.
Now that sounds exciting. I think people using the system could understand
that as a goal and would be likely to support the effort.
|
danr
|
|
response 112 of 171:
|
Dec 31 17:57 UTC 1994 |
I'd be happy with that solution, too. Perhaps we need a membership
recruiter/fundraiser. Any volunteers?
|
cel
|
|
response 113 of 171:
|
Dec 31 18:34 UTC 1994 |
STeve mentioned that a real vampire on the link is multiple simultaneous
SMTP connections. perhaps you could limit them to 4 or 5, and *add* more
ptys? off-site mail might be somewhat slower, but interactive telnet
response would improve (ignoring for the time being how news will impact
things).
the point being that while increasing the bandwidth of the internet link
is a desirable goal, it won't happen tomorrow, and it will cost real $$$
to do. what can be done in the meantime to improve things? and, once
grex has reached the new bandwidth limit, the same problems will occur
again.
you see, upgrading is a time-consuming process:
noticing that there may be a problem,
taking measurements to pin it down and quantify it,
(these first two are often the most difficult)
cooking up a set of alternative solutions,
picking which solutions to try,
raising the money and effort to implement the solutions,
installing and debugging the solutions,
measuring again to see what effects implementing your chosen solutions has,
lather, rinse, repeat.
at this point, i think grex is growing faster than its upgrade process can
keep up with. this i believe to be the fundamental problem.
|
cel
|
|
response 114 of 171:
|
Dec 31 18:46 UTC 1994 |
in #111, andyv says:
< So the challenge as I see it, is to raise more money and spend it on
upgrading < the system fast enough to stay ahead of the wave of new users and
at the < same time keeping the quality better than the other systems out there.
i wish money was all it took! :-)
in order for something like this to work well, you will have to choose
standards of performance, reliability, and availability. you will have
to quantify system behavior so you can measure it and compare it to
your chosen standard.
choosing a standard means weighing in budget, user expectations, and
hardware and political feasability. it means trading off system through-put
against responsiveness, interactiveness (like telnet) against batch (like
mail). it means choosing a set of performance measures which reasonably
depict system behavior as experienced by your users.
|
steve
|
|
response 115 of 171:
|
Dec 31 23:01 UTC 1994 |
Some comments on all the above:
Newuser doesn't hog resouces anymore. Before Marcus's passwd database
aware version, it certainly did, but its tame now. It can add a new user
into the database in something like *3 seconds* under light load. So even
under heady load its something like 15 seconds to add.
Because of newuser and finger understanding about the passwd database,
there isn't nearly as much of a need to limit the total number of users
any more. Once a few other things like "ls" and friends know about it,
the number of entries in /etc/passwd won't really matter to people much.
ISDN rates at 128Kbps would be about 2.1 times faster than a Merit
56Kbps link. So the Merit link would be twice as fast, and an ISDN
link would be four times faster, roughly speaking. Its hard to say
exactly, since the link modem connects at different speeds, and it can
data compress.
As for Dan's questions about usage, its hard to say. We have between
40 and 90 new people comming into the system each day now. Not surprisingly,
most of them look around a few times and then go away. Some fraction of
them log on once, and never come back. There is a nice pile of accounts
ready to be reaped. In terms of "active" accounts, which I will classify
as those who log in once a month, the last time I looked it seemed like
we had about 1,800. Prbably a few more, now. Some number of inactive
acocunts get mail. Some much smaller number account for 90% of that mail,
in that they subscribe to the entire net and we have to deal with them. ;-)
Most people who log into Grex use the Internet link--more than 80%. It might
be a little lower, if a lot of the people who can come into Grex via the
dialins also use the net link, I don't know. In terms of mail sent here,
the last time I looked it was something around 35 - 40M a day.
Chuck's idea of limiting the number of incomming mail smtp connects
is interesting. We could try that, but I do wonder what it will do to
other sites trying to get stuff to us. We can only know if we try that
out. Chuck sees the problem correctly, too: we're growig at a rate far
faster than we expected to have to deal with. That usage growth curve is
slowing now, but only for the reason that there is only so much that can
be shoveled thought out little netpipe, and that we're "selecting" for
people who can tolerate a slow system.
The cheapest solution for getting more system would be to get a
Sun-4/3xx CPU card. This low-end SPARC processor would cost us about
$500 and is compatible with all the current hardware we have. Once
the world was recompiled (remember we'd change CPU types) we'd be able
to run the "last" version of SunOS before Solaris came out--SunOS 4.1.3.
This version is still used by many places that refuse to use Solaris (for
many reasons), and gets around several problems that earlier versions of
SunOS had, including our current disk problem. I know that SunOS 4.1.3
systems use large disks, etc successfully. Chuck, Marcus and Greg know
of them too.
The alternative of course would be to jump to a 486 system. While
it isn't any harder to move to this platform, in terms of effort to
recompile the world, it would take a *lot* more money. I'm not as much
in favor of this as going to the SPARC, but we'll have to talk about all
that more before we can make a real decision about it.
Assume we use the SPARC, $500 plus hordes of staff time will build
up a Sun-3 cum Sun-4 system that would be about 2.5 times as fast as
our current system. Once on a SPARC platform we would have another
option of getting a Sun-4/4xx(?) card, which while requiring a new
type of memory, would be compatible with all the other VME equipment
we have. That card is roughly 3 times faster than the Sun-4/3xx series,
so we're looking at being able to get 2.5 timers faster initially, and
7.5 times faster with the next series SPARCs, all without having to
change everything out.
The path for getting Grex on a Sparc would involve getting the CPU
card, intregrating it with another Sun, getting the OS on it, getting
the utilities on it, testing for security problems, testing for special
hardware like the ALM II serial card & tape backup, etc. So while this
isnt a "simple" thing to do (remember that Greg spent a lot of time
last yeat getting the Sun-3 up), it provides us another jump in
processor power, and also puts us in line for faster "old" SPARCs
that people get rid of.
|
kentn
|
|
response 116 of 171:
|
Jan 1 00:02 UTC 1995 |
Would we get a free copy of 4.1.3 SunOS with that CPU card, or is that
another expense we need to budget for?
|
steve
|
|
response 117 of 171:
|
Jan 1 00:53 UTC 1995 |
We can get one with the CPU card--at least I've seen it that way
before. For SunOS 4.1.3 it shouldn't be a problem. If Grex ever
decided to go with Solaris (staff starts moaning about here), then
we'd have to pay something for it.
|
bartlett
|
|
response 118 of 171:
|
Jan 2 17:03 UTC 1995 |
Ok, here goes. After reading 117 (one hundred seventeen, yes that's
right) responses, there seem to several concurrent threads going here.
Since we've not had a summary since #31, I'll try one, though it won't be
as neat and Andy's.
1. As far as CPU goes, Grex has to make a choice whether to stay on the
Sun upgrade path, or wander over to a 486 or pentium-pased system. The
Sun upgrade path involves less money up front, and the consensus seems to
be that it allows for a more piece-meal upgrade plan, since we can upgrade
one piece of equipment at a time, with noticeable results in performance.
Correct me if I'm wrong, but the Sun upgrade seems the consensus way to
go, and from what I've read, I'd be willing to go with it.
2. There is a rather complex discussion going on about how to increase
the Internet link bandwidth. The chief complication is that there seems
to be some question about whether or not we should do so. I don't know
much about the technical aspects here, so I'll defer to someone who knows
more to actually summarize the technical part of the discussion, but the
more basic issue seems to run like this. Right now, our link is badly
over-taxed. Should we: A. expand the link, B. try to figure out ways to
control Grex's growth until we can get out from under the system problems
we have now, or C. allow the self-selecting process of people being
disgusted with current performance to continue and act as an asymtotic
limit on Greex's growth?
Now I have some questions.
1. We talk about raising money for all of these upgrades. We have, if I
recall correctly, something like $4,000 in our bank account currently.,
Will it be Grex's intent not to use this hard-won money for upgrading?
2. Remember, when estimating yearly membership income, that some people
like me payed $60/year, not $6/month times 12 monts = $72/year. I know,
I'm a cheap-skate, but that's a different matter.
3. It is becoming clear to me that we need to organize Grex volunteers a
bit better, and find ways to get more people involved. I'll be entering a
separate item about this in a bit.
4. There has been a lot of wailing about Grex's current management style,
"crisis management" and "reactive, not proactive" or something like that.
I agree. So how can we change it and preserve those elements of the
culture of Grex that we all like? Are there any elements of Grex culture
that we *all* like?
Damnmation, I had several more questions that came up as I slogged through
the responses, and they're gone now. Oh well, I'm sure these are enough
to start with, and I'll remember more later.
Chris, the driftmaster.
|
mju
|
|
response 119 of 171:
|
Jan 2 19:33 UTC 1995 |
I talked to ICNet. ISDN will cost approximately $290/month (including
both ISDN endpoints and the service itself) for the first 64Kbps channel,
and $250/month for the second 64Kbps channel. Up-front cost for
equipment is about $1300, assuming we buy it new.
We might want to talk to MSEN and/or Merit about ISDN. It would
probably be better than a 56K leased line.
|
cel
|
|
response 120 of 171:
|
Jan 2 19:53 UTC 1995 |
i'd like to add a few comments to chris's nice summary:
1) it should be mentioned that staying with Sun technology has price and
reliability advantages over 486 or pentium. a disadvantage of the Sun
technology is there are fewer experts, and fewer suppliers.
2) my take on the internet expansion issue is that the general consensus
is "yes, please expand it." the complication arises from the expense
of the expansion options, and therefore the timing of the expansion,
and what to do until expansion occurs.
|
danr
|
|
response 121 of 171:
|
Jan 2 21:01 UTC 1995 |
Labelling Grex's management style as "reactive" and "crisis management"
really isn't quite right, and frankly, I resent this characterization.
You may say we're conservative, and I'd go along with that. You all
are free to attend board meetings, see exactly how we make decisions,
and voice your opinions.
re: hardware upgrades and our bank account, we've already earmarked
nearly $1000 for a tape drive and upgrades to the PC router. I don't
think we want to dip into our savings too much further than this. We
do need money in the bank in case something catastrophic happens or
membership donations fall off.
re: the expense of a higher-bandwidth Internet link. We could almost
cover the expense with our current membership. This would, however,
leave us with little cushion. The answer to this, as I suggested
already, is to either hold a fundraiser or to increase membership.
I'm still looking for a candidate to be a membership
chaiman/fundraiser. Any volunteers?
|
kentn
|
|
response 122 of 171:
|
Jan 2 21:09 UTC 1995 |
In general Grex's management style is reactive--we wait until the
stuff hits the fan and then we decide to fix the problem. That's
not always the case, but in general, that's the way things go around
here. It's something we should work at moving away from. I wish
people would stop resenting characterizations and start fixing the
problems. The problem isn't with the characterization.
|
danr
|
|
response 123 of 171:
|
Jan 3 00:03 UTC 1995 |
I guess you're entitled to your opinion, Kent, but you're wrong. As
I've said before, you're more than welcome to attend board meetings
and even run for the board so we can benefit from your expertise.
|
kentn
|
|
response 124 of 171:
|
Jan 3 01:19 UTC 1995 |
Well, then, perhaps Grex's activeness isn't enough to keep up with the
problems we face. That doesn't make me "wrong" though, and I would
still say the way Grex is managed is more reactive than not. I think
it's partly built in to the organization, which lacks strong leadership
and tries to rely on consensus-building (which takes quite a bit of
time and often seems to lead to a "wait and see" result).
|