How should Grex usage policies respond to having a faster internet connection? Currently we do things like discourage sending big E-mail messages, ftping huge files, and running mailing lists on Grex. We usual send E-mail to people saying things like "Grex has only a tiny 28.8K connection to the internet that must be shared among all its users" and asking them please to not abuse it. Once the internet connection is faster, these policies naturally come under question. We could just edit the standard messages we send out to say "Grex has only a tiny 128K connection to the internet" but it doesn't have quite the same impact any more. There are lots of options. We could loosen up a while and not start clamping down again until it seems to be turning into a problem. We could try to hold the line and aim to support more users instead of just more usage. We could hold the line for now, and maybe slowly loosen up as we see how things go. What do people think? How should staff approach this?26 responses total.
This response has been erased.
Absolutely. A 128K connection is better than what Grex has had in the past, but thats *still* a ludicrous amount of bandwidth for an enterprise such as ours. Thats still 1/11th of a T1, which is the standard speed for any commercial operation that does things. Now, we aren't a commercial operation, but we do as much as many do, and I still get looks of disbelief when I talk to people about Grex and they find out we aren't on a T1. We're going to have an increase of users FTPing things in once we're on the ISDN line because uploads won't take geologic time any more. If anything, we're going to find ourselves in the position of having to be even more strict.
I think we should open more telnet slots (this may require the 670 also) so we can better serve our existing user base. Keep current policies in place until (if) we find we can relax those.
With a faster connection, consider losing the countdown cue...reasons for having it in the first place should be reduced with a faster connection. The countdown was put in experimentally a year ago and has never been brought up again for re-consideration or re-affirmation. This is time to do so.
Richard, if we don't have the telnet queue, we'll be opening ourselves to telnet attacks, where the telnet daemon (that master entity that accepts connections) will have to fend off all these requests when there aren't enough resources to handle them all. There *will* be a queue to Grex: we can manage it ourselves, save CPU time and even let people know where they are in said queue, or we can make it open and let telnet sessions come in on a first come first served basis and waste resources dealing with telnet attacks. I know what I want to see for grex. There is also a "fairness" factor here: if we don't have a queue system, then those people who have the knowledge to write telnet attack scripts have a definite advantage over those who don't. Not only is that unfair, but very much selects for those more technical types to get to grex.
What STeve just said.
I'd really like to see Grex avoid membership perks. I've said this so often folks know I'm going to say it before I read the item. But I don't often go into why I feel this way. I will this once. ;-) Grex inadvertently filters for a special type of member. We don't have a grand plan to plan to do this, mostly it just happens. At present we are filtering for folks who like the idea of an open system which seeks to give all users as much access as possible. We are filtering for folks who are patient and don't expect much from our overworked volunteer staff. We filter for folks who are more into giving than getting. If we start offering perks, like members-only Usenet access, we will most certainly attract users who need cheap access to such services. I'm quite sure we'd gain members and have a healthier bank account and that all sounds wonderful, right? But all those new "donors" who are here for the perks would now be voting members. Voting members who would be quite likely to vote to extend more membership perks as such issues arose. If I had to choose I'd much rather we be meager and smallish, struggling to find enough generous donations, than evolve into a budget ISP, with tiered access, and have-and-have-not users.
Thats a very interesting thought Mary, that we'd start selecting for members who aren't opposed to member-only benefits, beyond what we have now. I'm not sure thats the case, but I can't say it wouldn't turn out that way either.
I don't think it's so inadvertent that we "filter for a special type of member". I'd like to think that we're making some effort to filter for people who will like it here, and that we will enjoy having here.
Thank you, Mary. Very succinctly put. I concur completely. (I agree with Marcus, though, that to some extent our selection process has been semi-intentional.)
There is a difference between doing something just to create a member "perq" and doing something for other reasons that happens to result in a member "perq". The question can be asked, what modification could result in significantly increased support for grex at the price of only a *little* member perq? For example, if e-mail were just given a lower priority for non-members than members - delayed by a day, for example. Or put into a non-member outgoing mail queue, which results in members having a slight advantage in mail handling. I'm sure others can think of marginal "perqs" that might have dramatic consequences.
I support what valerie, steve, and scott said. We don't know what will happen with the new connection; let's hold the line for a while.
I really strongly approve of Mary's response #7 -- but I don't know why it is in this item. I didn't think anyone had proposed any member perks here. I think it belongs in Dave's E-mail restricting item, and I wouldn't mind a bit if it were copied over there so that people reading that item from the agora conference would see it. I guess we have some general philosophical agreement about how to administer a faster connection. Keep most of the restrictions, and loosening some like the number of ptys up slowly, as we try to figure out what the traffic will bear. We don't have a lot of control over how people use the added bandwidth, but we seem to be more interested in more telnet than in ftp and mail.
Righto to your #13, janc!
Ack! Jan is right and response #7 here should have been entered in item #23 on Usenet News. I'm surprised nobody corrected me earlier. I shouldn't conference drunk. ;-)
...ahve you had THAT much cyberspace today????? tsktsktsktsk <g>
This response has been erased.
as far as filtering is concerned, " I'd like to think that we're making some effort to filter for people who will like it here, and that we will enjoy having here" seems strange with ~100 members and ~14,000 logins. and how many are conferencing? those are the logins who best fit the "enjoy having here." ppl who 'like it here' ... who are they if not conferencers? same reality applies to filtering, " for folks who are patient and don't expect much from our overworked volunteer staff. We filter for folks who are more into giving than getting." if that is true, as i wish it were, then the filter is a seive and need the element replaced. in fact, it is my opinion that we are filtering for the REVERSE, those who are more into getting than giving. >p
re 18: Nope. This is Grex, not MNet. :*
I'm not in favor of increasing the "concurrent telnet sessions" count right off the bat. I don't think anyone has evidence that the CPU with faster net connections won't be the bottleneck to acceptable system performance for connected users. I second the notion of putting in the ISDN with no other changes, and seeing what happens.
RAM is the bottleneck right now. We can't support the processes we're currently running on less than 128M. We've got to solve that problem before we let more in. My data, ping times under 200ms, but 6.x minutes to load mail. Mail is a nothing program. If it can't load then there are too many jobs competing for time. Please don't up the number of people yet.
And, it seems to me, things gravitate back to the idea of a mail machine to ease the load.
Load and memory problems both will be solved by the 670. The advantage of a separate mail machine is that the bandwidth of mail on the link can be throttled. I like this idea, but I don't see things gravitating back to it especially.
Bad choice of words on my part
(Load and memory problems will be temporarily solved by the 670. Load and memory would probably only be temporarily solved by an UltraSparc with as much memory as you want to put in it. We have that many users. Especially with a faster link.)
This response has been erased.
You have several choices: