Nuts and Bytes

Hardware and Software Issues at Edmonton FreeNet:
The First 18 Months.

Abstract:

Introduction

I'll cover some of the technical decisions we made on startup, and then some mo re decisions we faced in the first year and half of operation. Your situation may be different . However, I hope that what I'm going to say will give you some insight into the problems you may face and give you some ideas of how to approach them.

Initial Simplifying Decisions:

Hardware and software

VT-100, text-only

LYNX, no shell

Gopher

Modem Pool

Issues since the startup

Mail and offline news

After careful consideration, we decided that yes, offline mail could be an adva ntage. For mail the "signal to noise ratio" (proportion of useful to non-useful traffic) is hig h since most people read most, if not all, the mail they receive. However for Internet news, there are many, many articles that people never even read after a cursory examination of the title. Downloading all this would be a waste of time.

We therefore put the implementation of offline mail on our list of things to do .

Unfortunately, this never rose high enough on the priority list for the right p eople with the right expertise and the right time to do it. Also FreeNet HelpDesk was still struggl ing with users trying to set up VT-100 emulators. Nobody could really face the thought of try ing to guide people through anything more complicated.

Within the last couple of months, we made a SLIP access arrangement with SAS, o ne of our founding sponsors. At this point offline mail was removed from the list of thi ngs to do.

Slip emulators

In short, SLIP emulators would have caused some amount of initial and ongoing w ork to satisfy a small group of users. SLIP emulators were not left very long on our list of th ings to do. When our real SLIP access arrangement with SAS came into force, SLIP emulators disap peared forever from consideration.

Z-modem

• We tried different versions of z-modem software on the FreeNet and the term inal end, and even tried compiling our own tweaked source. Different combinations worked mor e or less well, but not consistently.

• The hardware terminal servers may have had something to do with it. They d idn't always act as they should have, according to the documentation. Two different versions of firmware didn't help either.

• We originally used the telnet protocol between the terminal servers and the FreeNet computer. Telnet actually is only (mostly) a seven-bit protocol and didn't (al ways) pass the eight bits that the z-modem protocol (usually) relied on.

With the consistent problems with z-modem, we put up the Kermit protocol as a l ong-term interim measure. This worked very reliably under all conditions, but was slow and the target of much bitter complaint.

The problems with z-modem were greatly reduced by changing to a "rlogin" protoc ol instead of "telnet" between the terminal servers and the FreeNet computers. There are sti ll z-modem problems with some terminal emulators on the user end, however, and we still ha ven't worked out all the bugs.

PUBLIC ACCESS TERMINALS

We had a number of offers of old dumb VT-100 terminals. To make these into pub lic access terminals, we would have had to add external modems and cables (attractive item s to thieves if left in a public place like we wanted), and rely on a certain level of expertis e by the user to connect, or at least his ability to read and follow written instructions (rarel y realistic expectations). We wanted something a bit more foolproof, so we turned down the offers of dumb terminals.

We also got offers of a considerable number of old PCs and XTs with monochrome screens, some with only a single floppy and no hard disk. We accepted these and turned them into our public access terminals, what we call "PATs".

Nobody wants to steal an old PC or XT, and even if they could, they would have a hard time actually carrying it off. We bought the cheapest internal 14.4 kbs modems we c ould find to make them harder to steal and to minimize our loss even if somebody did. Internal m odems also simplified the cabling and power distribution problems. None of these PATs ha s been stolen so far.

We wanted naive users to be able to access FreeNet from the PATs without some a rcane connect ritual -- we wanted the PATs to be idiot-proof and simple to use. We tried to customize some freely-distributable emulation software but couldn't get this to work in a "bul let-proof" manner. There was always some way a user could by accident or on purpose leave the term inal in some indeterminate state.

We finally wrote our own PAT software. This does not upload or download files, and is set so that when the PAT powers on, the only thing it does is display a scrolling bann er announcement for FreeNet. This also acts as a screensaver to avoid the mono screens having a single image burned on them. Any keystroke dials up FreeNet (and only FreeNet) with error d etection and feedback, and emulates the VT-100 that FreeNet expects on connection. If the c onnection is broken (timeout, hangup or problem), the scrolling banner returns. The softwar e has proven to be very reliable for the last year and a half, and runs off a single diskette ( which only occasionally gets stolen) or the hard disk. This software is freely available to anyone who wants it.

[Tech notes: PAT software written in Turbo C V2.0; works at 7200-9600 baud wit h cheap modem in 4.77MHz PC; available by request from t.green@ieee.org; includes setup and configuration documentation]

MODEM POOL COSTS

MODEM POOL TESTING AND CONTROL

