F I D O N E W S -- | Vol. 10 No. 7 (15 February 1993) A newsletter of the | FidoNet BBS community | Published by: _ | / \ | "FidoNews" BBS /|oo \ | +1-415-863-2739 (_| /_) | NEW!--> 1:1/23@FidoNet _`@/_ \ _ | editor@fidonews.fidonet.org | | \ \\ | | (*) | \ )) | Editors: |__U__| / \// | Tom Jennings _//|| _\ / | Tim Pozar (_/(_|(____/ | (jm) | Newspapers should have no friends. | -- JOSEPH PULITZER ----------------------------+--------------------------------------- /********************************************************************* * IMPORTANT NOTE: The FidoNet address for FidoNews has been changed. * * The new address is: * * * * FidoNews = 1:1/23 * * * * Starting January 1993 email sent to the old address will not be * * forwarded! You were warned! * *********************************************************************/ For information, copyrights, article submissions, obtaining copies and other boring but important details, please refer to the end of this file. Table of Contents 1. EDITORIAL ..................................................... 1 And the winner is ............................................. 1 2. ARTICLES ...................................................... 4 Fidonet: Choice of a New Generation(?) ........................ 4 Review of the Zyxel U-1496E modem ............................. 5 Time to Bring Policy 4 into the 1990's ........................ 18 More Insantiy In Fidonet! ..................................... 19 A_THEIST Echo now on Backbone! ................................ 21 The GlobalNet Network (92) .................................... 22 The INTERNET echo is now available! ........................... 23 Online Magazine Standard Proposal ............................. 24 MENSANS_ONLY Echo Notice ...................................... 25 NEW ECHO FOR ANTIQUE RADIO COLLECTORS ......................... 27 SKEPTIC Echo now on the Zone 1 Backbone! ...................... 27 3. FIDONEWS INFORMATION .......................................... 29 FidoNews 10-07 Page 1 15 Feb 1993 ====================================================================== EDITORIAL ====================================================================== And the winner is... by Tom Jennings (1:1/23) Let's gets some small-time business out of the way. Let's take a look at what appears to me to be yet another case of bureaucratic silliness, finger-pointing, name-calling and other useless friction. OK, the nodelist and nodediff remains broken. A data-format error causes nodelist processors on many FidoNet nodes/BBSs to break. The immediate, problem-at-hand is, there's an extraneous control character embedded in one net's nodelist fragment. It is, in fact, not supposed to be there. Each of these fragments is maintained by each network's NC, who passes it up to each ZC, who compiles the complete nodelist from all the fragments. From this master nodelist is created the nodediff, which is distributed back to each local network. This is more-or-less the process, minus lots of details. MAKENL, written before most of you even know FidoNet existed, checks for lots of potential errors on these many nodelist fragments. It however doesn't check for this particular error. It would be nice of it did, obviously. So we have a number of possible solutions. A reasonable one (of many) might be, to edit out the unwanted control character from the nodelist fragment in question, and then to consider whether it's worth changing MAKENL to check for Yet One More Error. But no, instead we piss and moan, complain, point fingers, generate huge volumes of CC'd rants complete with dozen-level quotes, pontifications, etc etc ad infinitum. Hmm... maybe we need... another POLICY document! Another level of /0's! A new scapegoat! How about a text editor, and fix the goddamned text file? A few weeks ago, I casually mentioned that maybe MAKENL has a problem, and should be looked at. A number of people took this to mean I wanted to be part of every conversation regarding MAKENL or the nodelist -- I am not interested, so you may stop now, please. Looking back on what I wrote, I remain satisfied. In light of the new information, it looks like yes, MAKENL could be made to check for this error as well as the ones it already checks for, but in fact MAKENL works just fine, and the data given it is AFU -- hence GIGO. FidoNews 10-07 Page 2 15 Feb 1993 Why people have such emotional investments in this stuff is beyond me. * * * * * I have finally chosen a new heir-apparent to the FidoNews fortune. The new victim I mean victims I mean volunteers for life are: Sylvia Maxwell & Donald Tees, FidoNet 1:221/192 There were actually a number of excellent candidates, really. A diverse bunch. You can read what they wrote, buried in the file NEW-ED available from the FidoNews BBS. Here are some of the highlights of my reasoning: They are from not-the-US. There are two of them; there have times when having a co-editor has saved me. They seem to be the right kind of whackos. They are not part of any existing /0 conspiracy, as far as I can tell. And last but not least, they seem to have a grasp of FidoNews' peculiar and subtle position within FidoNet, and value FidoNet's independence highly. I think I trust 'em. As most of you probably know, there is no set process for picking a FidoNews editor. It used to matter a whole lot less. It will matter more and more. The present editor (me) is fairly well known within FidoNet, ahem. Previous editors were also well known within FidoNet, especially during their reigns. I don't know what the process will be for choosing the next editor. I know that I am personally am not comfortable with mob-rule, aka "democracy". It ain't a slot to fill, it's a peculiar set of skills necessary. What those requirements will be will change with the times, as they have in the past. I think what I did, though hurried, is about right, for this point in time. It would have been OK years ago, and maybe years from now, but we won't know until we get there. WE CAN'T KNOW FOR SURE UNTIL WE GET THERE. Let's not trade off flexibility, and the fun and satisfaction of banging heads with the future, for the "security" of bureaucratic rule. We've got enough of that out in the Big Room*, and no one is going to die if we screw up. FidoNet has not succeeded by making correct plans in 1984, for 1993, and certianly won't survive if it makes hard plans for 2001. We got here, and quite reliably, safely and fun! by being flexible. In spite of the annual sky-is-falling contests we seem to love, FidoNet remains incredibly robust and efficient. We splinter off dozens of new networks all the time; what Randy Bush calls "SourGrapesNet"s he also recognizes as a healthy thing; communications is supposed to serve peoples' needs, dammit, not some monolithic one-world-one-network heirarchic fantasy. "ONE PLANET -- FIVE BILLION SOVEREIGN STATES!" FidoNews 10-07 Page 3 15 Feb 1993 Do you really understand what that means? This is how I treat the world. You can quote me. ----- * the Big Room is the large place where it's bright during the day and dark at night with little bright specks. Some of us venture there occasionally, others rarely. ---------------------------------------------------------------------- FidoNews 10-07 Page 4 15 Feb 1993 ====================================================================== ARTICLES ====================================================================== By Isaac Salpeter The Youth of Fidonet. In many senses I am your everyday average sysop. I have a v32 modem like 3800 other sysops in the nodelist. I am very individualistic and fiercely independent, like many other sysops. I have never been an NC or for that matter any other administrator in Fidonet. My bulletin board is fairly locally-oriented, like the majority of those out there who have a limited budget and are running their system as a hobby, rather than a business. OK, so my file bases set me a little bit apart because I specialize in sound & graphics, but that's not really very. I do not carry any national echoes at present. Most of my users only read and post on message bases local to my system. But these are not what makes me or my system so different from others. I am fifteen years old. Wait! Before you punch the Page Down key, muttering under your breath "stupid kid", I think I have something valid to say. I set up this BBS about 5 months ago, but I have been a regular user of bulletin boards for over 5 years. I have, since I was 4 years old, used Apple ]['s, a decrepit PS/2 model 30, several Macs, the local university mainframe, a dumb terminal, and, for the past two years, my current 386'er to get my "digital fix". Right now, as well as attending school and running the BBS, I do consulting for the City of Pensacola as a community service. So, while it was not always true, I consider myself fairly literate in the world of computers and BBS's. "So what?", you say. The reason I bring this up is because of the alarming hostility towards most minors that I have seen from users and sysops over the years, including "adult" users of Fidonet. I know, I've heard all the jokes and anecdotes about so-called "d00dz" (generally minors who act immature, arrogant, and annoying, and who do so publicly and through the modem). I know there is a kernel of truth in this (there are a few in town who run "B-Bordz"). However, I am irked by the notion perpetuated by quite a large number of "adults" that this stereotype accurately fits all minors. Here's an example: In town, there is one other Fido sysop who is a minor. He has run a BBS for about a year, I believe. He is an extremely intelligent individual, and the care he puts into his system is apparent to all his users. I have yet to see him be anything but friendly and fair, which is more than could be said for a lot of adult sysops. And yet despite this, he was and is just about completely disregarded by several local sysops as "just a kid with a modem". Mind you, this treatment has ebbed slowly, and when I joined Fidonet just before the new year, this sort of "stoopid kid" talk was not really present, (at FidoNews 10-07 Page 5 15 Feb 1993 least not in "official" channels). Nevertheless, it is time for the majority of Fidonet (pun intended) to step back and reevaluate their positions on minors in Fidonet. I suggest these questions as ones adult sysops should ask themselves before insulting or dismissing a minor in the net: 1. Is this kid just cocky or does he/she actually know something? 2. Do or will I dismiss or shout down his/her opinions because of my own arrogance? 3. Am I being condescending to this person because of his/her age? 4. What has this user/sysop done to me to deserve sub-standard treatment? And most importantly: 5. How would I like to be treated the same way, were *I* in his/her position? I think that if everyone honestly asks themselves these questions, many people would come to the realization that not all minors are arrogant, ignorant, and just putting up a front. I know there are bad apples among the youth, but I fear that without some sort of change in behaviour by the adults of our "hobby" (addiction :-)), that the future of FidoNet, and even the hobby of BBS'ing will wane as more and more minors feel less and less welcome in the realm of computers. OK, say what you will. Perhaps you agree with me, perhaps you think I'm just a fool. But whatever you think on this subject, let me know, or better yet, let your NC, your net, your local BBS community know how you feel. If you agree, hey, great! You can make a difference. Encourage young users and sysops, let them know that they are welcome! If you don't like what I say, well, write me hate mail, for all I care. I've gotten it before, and my skin is not thin, so why waste your time? Now, if you have some serious, logical argument against the youth of Fidonet, then by all means, I'd be glad to hear from you. Otherwise, direct replies to the NULL device. Thanks! Isaac Salpeter 1:3612/380 ---------------------------------------------------------------------- by Tom Jennings FidoNet 1:125/111 Internet tomj@fido.wps.com FidoNews 10-07 Page 6 15 Feb 1993 BBS-usable hardware fashions come and go; very few are worth remembering. I say "BBS-usable" because so little of the hardware we use was designed for bulletin boards. I've been using bulletin boards since 1977, and I've run one continuously since 1983. The only devices worthy of mention in all those years are: the original Hayes S-100 board modem (ca. 1976?); the Hayes Smartmodem 1200 (ca. 1982?); the US Robotics Courier 2400 (the first time a manufacturer sought the BBS community's input); the US Robotics Courier HST (affordable high-speed); and the National 16550 FIFO'ed UART (how could we live without it). To this short list, I'd add the Zyxel U-1496 series, which I've had the pleasure to work with these last few months. MY INSTALLATION I have two rather disparate modem installations in my network here; FidoNet/dialup BBS, and direct-connect Internet. The features and desirable modem behavior for each is quite different. A modem great at BBSing is frequently terrible at unattended Internet use, and vice versa. While obviously the highest possible speed is always desired, I'll always trade off reliability for performance; it doesn't matter how fast it is, if it won't stay running! Reliability and consistency are the most important "features" of a modem, and the most difficult to account for. I want my modems to be *boring*. One doesn't need "excitement" in complex devices that need to run 24 hours a day. The 1496E has been about perfect: boringly reliable, a drop-in to install, and no tradeoff on speed; as a matter of fact it's the fastest all-around modem I've ever used. My FidoNet BBS, "Fido Software / FidoNews", is a 286-clone running my Fido/FidoNet program. Like many systems, mine doubles as a public-access BBS, as well as a FidoNet network interface. What's important for a BBS is reliability in an environment of many connects/disconnects/bad connections per day. Just as important is compatibility with other (BBS callers') modems. Human callers use every and any sort of modem, from the most popular to the most obscure, and every imaginable (and then some) terminal program. Few BBSs today rely on the modem to "auto-answer"; modern software handles all aspects of BBS incoming-call negotiation to maximize performance and error handling. A busy BBS modem might handle 100 calls per day, not including connections failed due to operator error, busy signal, noisy phone lines, etc. FidoNet uses the same sophisticated modem handling as BBSs, but does something that makes FidoNet unique -- dialing out to other FidoNet systems to automatedly deliver messages and files. A busy FidoNet system might make many tens of phone calls a day throughout a broad geographical area. FidoNews 10-07 Page 7 15 Feb 1993 Performance in BBSing and FidoNet means, besides reliability, BYTES PER SECOND! We have protocols (ZMODEM, off-line compression such as ARC, etc) optimized to squeeze every last second of connect times, since as amateurs (mostly) we're more sensitive to the cost of every minute we stay online. My other modem installation connects my 386BSD (freeware Berkeley unix) computer to the Internet. The inter-net is a large connection of computers ("hosts") and networks inter-connected via ethernet, modems, T3, radio, microwave, and any other damned thing humans have managed to cram 1's and 0's through -- including modems. A "connection to the internet" simply means a connection to another host connected to... Most Internet hosts are instantaneously connected to all other hosts, 24 hours/day. In under 1 second, I can find out how long my friend Alekz's terminal has been idle in the library at Johns Hopkins University in Maryland, from my little 386 in San Francisco. The amount of data to determine this is small, but it takes a number of back and forth queries and responses, each taking a few hundred milliseconds. Contrast this to the BBS/FidoNet paradigm, of staying idle and "offline" with intense bursts of activity transferring as much data as possible in a short period of time. Many of the two million (last best guess) Internet hosts are connected with a protocol called, surprise, Internet Protocol (IP). IP knows nothing about modems or phone lines; it assumes a point-to-point connection, full-duplex, up and running 24 hours/day. Copper wire (or functional equivalent) is the perfect IP medium. IP behaves vaguely like Kermit or XMODEM, in that there are small packets with ACK/NAK (response) packets for each packet or group of packets. It is most definitely *not* optimized for maximum-data-throughput alone. Since us mere mortals can't afford high-speed leased lines ($100/month and up for short runs plus $1000 CSU/DSU hardware), we resort to using BBS-style modems and plain old telephone service (POTS). A phone line and modem goes at my house, a phone line and modem to the nearest Internet-connected host, then you make exactly one phone call -- and never disconnect it! Many links require manual intervention when the line drops (operator tripped over the cord, etc) to bring the link back up. This is generally adequate for IP use. Because IP is uncooperative in establishing and maintaining a connection, unlike FidoNet, features for unattended modem use are most important, besides the constant of reliability. Performance for IP also requires something that FidoNet has designed around; turnaround time; the time it takes a pair of modems to flip direction, back and forth; SEND RECEIVE SEND RECEIVE ... more on this later. FidoNews 10-07 Page 8 15 Feb 1993 Contrast the BBS/FidoNet and the Internet/IP requirements, and you'll see there's more than a bit of difference. BBS/FidoNet likes lots of interactive command-rich features, and IP wants solid unattended-use auto-answer reliability. MY TEST SETUP For testing I used two 80386 hard-disk clone computers, each with a Zyxel U-1496E (external model) modem attached. For the DOS-based tests I ran DOS 5.0, Ray Gwinn's X00 FOSSIL driver, and my homebrew FidoTerm program. For Internet-based tests I used 386BSD 0.1. Before all testing, I restored the modems to factory-default settings with the "AT&F" command to ensure consistency. In all cases the modem to computer link was locked at 56,700 baud, and used hardware flow control, which is smartly the Zyxel factory default. Unlike older, simpler (slower!) modems where you simply set the baud rate to the maximum and forgot it, high-speed modems' actual rate is negotiated by the modems at connect time, and varies during a session; the flow of data to/from the modem must be regulated, and hardware flow control does this. When choosing a locked rate, a good rule of thumb is to pick the lowest speed that is still higher than the maximum data rate you will actually get. Setting baud rates needlessly high will simply lower reliability and increase processor-interrupt overhead. THE MODEM I tested the Zyxel for performance and operational behavior, rather than the commands and features. The command set is more than complete. They smartly chose the basic functions to be compatible with "most" modems, including most of the "AT&" extended command set of Hayes and US Robotics. The Zyxel however has a truly daunting proprietary command set. It seems there's a command or S-register for possible function, and then some, and I hear that the PLUS series has even more. Every week it seems I get yet another list of not-in-the-manual commands from the huge and growing Zyxel support/user/hacker community. The 1496E has the usual excessive array of modem result codes given after a dial (ATD) or answer or originate commands (ATA, ATO). It's not their fault that there are currently about 25 modem protocols and variants in use today, but it sure is a pain to configure software these days. With some of my older software (such as Fido/FidoNet) I had to suppress most of them (ATX command); with newer programs, or ones under my control such as FidoTerm dialing scripts, I was able to use every feature. (The ATX command merely suppresses the extended connect/status messages; the modem will still communicate at the FidoNews 10-07 Page 9 15 Feb 1993 highest speed possible.) I'll ignore the FAX features and commands, which are completely out of my area of interest and expertise. It seems though that Zyxel has implemented what looks to be the future FAX standard. I'll leave it for others to cover. THROUGHPUT I'm fairly conservative when testing throughput. Back in 1987 or so when FidoNet mailer packages started supporting high-speed modems, it became all the rage to display "bytes per second" for each session. It was no coincidence that the software displaying the highest number became most admired, never mind that the other end of the very same session displayed a lower, more conservative number... My Fido/FidoNet program, for example, measures "bytes per second" from start to end of the entire session, which is more realistic but less exciting. Oh well. I kept this attitude in my testing of the Zyxel modems. I don't measure "peak" speeds during some most-optimal part of a test, but include startup and finish times, disk file open and close, etc. I feel this approach is more likely to reflect reality. On to the actual testing. I concentrated on two areas in basic data-throughput, pure ASCII text and pre-compressed binary, and tested turnaround latency, ie. modem responsiveness. PURE ASCII: These are the numbers that modem manufacturers love to brag about. Text, using standard ASCII encoding, is very redundant; using nifty mathematical tricks compression techniques can squash text to a fraction of it's original size. Presto! instant modem speed increase! (This is what the V.42 stuff does, amongst other things.) For testing ASCII text throughput, I used an industry-standard test called Bit Error Rate Testing, or BERT. It works by having one end issue a repeating test pattern such as "THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG" and with the receiving end comparing the incoming bit stream against the same test pattern; error bits (not bytes) are counted. BERT has enough hard statistics to give you a pretty good handle on things. TEST #1: direct modem-to-modem, unidirectional pure ASCII. DTE speed locked at 57600 baud. FidoNews 10-07 Page 10 15 Feb 1993 +MODE: Receive-only +DURATION: 60:10 +LOG INTERVAL: 5:00 ---------- Errors ----------- Time Bits Rec'd Bits Blocks Seconds Resyncs =13:34:22 0 0 0 0:00 0 =13:39:26 12,369,312 0 0 0:00 0 =13:44:30 24,722,112 0 0 0:00 0 =13:49:36 37,150,616 0 0 0:00 0 ... =14:25:12 123,967,184 0 0 0:00 0 =14:30:16 136,319,880 0 0 0:00 0 -14:34:30 146,231,616 0 0 0:00 0 -END: 14:34:30 -RECEIVE BYTES/SEC: 4051 -BER: 1.00*10E-07 OK, so Zyxel has something to brag about; 4051 bytes/sec is fast! Note that the "Recv'd Bits" column counts bits, not bytes; there are eight data bits per byte. Note also the "Errored bits/blocks/seconds" columns. BERT does not correct errors, it merely counts them. It is meant to measure the error rate of a communications link. Obviously with this particular test we should have a very low error rate; as indicated, it's less than one error out of 10 to the seventh power, ie. zero. This is NOT a real-life test; you will probably not get this downloading even a pure text file; telephone lines were not used. The modems were connected together with an RJ-11 cord, one was commanded "ATA" and the other "ATO". This is "flat out downhill with the wind"; you can however use it as a relative measure of telephone line quality. TEST #2: Dialup, unidirectional pure ASCII. DTE speed locked at 57600 baud. +MODE: Receive-only +DURATION: 60:10 +LOG INTERVAL: 5:00 ---------- Errors ----------- Time Rec'd Bits Blocks Seconds Resyncs =15:37:04 0 0 0 0:00 0 =15:42:08 11,027,256 0 0 0:00 0 =15:47:12 22,975,176 0 0 0:00 0 =15:52:18 34,932,344 0 0 0:00 0 =15:57:24 46,896,248 0 0 0:00 0 ... =16:27:54 117,567,408 0 0 0:00 0 =16:32:58 129,486,280 0 0 0:00 0 -16:37:12 139,430,784 0 0 0:00 0 -END: 16:37:12 -RECEIVE BYTES/SEC: 3862 -BER: < 1.00*10E-07 FidoNews 10-07 Page 11 15 Feb 1993 Now this test was done with phone lines in a realistic manner. I live in an old industrial area, the phone lines aren't new, but not particularly bad either. The central office is about 5 miles away, so this is probably over 10 miles of copper. No fiber here yet! Note how the throughput dropped about 5%. This is the direct effect of pushing data over phone lines vs. about 4 feet of cord. Downloads of large, uncompressed text files will see this speed; it will also make BBS bulletins very snappy! TEST #3: Dialup, bidirectional pure ASCII. DTE speed locked at 57600 baud. +MODE: Bidirectional +LOG INTERVAL: 3:00 ---------- Errors ----------- Time Bits Sent Bits Rec'd Bits Blocks Seconds Resyncs =20:47:54 184 3752 0 0 0:00 0 =20:50:56 6,326,840 5,877,464 0 0 0:00 0 =20:54:00 12,512,552 12,095,040 0 0 0:00 0 =20:57:04 18,850,984 17,760,856 0 0 0:00 0 =21:00:10 25,479,032 22,622,432 0 0 0:00 0 ... =21:21:46 70,366,384 59,473,344 0 0 0:00 0 =21:23:58 OPERATOR INTERRUPTION START =21:23:58 OPERATOR INTERRUPTION END =21:25:00 76,999,584 60,747,280 23 1 0:01 1 -21:26:50 80,421,800 60,922,264 23 1 0:01 1 -END: 21:26:50 -REASON: OPERATOR ABORT -DURATION: 38:56 -SEND BYTES/SEC: 3443 -RECEIVE BYTES/SEC: 2608 -BER: 3.77*10E-07 This was a difficult test to perform, and I failed -- modem performance exceeded my test setup! My goal was to saturate the modem in both directions simultaneously, and see how the sum total throughput compared to the unidirectional tests. I never got there. My poor processors were overloaded trying to send and receive at these speeds; as a matter of fact, at one point I had to manually pause it to keep the computer out of saturation! Hence the relatively-low receive rate. Note that this time the error rate is not zero; I can assure you this is due to the computer dropping bits when I manually broke in, rather than the modem. FidoNews 10-07 Page 12 15 Feb 1993 The real problem is not that a 386 can't handle 50,000 bytes per second; disks are ten times that speed. The problem is we're running into the fundamental limits of Async ports, and while brute-force processor-clock speed helps, it's not the ultimate solution. More on this later. TEST #4: Dialup, ZMODEM file transfer. DTE locked at 56700 baud. +17:52:12 File #001: TESTFILE.1, 641,304 bytes, Zmodem -17:57:40 File complete (5:34, 1920 bytes/sec) +17:57:42 File #002: TESTFILE.1, 641,304 bytes, Zmodem -18:03:12 File complete (11:05, 1928 bytes/sec) TEST #5: Dialup, ZMODEM file transfer. DTE locked at 38400 baud. +18:52:22 File #001: TESTFILE.2, 1,923,912 bytes, Zmodem -19:08:50 File complete (16:30, 1943 bytes/sec) OK, some real-life tests finally. The files used for testing was NODELIST.015, a recent FidoNet nodelist, pre-compressed with LHARC 2.12, to somewhat foil V.42bis compression. These numbers are very conservative; they are file transfer end-to-end times, including file open, close, read and write, and do *not* include file-transfer protocol overhead bytes. These are very pessimum, and are the numbers real people will get with real files and clocks. 1943 bytes/second is damn fast. LATENCY Modem latency is usually ignored, because it's hard to test and the results are not obvious. Latency, or turnaround time, is the time it takes the modem to send/receive data in alternating directions; send, receive, send, receive, ... the lower the latency, the better. Plain copper wire has zero latency. 2400-baud and below only modems are usually pretty good, because they are much simpler internally. Most people who have used high-speed modems, especially older designs, know what latency is about... the sluggish response to your typing on a BBS that otherwise does fast downloads. Latency is the thing that killed XMODEM good and dead as far as high-performance was concerned. FidoNews 10-07 Page 13 15 Feb 1993 In the BBS and FidoNet world, things are optimized to not rely on latency wherever possible. ZMODEM's strongest feature is it's streaming mode that minimizes latency effects. TEST #6: Latency using IP over dialup. DTE locked at 38400 baud. For the first test I used my Internet IP link. My internet router, a 386SX running NOS, is connected to another router at my internet connect site across town, which is a 386DX running 386BSD unix. Testing consisted of using "ping"; Ping is a feature built-in to IP to check a link; a small block of data is sent out to a (specified) remote host, which immediately returns it back to the sender -- ping! When you ping across a single, simple modem link, you can measure the time the packet takes to traverse that link. There are however complications. First of all, this is serial communications; each byte is serialized, so that even under ideal conditions sending and receiving one byte of data takes time. Ideally one data byte would be sufficient; however the smallest packet my IP implementation will do is 16 bytes (8 data, 8 overhead). Since the test is turnaround latency, ie. out and back, the latency times are for two modems in series. On top of this, the software itself is a complex real-time multitasking system, and there is non-zero latency within the software itself. However most of this can be untangled, with care. The basic test consisted of 500 or so pings from my router, to the remote router, and back. My router calculated an average turnaround time of 180 milliseconds, and I watched to make sure the numbers stayed sane; the lowest I saw was about 150, the highest about 220. I then did another 500 pings on my router box to it's own internal interface; this resulted in an average turnaround time of 9 milliseconds of software overhead alone. I repeated this test on the remote router and got zero milliseconds. This is probably means something under 1 millisecond, which is reasonable, given that 386BSD unix is well-tuned for TCP/IP. The results of this test depend on how you want to look at what's left, which appears to be approximately 171 millisecond total loop time (180 minus 9). For comparison purposes, this is enough. In a series of messages forwarded to me from some internet mailing lists, there are many people interested in modem latency. According to various other informal tests, the Zyxel is better than most, with only one modem, the Digicom 9624LE+ significantly faster. (Their numbers were 203 milliseconds for the Zyxel and 163 milliseconds for the Digicom, using a very different and more complex test environment.) FidoNews 10-07 Page 14 15 Feb 1993 TEST #7: Benchmark latency, direct modem-to-modem. DTE locked at 56700 baud. I did however want to get "real numbers", ie. an actual measurement of modem turnaround latency. Without a large amount of comparative data, however, these numbers aren't much use. I believe the method is a good one however and I'd like to see more testing done in this area. My test environment in this case was again the two 386 machines coupled with two 1496E's. The test mechanism was plain old vanilla XMODEM transmission of a pre-compressed text file, once again NODELIST.015 compressed with LHARC 2.12. XMODEM is convenient because it transmits data as a series of blocks, each containing 128 bytes of data. Each block requires an ASCII 'ACK' character before the next block is sent; therefore there are two turnarounds per block (same as a ping). The file was exactly 641,304 bytes long, sent as exactly 5011 blocks (rounded up to the nearest 128 bytes); the entire transfer was 666,464 bytes including the file-transfer protocol overhead data. We can use the data from the ZMODEM send of the test file for comparison; both ZMODEM and XMODEM need to open files, write to disk, display status info on-screen, etc, minimizing the number of variables. +17:38:58 File #001: TESTFILE.1, Xmodem/CRC [641,304 bytes] -17:58:10 File complete (19:13, 556 bytes/sec) +17:52:12 File #001: TESTFILE.1, 641,304 bytes, Zmodem -17:57:40 File complete (5:34, 1920 bytes/sec) The difference in time between these two is the turnaround latency. With 5011 blocks sent we can easily calculate the latency per block (remember two turnarounds per block): 19:13 - 05:34 = 13:39 time difference 5011 / 13:39 = .163 sec/block turnaround time This jibes pretty well with my less-rigorous ping testing, and that of others. UNATTENDED USE Another major aspect of Internet type use that modems frequently need to be completely unattended. In the Internet cooperative that I manage, the San Francisco end has a dozen modems of various types. The Zyxels are by far the best-behaved and easiest to configure; the remote-configure feature isn't exactly a luxury when your other modem is locked in a basement ten miles away. Five of the newest members of our Internet coop are using them. Some of the other members, not using Zyxels, have their modems attached to a BSR box, so they can remotely power them off and on to reset them. Consider what it would take to drive you to such ends... not a pretty thought. FidoNews 10-07 Page 15 15 Feb 1993 Because our current router software doesn't manage connects for us, we have the modems setup for blind auto-answer. The router doesn't even issue a single "AT" command, usually required to let the modem know what the locked rate is. We've had no problems getting the Zyxel's to perform well under the worst possible conditions (dumb software blazing out IP packets to a modem not even connected...). Personally I'd recommend that you disable the infamous "+ + +" sequence that Hayes went and patented on everyone. It hardly matters any more anyways; decent software uses DTR to get the modems attention. Zyxel uses some proprietary method that is actually supposed to work. I see no use for it anymore anyways. RECOMMENDATIONS AND OTHER FEATURES I recommend the Zyxel U-1496 series highly. They don't require tons of fine tuning to get them working. The command set has the most common subset of all the high-speed modems I've used. They are inexpensive, bang per buck. Zyxel has a $35 EPROM software upgrade policy -- and for real cheapskates, you can get the EPROM image and burn your own for free! OOPS -- PROBLEMS! OK, so nothing is perfect. All high-speed modems these days are about equivelant to a Macintosh Plus in processor power and memory, and as much software. All modems have bugs; what matters is (1) will I ever get it fixed and (2) does it still get the job done in the mean time. Well. I ran into two problems. One looked to be truly horrid at first glance, but turned out to be not quite so. Some people doing testing in a purely Internet environment found that their 1496E's would not output received data under heavily-loaded full-duplex conditions; the modem was apparently too busy sending to notice the received data, and programs were timing out waiting for that input. In other words, the modem wouldn't really do full duplex. (When you stopped sending, all the queued up recieve data would come spewing out.) It turns out to be fairly hard to reproduce this bug; you have to enable hardware handshake (RTS/CTS) and then, apparently, ignore it. Instead of dropping bytes, the modem tries to keep up. Personally, I would have called this "operator error"! What Zyxel did however was fix the bug and mailed a copy to the person who found the bug -- and as far as I know, this was a mere mortal customer, not an "official" tester! FidoNews 10-07 Page 16 15 Feb 1993 In a DOS environment, with a standard PC Async Adapter, especially with a decent FOSSIL driver, you will never be able to reproduce this; it requires an improper installation. This is not the only story like this, where Zyxel takes customer bug reports and acts on them, producing a fix in the next ROM version. And makes those ROMs available for $35, or "free" if you can burn your own EPROMS! (Which most people don't of course do; however it lets others burn replacement EPROMs and make them available inexpensively. I can think of a few other modem manufacturers who will simply not admit that their product could possibly have bugs, or that mere users could find them. Grrr. Zyxel seems to be agressively working the sysop world. We're a fussy and demanding group of people, but I think they've noticed that BBS callers tend to look to BBS sysops' experience as to what modems are worth getting. This worked with U.S. Robotics, and it seems to be working well with Zyxel. Let's see if they can keep up! FIDONET COMPATIBILITY REARS IT'S UGLY HEAD... There is one other problem of uncertain effect, that has already caused not a little bit of trouble. The Zyxel modems will not auto-answer at 300 baud, ie. Bell 103A. Really. No one *likes* 300 baud. In this day and age it's a "fall back", when literally everything else fails, and in some cases, such as calls from "overseas" (US-centric point of view) the only modem protocol in common with U.S. modems. (The old European split 1200/75 baud 202A protocol for example.) The clincher: the FidoNet technical standards require that a node in FidoNet always accept incoming mail, simply put. Even if this means falling back to FSC-001 mode, with XMODEM for files and at 300 baud; at least a message can get through. Zyxel claims that the problem is due to some modems' FAX protocols using 300 baud for protocol signaling, such as the Supra, and because of this 300 baud is unavailable for modem use. I do not understand FAX protocol issues, and can only offer that other modems do not have this problem. So a Zyxel-equipped FidoNet system cannot accept incoming 300-baud calls, which is technically in violation of FidoNet technical requirements. It has already come up as a problem in one net, at least. FidoNews 10-07 Page 17 15 Feb 1993 FidoNet is not here to sell modems; it's here for people to communicate, period, even or maybe especially people with "no money" systems using junk modems. But in fact this "300-baud" problem has been around for a while now -- for example, my Tandy 200 laptop (circa 1985) has a built-in 300-baud modem that hasn't been able to connect to any high-speed modem for years; it's old design gets fooled by the complex tones required for the new speeds. Probably this is a common problem. I truly don't know how much it matters that the very bottom end of the speed range is going away. Are we cutting off a dozen people? A hundred? Thousands? It's a marketing decision certainly, and we'll see what the outcome is. I wish we could have both, such as an option to dedicate Bell 103A to modem use vs. FAX. -------------------------- Zyxel contact information, courtesy Zyxel Retail Price SYSOP Special Price ZyXEL U-1496B/144 (Internal Card) US $449.00 US $289.00 ZyXEL U-1496B/168 (Internal Card) US $469.00 US $299.00 ZyXEL U-1496E (Ext/16.8kbps) US $469.00 US $299.00 ZyXEL U-1496E+ (Ext/16.8/19.2kbps) US $649.00 US $399.00 ZyXEL U-1496 (Ext/16.8kbps) US $899.00 US $499.00 ZyXEL U-1496+ (Ext/16.8/19.2kbps) US $989.00 US $549.00 ZyXEL U-1496R (Rack Modem16.8/19.2)US $899.00 US $549.00 ZyXEL RS-1600SY (Rack System with one RS-1600 and one U-1496R modem) US $1349.00 Manufacturers Representative William Gourley 1-800-669-5085 1-800-GOU-RLEY Support BBSs: San Diego Rep 1:202/346 8:913/1 1-619-282-0857 Corporate 1-714-693-0762 Fax: San Diego 1-619-282-2397 Stocking Resellers: ORG NAME MANAGER VOICE PHONE Donovan Enterprises - Brenda Donovan - 1-619-560-8317 RTL/VAR FidoNews 10-07 Page 18 15 Feb 1993 Micro City - Rodger - 1-619-689-0567 RTL Sole Source Systems - Scott McMillan - 1-619-467-0661 RTL LaPaz Electronics - Allen - 1-619-586-7610 WHL Richard Couture - Richard - 1-415-621-1908 RTL/VAR ---------------------------------------------------------------------- by: Phillip Dampier 1:2613/228 While flipping through an overloaded case of floppy diskettes, I was very much surprised to find the floppy disk that contained the very first nodelist that listed my node, back in December of 1988. At the time, our hub consisted of about a baker's dozen of nodes, all a part of a Net 260 that was about two screen pages full. The entire nodelist was well under 700k at the time. What amused me even more was finding a policy document on that diskette that was almost identical to the Policy 4.07 that is used today in Fidonet, one that was adopted in 1989. Today, the nodelist is fast on the way to reaching two megabytes in length as Fidonet passes 22,000 individual nodes. With that growth has come change -- change that has not been reflected in this network's current policy document. For those visionaries who want to bring Fidonet into the 1990's through representative governing of this network, a new policy built from the ground up sounds like an excellent idea at first thought. Unfortunately, the landscape is littered with policy proposals and movements that have pledged to produce a new policy built from the ground up, only to stand little or no passage within the current Fidonet infrastructure. The policy proposal recently submitted by a committee working under the auspices of Richard Wood does not address all of my concerns, but I have realized that it's a good first step. It represents the building of a new foundation for Fidonet -- one built on democratic reform. It's time for us to recognize that Fidonet needs a new policy document. It also needs a new system for adopting policy documents, one that involves each of you who belong to this network. Let's take the first step by adopting a policy that sets the stage for future reform through better election procedures and a realistic policy reform process. Without this basic reform, no major policy proposal ever has any real chance of discussion and adoption. FidoNews 10-07 Page 19 15 Feb 1993 I call on all Fidonet Region Coordinators to support taking this new policy proposal to a full network referendum. I call on all nodes in this network to take the time and get involved in Fidonet's administration. Your involvement in this great Fidonet Co-Op brings new blood and a new vision for the future. Let's start off with a new policy document that paves the way. Some of our nodes in Net 2613 who wanted to add their names to this article follow: Jerry Seward (Net 2613 NEC) 1:2613/333 Tracy Logan (Hub Coordinator - MetroEast) 1:2613/111 Daniel O'Donnell (Hub Coordinator - MetroWest) 1:2613/369 John Passaniti 1:2613/102 George Vaisey 1:2613/333.5 Raymond DeRoo 1:2613/450 Alex Barbara 1:2613/123 Mark Pedersen 1:2613/211 ---------------------------------------------------------------------- Yes, it's possible: More Insanity In fidonet! By Mike Catchpole of 1:267/113.15 Well, the hot air from my last article seems to have died down, but it's still winter out and it's getting cold out here :) I'll attempt to do an entire article without that phrase that has become quite popular in the fido world today... ... GO POUND SALT ... The democracy issue in fidonet is getting a good start, and this is good. Glen Johnson wrote recently on point voting. It was in fact the most cool-headed article ever written about the topic. >But, I gotta oppose that one, friends. See, a point system, by >definition, is an extension of an existing Fidonet Node. Points >are not subject to policy; they don't have to be up during Zone Mail I couldn't agree more on the first part. If points were allowed to vote under a new policy, it would open the door for ballot box stuffing. Not good. However, the thing that points do not have to follow policy is a gray area. Existing policy defines points as users. So we have to follow policy and be users... Which means exactly what? A user is PHYSICALLY and TECHNICALLY unable to File Request, for example. He doesn't have the software to handle it. On the other hand, a point can physically File Request or crash mail systems other than his own. But..... FidoNews 10-07 Page 20 15 Feb 1993 Is this legal under policy 4? Well, friends, it depends on who you ask! Attempts by points to get some clear cut definition on this issue in the policy_5 echo have been meet in a very unique and interesting manner. Keep in mind, the points in question did not want to set policy... they wanted it to say specifically what was legal and what was not. Of course, that didn't stop the netmail flame-throwers from telling them they had no right to set a policy that will affect ME. (me being the nodelisted flame throwers...) First off, when points posted in the echo they were told by persons in the echo that points could not have anything above READ ONLY access. Some changed. Some came in later and never saw the message. Then Glen Harvy Posted a message, which he signed "Zone 3 Co Moderator" in which he stated that points could not receive the echo, period. So I looked it up in the elist. And again in elist 302 just in case it had been changed for some reason... it hadn't. Here is the entry from elist302, with some of the indentation removed to make it more fido-news friendly, otherwise unchaned... Policy 5 assimilation, discussion, and implementation. POLICY_5 This conference is for those persons who are interested in seeing a new FidoNet policy (Policy 5). It is not a place to bitch about the downfalls of Policy 4, but a place for constructive discussion which WILL lead to drafting a policy that is more in tune with the needs and flavor of todays FidoNet. YOUR INPUT COUNTS! Moderator: Chip Kukuk 1:3636/3 Last Updated: 12/01/92 No. of Nodes: 25 Volume: 40/week Restr: Distribution: REQUEST Gateways: ZONE 3 VIA 1:291/11 Rule File: n/a Now, first thing is that the Restr: field is blank. Thus, it can go to anyone, not just these nodelisted sysops. Secondly, according to nodelist.029, there is no such node as 1:3636/3. Now, how chip is moderating the echo from a node that does not exist when the rules suposedly say that you must be the sysop of a listed node to participate is beyond my comprehension. As far as I am concerned, it is somewhat ridiculous to establish rules for a confence that specificly prevent the moderator from receiving it. Especially when they are created to squash the voice of a so called minority group. I also received a netmail from Glen that "Policy 5 will never be accepted if it is learned it was moduled by points". Well, I don't think it'll last long if it DOES pass. Since many major points, such as point file requests and crashmail will probably never be considered, it will have the same weakness as policy 4- vaugness. FidoNews 10-07 Page 21 15 Feb 1993 Well, I think I can imagine what policy 5 will probably look like. If it was based on the recent fido events, there will be no elist, no nodelist, and no rules.... ---------------------------------------------------------------------- Christopher Baker Rights On! 1:374/14 A_THEIST Echo Available A_theism means free of religion in the way a_political means free of politics or a_sexual means free of sex characteristics or drives. With that in mind and ever cognizant of the continued pressure of religion to intrude itself into our government and its operations, the A_THEIST Echo is provided to inform and alarm and hopefully wake up the sleeping and too long silent majority to the peril on our doorstep. It is now a Zone 1 Backbone Echo Hosted and Moderated by Rights On! [1:374/14] and Christopher Baker [card carrying member of American Atheists, Inc.]. Initial links may be obtained from your local Backbone source connection. Zone 3 is being fed through 3:800/857 and Zone 2 through 2:241/6001 via a Gate at 1:374/14 until direct links can be made to those Zones via the international Backbone links. The Zone 3 Hub sends it into Zone 6. The Echo is open to anyone who can discuss, without proselytizing, the extreme desirability of maintaining the absolute separation of State and church in this country as provided for in our Constitution. A sample of the first few messages and the statement of purpose of the Echo is available as A_THEIST.ZIP from this system anytime except 0100-0130 ET and Zone 1 ZMH [USR HST V32 online] if you wish to get an idea of whether to commit disk space to the Echo. An archive of the past traffic from the Echo is also available as A_ECHO1.ZIP, A_ECHO2.ZIP, and A_ECHO3.ZIP, A_ECHO4.ZIP, etc. It has been on the Backbone for months. Ask your Backbone connection to get it for you! The complete info is available in the current ELISTnnn.XXX file available from your NEC or REC or here. [Request ELIST.] I hope you will join us or ask your Sysop to request a link via their regular Backbone connections! FidoNews 10-07 Page 22 15 Feb 1993 TTFN. Chris ---------------------------------------------------------------------- By: Howard Sucher 1:167/320 The GlobalNet Network (92) This article is to let sysops and non-sysops know that their is an alternative FREE electronic communications network that travels around the world daily. This network is called the GlobalNet Network (92). Now please don't start thinking "Oh no, Not another network, they are all the same." GlobalNet Network is not like any other network! I'm sure it is very hard to believe this. But it really is true. A network can be compared to a computer game. Their are many bad programmed games and a few good ones. The GlobalNet Network (92) is a network who is based mainly on adult and professional type people. We do not support the writings of wasteless messages that always say hello, hello and hello and have such FALSE B.S in them. Sysops and non-sysops who are a part of GlobalNet are willing to help each other out. We have no moderators in our 50+ message areas that travel anywhere from North America, All over Europe, Asia and Australia. I'm sure you are wondering how we don't have moderators? The answer is that we have specialists! These people are knowledgeable in this subject field! They are not in the echos to complain about people doing this and that. GlobalNet is free of cost shareing as this network is founded on the basis of free amateur communications around the world, where people can enjoy themselves and not put up with useless words found in many other networks. This is how a Good ELECTRONIC amateur network should be! It's a hobby. In GlobalNet, you decide what you would like to see and then discuss it with everyone else. Unlike some other networks in which your plight and suggestions are flushed down the toliet, we in GlobalNet take everything seriously and even if your a node, yes a node! your very important and have a say! No one rules you! If by chance your eyes and head are not overpowered with everyday life and you really want to believe and see something different, then you can't lose on trying out this network. P.S. Also to prove that GlobalNet is not just a network off the floor, it was mentioned in an article with in PC-TODAY magazine Aug. 92 issue. FidoNews 10-07 Page 23 15 Feb 1993 For fast and quick information freq: GN_REG at: Howard Sucher - (514) 487-7086 (19200 ZYX) Fido: 1:167/320 Howard Sucher - (49) 6841-15390 (HST DS 16.8) Fido: 2:247/83 ---------------------------------------------------------------------- by Adam Michlin, 1:143/143 The INTERNET echo is now available: This echo is for novices and other non-experts to discuss the use of the Internet. Finally, a place where the question "How do I send netmail from my fidonet address to my friend on the Internet and vice versa?" is on-topic. What INTERNET is: o A place to ask "dumb" questions like: * How do I get a node-number on the Internet? * How can I get a full Usenet feed with my 1200 bps modem and my Fidonet mailer? o A place to discuss getting access to the Internet, and getting Usenet feeds. o A place to discuss the "cool" places to FTP from, how to FTP/Telnet, and how to be polite about FTP'ing. o You don't know what FTP'ing is? INTERNET is the echo for you. o A place to discuss how to address mail from Fidonet to other non-Fidonet technology networks such as Compuserve. What INTERNET isn't: o An overly technical echo. Topics like "Getting the best throughput with UUCP-G" will be tolerated, but not looked upon favorably =) o A place to discuss the actual technical issues behind running your own Usenet/Internet gateway. (For this, you might try the UFGATE echo). Why?: o Why not? o It's needed. The OTHERNETS echo gets a lot of Internet related traffic and needs to return back to Fidonet technology related issues. How many times have you seen someone ask something about the Internet in an echo that has nothing to do with the Internet? I see many messages like that consistently in all sorts of echos. Who?: o The moderators are Adam Michlin@143/143 and Software John@143/8. I (Adam) am the current moderator of the backbone echo OTHERNETS, and to some extent an Internet novice myself. John runs the Internet<->Fidonet connection for Net 143 and will be the resident FidoNews 10-07 Page 24 15 Feb 1993 'expert'. Where?: o Currently available from: Adam Michlin 1:143/143 Al Anderson 1:377/37 Software John 1:143/8 Michael Forrest 1:278/707 Guy Martin 1:143/269 Jim Cannell 1:216/21 Mark Woolworth 1:209/710 Jerry Seward 1:2613/333 Barry Kapke 1:125/125 J. Allen 1:2201/13 John Gillet 1:114/27 Leon Lynch 1:262/3 Roger Smith 1:214/33 Ralph Sims 1:343/94 -Adam Michlin 1:143/143 amichlin@cats.UCSC.EDU ---------------------------------------------------------------------- by Jasen Fici (1:260/445) Magcom v1.0 Concord Software would like to introduce Magcom v1.0 ... Magcom is a result of years of on-line experience. Many, many great publications are transmitted electronically in or as a single text file. Although many system operators make these magazines available for users to look at while they are on their system, and some even make them available for download, until this time, there has been no easy way for the user to do this (or the sysop to set it up). Enter stage left, Magcom ... Magcom is a full featured, magazine and publication manager, viewer, and on-line door. It encompasses a rather wide range of functions, but is extremely easy to use. Who is Magcom for? In a word, EVERYONE! For the writers, and people who create publications, Magcom is a GREAT magazine management facility. It allows the authors to easily manage individual articles, full magazines, and entire publications (multiple issues of the same magazine). It creates compressed archives of magazine and publications on command, and allows for the easy distribution of such on-line-creations. FidoNews 10-07 Page 25 15 Feb 1993 For the sysop, almost painlessly, on-line magazines and publications created by authors who also decide to use Magcom (mentioned above), can be viewed, captured, or downloaded by their users. Magcom is the ultimate on-line magazine viewer! (and as far as we know, the only one). For the casual BBS users, Magcom can make your life EXTREMELY easier. No longer are you required to pan through an entire on-line document to get to the part that you want to read. Anything created with Magcom will allow you to view things in an orderly and structured fashion. It even allows you to download individual sections of a publication with the seven internal protocols supplied! The number one objection you will hear from authors, is that magazines distributed in this format would not allow for users of non-based DOS machines to view it. I say, Magcom does NOT have to be a switch of the way their magazines are distributed, but simply an addition. With the thousands of DOS based BBS systems available, distributing magazines in the Magcom format makes nothing but sense. How can Magcom become successful? By you, the system operators and users. If you would like to see your favorite on-line magazines distributed in the Magcom format, you MUST ask the authors of these magazines to take a look at Magcom. Don't harass, but make a simple suggestion. If enough people make the request, eventually they will see the possibilities of Magcom. Since this is the first major release of this type of software, Magcom we may NOT have thought of EVERYTHING that you would like to see within such a program. If you have any comments, suggestions, constructive hate mail (if there is such a thing), please send it to Jasen Fici at the address below. Magcom is being distributed as shareware. It is available from 1:260/445 24 hours a day, 300-14400 with a file request for the magic name : MAGCOM (how original?) You can also obtain it from calling our BBS at (607) 748-5276 also 24 hours. We also have designed a new BBS package known as Harmony BBS that had been released across the country a few months ago. We are working on a majpr update to that software also, but please feel free to call up, take the grand tour, and say hello. (Harmony BBS v1.1a can be FREQ with the magic name HARMONY) ---------------------------------------------------------------------- Christopher Baker 1:374/14, Titusville_FL_USA FidoNews 10-07 Page 26 15 Feb 1993 MENSANS_ONLY Echo MENSANS_ONLY is open to any verified member, past or present, of any Mensa organization. MENSANS_ONLY is not connected with American Mensa, Ltd. [The High IQ Society], or any other Mensa organization anywhere. MENSANS_ONLY has no opinions. Any opinions expressed are those of the writer and any replier. MENSANS_ONLY exists solely to provide a convenient forum for electronic conversation between accepted members of any Mensa organization. Any other inference you may glean from perusing this Echo is all in your head, which is where it should stay. It is Hosted and Moderated from Rights On! in Titusville_FL_USA at 1:374/14. It is intentionally withheld from the FidoNet Backbone distribution system and is offered for point-to-point links only. Any Backbone system discovering this Echo traversing their system should immediately remove it and notify anyone sending or receiving it through them to desist unless said Backbone system is an active and verified participant of MENSANS_ONLY. Anyone may read the traffic in this Echo but only verified members may post in this Echo. Non-members interested in more information about Mensa are directed to the general Mensa Echo of the same name [MENSA] available from the FidoNet Backbone and Moderated by Dave Aronson of 1:109/120. Sysops who link into MENSANS_ONLY agree to abide by the access restrictions above. The content of that Echo is not restricted to any single topic or idea. The number of systems linked to this Echo and the volume of traffic in this Echo varies. Traffic is generally light which is typical of non-Backbone, special interest Echos. Anyone interested in linking into MENSANS_ONLY, should send Netmail to: Christopher Baker at 1:374/14 {Rights On!, Titusville_FL_USA}. The following is a list of primary links for M_O: [Zone 1:] 109/120 114/15 114/74 135/71 250/416 374/14 374/98 380/7 387/31. Zone 2 is also connect thru Holland courtesy of Bob Hirschfeld at 1:114/72. [thanks, Bob!] The Sysops of the above systems may link others into MENSANS_ONLY based on the acceptance of the restrictions, imposed above, by the link requesting Sysop. FidoNews 10-07 Page 27 15 Feb 1993 Anyone requiring a direct feed or further information should send Netmail to me at 1:374/14. Rights On! is a 24 hour system currently at 9600+ bps. It is now at 9600+ on a USR Courier HST dual standard courtesy of their Sysop Purchase Plan. TTFN. Chris ---------------------------------------------------------------------- RADIOS_OLD is an new echo for collectors, traders and restorers of antique radios and televisions. For systems carrying shortwave, ham, or electronic for-sale echos, Radios_Old will fit right in. For the nearest feed, contact Darren Leno at 1:115/747 / (708) 238-1901. ---------------------------------------------------------------------- Christopher Baker Rights On!, 1:374/14 SKEPTIC Echo is alive and well! SKEPTIC is now a Backbone Echo that originally sprang forth from the San Francisco area. It now originates from Zone 3 in Adelaide, Australia under the Moderatorship of Jackson Harding at 3:800/857 and is Hubbed into Zones 1 and 2 by 1:374/14. It is Hubbed into Zone 6 from 3:800/857. The Zone 2 Hub is Dieter Hummel at 2:241/6001. If any of you or your Sysops are interested in obtaining this Echo, you or they should contact their regular, Backbone Echo source! SKEPTIC now appears in FIDONET.NA as of 2 May 92. SKEPTIC is devoted to examination and report of paranormal and fringe-science claims. It has NO official or unofficial connection to CSICOP {Committee for the Scientific Investigation of Claims of the Paranormal} but has a similar philosophy. Claims are not rejected on a priori grounds but rather are investigated by objective and critical inquiry. The Echo is now fully activated and waiting for those with an interest in the mission stated above. Complete information about the Echo may be found in the current issue of the EList and the ELRules files. FidoNews 10-07 Page 28 15 Feb 1993 Come and join us in the pursuit of knowledge! [grin] TTFN. Chris Zone 1 Hub for SKEPTIC ---------------------------------------------------------------------- FidoNews 10-07 Page 29 15 Feb 1993 ====================================================================== FIDONEWS INFORMATION ====================================================================== ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ---------------- Editors: Tom Jennings, Tim Pozar Editors Emeritii: Thom Henderson, Dale Lovell, Vince Perriello IMPORTANT NOTE: The FidoNet address of the FidoNews BBS has been changed!!! Please make a note of this. "FidoNews" BBS FidoNet 1:1/23 <---- NEW ADDRESS!!!! Internet fidonews@fidosw.fidonet.org BBS +1-415-863-2739, 300/1200/2400/16800/V.32bis/Zyxel (Postal Service mailing address) (have extreme patience) FidoNews c/o World Power Systems <---- don't forget this Box 77731 San Francisco CA 94107 USA Published weekly by and for the members of the FidoNet international amateur electronic mail system. It is a compilation of individual articles contributed by their authors or their authorized agents. The contribution of articles to this compilation does not diminish the rights of the authors. Opinions expressed in these articles are those of the authors and not necessarily those of FidoNews. Authors retain copyright on individual works; otherwise FidoNews is copyright 1992 Tom Jennings. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact the original authors, or FidoNews (we're easy). OBTAINING COPIES: The-most-recent-issue-ONLY of FidoNews in electronic form may be obtained from the FidoNews BBS via manual download or Wazoo FileRequest, or from various sites in the FidoNet and Internet. PRINTED COPIES may be obtained from Fido Software for $10.00US each PostPaid First Class within North America, or $13.00US elsewhere, mailed Air Mail. (US funds drawn upon a US bank only.) BACK ISSUES: Available from FidoNet nodes 1:102/138, 1:216/21, 1:125/1212, (and probably others), via filerequest or download (consult a recent nodelist for phone numbers). A very nice index to the Tables of Contents to all FidoNews volumes can be filerequested from 1:396/1 or 1:216/21. The name(s) to request are FNEWSxTC.ZIP, where 'x' is the volume number; 1=1984, 2=1985... through 8=1991. FidoNews 10-07 Page 30 15 Feb 1993 INTERNET USERS: FidoNews is available via FTP from ftp.ieee.org, in directory ~ftp/pub/fidonet/fidonews. If you have questions regarding FidoNet, please direct them to deitch@gisatl.fidonet.org, not the FidoNews BBS. (Be kind and patient; David Deitch is generously volunteering to handle FidoNet/Internet questions.) SUBMISSIONS: You are encouraged to submit articles for publication in FidoNews. Article submission requirements are contained in the file ARTSPEC.DOC, available from the FidoNews BBS, or Wazoo filerequestable from 1:1/23 as file "ARTSPEC.DOC". Please read it. "Fido", "FidoNet" and the dog-with-diskette are U.S. registered trademarks of Tom Jennings, Box 77731, San Francisco CA 94107, USA and are used with permission. Asked what he thought of Western civilization, M.K. Gandhi said, "I think it would be an excellent idea". -- END ----------------------------------------------------------------------