Edmonton FreeNet now has over 100 modem lines on a call forward rotary. A goo d number of these are busy even during the quietest hours. Without centrally managed modem s and management software to collect statistics, we would never even come close to kn owing what was going on. This is important since modem lines represent our most expensive ong oing cost.

With the modem management software we have, we can tell if a modem isn't handli ng any traffic. That's an indication that the modem has a problem, so we check it. Some modems for whatever reason, will only connect at less than the maximum rate (28.8 kbps) un der some conditions. Finding out which ones these are is problematic, since the modem m anagement software we have doesn't reflect actual connect speeds for each session.

The PC that controls the modem pool is accessible via its own dedicated modem l ine. This lets the system manager or a specially-chosen volunteer call in to check the modem p ool status on a regular basis to detect and solve problems.

EQUITABLE ACCESS TO MODEM POOL

• We would like to keep the ratio of modems to users at 1:50 and have noted t hat when this decreases to 1:75, the user dissatisfaction rate increases sharply. In other w ords, complaints spike up as we cross this modem to user threshold. We have added lines to the modem pool and could add even more, but this is expensive. We have therefore investigated met hods to make the optimum use of the modem pool lines we do have.

• We have implemented time outs to reduce the periods that lines are occupied but not being used. If, for example, a login procedure is not completed properly (for insta nce if system waiting for someone to put in their password), the system will drop the line af ter two minutes of inaction. If login is completed, system will drop the line without warning aft er ten minutes of inaction (e.g. if the user goes for a coffee while connected to FreeNet and for gets to come back). We did have a problem where, if the user was reading hs email, the mail program would keep checking automatically for new mail and make the system think user was active e ven if he was not. We solved this by reducing frequency of mail checking to 15 minutes, long er than the 10 minute timeout time.

• We have implemented bumping to reduce any user from hogging more than his s hare of the modem pool resources. Our algorithm for bumping is that if the modem pool is f ull, the longest connected member who has been on for more than 60 minutes (a guest gets less ti me) is bumped. If modem pool is not full, or if no member has been on for more than 60 minutes (again, guests get less time), no one gets bumped. Once someone gets bumped, he is more than welcome to call back and compete with everyone else for another modem line and full bumping per iod. This bumping process has helped give everyone a better chance of actually getting ac cess. Users also perceive it as fair, and this perception is important.

• Our resident statistician gets automatic dumps of connect time statistics from the system logs. He uses these in a number of ways to look at system use and answer questi ons like when are the busy times and what are the usage trends? These give us some measure of feedback on our control measures and have also been useful in marketing FreeNet.

• One very simple method to make better use of our modem pool is education. We tell people when the busy times are, and at what time of the day they have a better chance to get a line. We encourage them to spread out their access times into the generally less-busy ti mes if they can. This has worked to some extent.

• With our often-overloaded modem pool, we had a problem with our informatio n providers whocompete for the same lines; they couldn't get through in order to update the ir information. Our HelpDesk couldn't get connected either during busy hours and the FreeNet of fice (not in same building as the FreeNet computer) was often isolated as well. For a while we had a separate small modem pool for HelpDesk, office and info providers. This worked for a short period of time until the knowledge of the secret phone number became widespread . We then tried to limit access by software -- if you weren't on the access list and trie d to use the restricted modem pool, you got bumped. This was a pain to set up, and the access list was always out of date, causing much resentment. We finally ended up providing dedicated access from the FreeNet office to the FreeNet computer that office staff use during the day, an d the HelpDesk in the evenings. Our other efforts to improve the use of the modem pool mean the info providers generally don't have as much problem getting on as they used to.

• Lesson learned (also statistically provable) : A split modem pool is a les s efficient use of expensive resources than a single larger pool. However, user perception may no t agree.

ACCESS TO NEWS

Another concern by parents was with their children having access to news groups that the parents did not wish them to see. A project underway makes the function to add or dele te newsgroups for any given account to be password-controlled. The parent would enter the pa ssword (not the same as the login password), set up only those news groups he wanted the kids t o participate in, and then lock in that selection. If the kids wanted other newsgroups, the pare nt would then have to use his password to add them.

DIRECT ACCESS TO ARBITRARY URL

We opened this up and did run into some problems of a small number of users of bogging down the system by ftp-ing massive files. We control this problem in ways other tha n restricting URL access. Opening up URLs mean that users can use ftp and telnet as well as have access to the World Wide Web.

USER LIMITS AND CONTROLS

Since in downloading a file in our system entails the use of temporary disk spa ce, this effectively limited downloads to less than 2M in any one session. This inconvenienced a sm all number of members, but has resulted in much better service for everyone overall.

We have also tried to educate our users on not keeping large files in their Fre eNet file areas. In general, people have been most cooperative with this "good net citizen" approac h. This has avoided the imposition of disk quotas. Of course, we gave each user a means o f seeing how much space each file was taking so he would appreciate just how big a big file was. The system manager does periodic checks on file usage and zaps blatant offenders by making big longtime files disappear.

Another means we used to reduce the effect of massive ftp-ing was to restrict f tp to periods when the system was not otherwise busy We have gradually relaxed this as other cont rol methods (e.g. temporary file space limits, education, bumping) have proven effective.

SOFTWARE UTILITY DOWNLOAD

BACKUPS

Edmonton FreeNet _does_ do regular backups of all system files and the informat ion held by our official information providers. We _do_not_ backup user files. We make it cl ear to users that they, and only they, are responsible for their own files. The system manager w ill, however, intervene to fix up any inadvertent erasure of key files in a user's directory (e.g. mail or news configuration files), but he cannot restore the original content since these ar en't backed up.

WHITE PAGES

• not to be listed at all (no match between login name and real name)
• to be listed as last name and initials, for any login name
• to be list as first name and last name for any login name.

The names and initials that are listed come from the membership data base; they are not changeable by the user.

VT-100 ONLY

COMMITTEE USE OF FREENET

• dedicated newsgroups. There was no particular advantage in this. There we re some items of embryonic policy and technical discussions we didn't want the membership in gen eral to see.

• pre-established mailing lists using a global alisas. We tried this. Howev er since these have to be set up by the system manager, these were always out of date for continual l y changing lists of committee members.

• ad-hoc mailing lists. This worked well. The chairman or secretary would t ake down the names and email addresses of everyone at each meeting and keep an up to date li st of active members. He would mail records of decisions to the most current list (maintain ed in his local email program). All members would use the list of addressees on the email to u pdate their own address lists. Considerable discussion would go on inside the group in between meetings, broadcasting to the whole email group. Thus the lists were quite flexible and did not rely on the over-worked system manager to keep things up to date.

Some committees started out keeping rigorous minutes of who moved, who seconded etc, and then distributing formal minutes on paper at the next meeting. At least for th e Hardware/Software Committee, this quickly became clearly impractical. Instead of minutes, other things worked well:

• The chairman produced a list of outstanding items, i.e. a prioritized list (high, medium, low priority) of what must be done and who was responsible to do it. He distribute d this by email directly to each HW/SW committee member as well as heads of other committees an d the Executive Director, as soon a possible after the meeting.

• The chairman produced a list of outstanding items as above, but without the names of who was responsible for what. He posted this in an appropriate newsgroup for gener al information of all FreeNet members. This let members know what was going on, and generated a lot of useful feedback on the committee's work.

Considerations for changes

How does it affect the work of other committees? Discuss with them. Ensur e that the technical changes are in line with the overall aims and policies of your commun ity network. Censorship issues come to mind here -- there are lots of things possible from a technical point of view, but are they in fact desirable?

Priorities

We found that our resources were always limited. Since there is never enough, it's extremely important to prioritize projects and review the priorities regularly. Some low prioirity projects get done because either they are quite quick to do, or there is some volunteer really keen to do them. Some low priority projects never get done. Some high priority projects take a long time because it's the same limited number of people working on their implementation . Some projects may seem important but as time passes with them not being done, it becomes clea r that they are not really all that important after all.

Credits

This paper was prepared by Tim Green, recent chairman of the Hardware/Software Committee at Edmonton FreeNet. Any errors or omissions are the responsibility of Phil Kemp, who adapted the paper for presentation at TC96, 17-August-96.

---

Addenda

From Gopher to Web Server

TC96 session, Sunday at 1330 hr.

Title: Coping with Progress, or The Great Web Server Changeover of '96

Introduction: This paper explores the impact of technological change on the volunteers, information providers, and users of the Edmonton FreeNet. What lessons were learned from the Edmonton FreeNet's move from a gopher server to a web server as the primary method of information provision?

For Contrast to EFN:

ANNOUNCEMENT:

After one and a half years struggle to raise startup funding, the Brant FreeNet, based in Brantford Ontario, will officially go on-line June 8th 1996. The Brant FreeNet is a community based information system serving the needs of the people of Brantford and Brant County.

The Brant FreeNet is offering FULL PPP access to the Internet for its users through 32 lines. Access is provided to all Internet services including WWW, full news feed, gopher, FTP, and E-mail. Our system is running on 4 dual pentium 133s networked using Windows NT.

Our beta web site may be visited at http://www.bfree.on.ca.

Back to List of Presentations