Volume 6, Number 47 20 November 1989 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief: Vince Perriello Editors Emeritii: Dale Lovell Thom Henderson Chief Procrastinator Emeritus: Tom Jennings FidoNews is published weekly by the International FidoNet Association as its official newsletter. You are encouraged to submit articles for publication in FidoNews. Article submission standards are contained in the file ARTSPEC.DOC, available from node 1:1/1. 1:1/1 is a Continuous Mail system, available for network mail 24 hours a day. Copyright 1989 by the International FidoNet Association. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact IFNA at (314) 576-4067. IFNA may also be contacted at PO Box 41143, St. Louis, MO 63141. Fido and FidoNet are registered trademarks of Tom Jennings of Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and are used with permission. We don't necessarily agree with the contents of every article published here. Most of these materials are unsolicited. No article submitted by a FidoNet SysOp will be rejected if it is properly attributed and legally acceptable. We will publish every responsible submission received. Table of Contents 1. ARTICLES ................................................. 1 A Final Word on IFNA Voting .............................. 1 HST (DS) Setup Notes ..................................... 3 IFNA Bylaws and Rules Committee Report ................... 9 IFNA/FidoNet Bylaws Proposal Draft ....................... 11 IFNA/FidoNet Policy Appendix Format ...................... 20 IFNA/FidoNet Policy Proposal Draft ....................... 23 A Visit From My Daisy Maid ............................... 31 2. LATEST VERSIONS .......................................... 33 Latest Software Versions ................................. 33 3. NOTICES .................................................. 36 And more! FidoNews 6-47 Page 1 20 Nov 1989 ================================================================= ARTICLES ================================================================= A Final Word on IFNA Voting Phil Buonomo, 1:107/583@FidoNet 520/583@AlterNet 9:807/1@PNet 1-201-935-1485@NJBell Well, it all comes down to this. Six months ago, I was tired of hearing/reading about the abuses of some misguided *C's. While the great majority of them were good folks, we had no guarantees that the nodes would have their say under Policy 4. That's when I had the idea of instilling democracy through the legitimacy of IFNA. I campaigned for director seats, went to FidoCon, and forced the issue. What we came out with was a network wide election to determine the legitimacy of IFNA. Quite simply, if this vote fails, if less than 50% of the network votes FOR IFNA, I don't believe we'll see democracy in FidoNet at all. All other major proposals to replace Policy 4 are based on a vote of the *C structure, not on a vote of the nodes like the IFNA vote. That means that any new policies will be decided by the people that're going to lose their guaranteed positions under any new policies. This vote decides policies by YOUR vote. But if it fails, the sysops have only themselves to blame. IFNA will dissolve and FidoNet will be back at Policy 4, with the *C's holding all the cards again. Frankly, I'm satisfied that we had the election. In my opinion, no one will be able to say that FidoNet "never had" a chance at democracy again. If you haven't voted yet, I urge you to read thru the draft policy and bylaws published in this issue (if all goes well...). The new IFNA calls for network wide votes for the Board of Directors. It guarantees seats on the board for zones outside the US, and gives a minimum of 2 seats out of 8 to SOMEONE other than the north americans. It gives any zone a maximum of three seats, so that the masses may also be represented. It calls for election of *C members all the way up to the ZC, and since YOU elect the BoD, you in essence elect the IC, as well. Most importantly, the draft policy eliminates the "excessively annoying" clause that's been such a thorn in the side of FidoNet for so many years. Non-technical policy complaints would be a thing of the past. If you can send/receive mail during ZMH, and don't interfere with the technical operations of others, you're in. And if you're in the nodelist, you're a full voting member of IFNA. FidoNews 6-47 Page 2 20 Nov 1989 Some people have said that this was all a "power grab", that we intend to dictate to FidoNet what it can/cannot do. To them I ask, if that were so, why are we holding a network wide election, something Policy 4 and the *C's never did? Why is the entire BoD going to be reseated by next FidoCon? Why are we giving the sysops of FidoNet a chance to vote on accepting or rejecting the proposed policy and bylaws. Some might think that those types are interested in maintaining the power of the *C's, but thats for others to decide. As for the *C's let me say one thing. I've had my doubts about some of them in the past, but most have conducted this election in the spirit in which it was intended. Only one case of 'election rigging' has reached the election committee, and the NC who violated that trust we spoke so much about in September is no longer in FidoNet. I think that speaks a lot about the *C's in general, that they are willing to police themselves when necessary. I would like to thank the *C structure and Matt Whelan and Steve Bonine especially, for carrying out this election. Unless there's massive reports of voter fraud at the last minute, I feel they've done a great job. As a last word, I would just ask that if you haven't voted yet, that you please do so. It would be nice if we could show the world that when it counts, sysops are NOT apathetic. This election could become a shining example of what people can do when they put their minds to it. Let's tear down that "Berlin Wall". Let's have a democratic IFNA. Thank you for your time. ----------------------------------------------------------------- FidoNews 6-47 Page 3 20 Nov 1989 Jim King & John Souvestre FidoNet 1:396/1.3 & 396/1.0 HST (DS) Setup Notes ---------------------- November 12, 1989 This note describes how to set up the U S Robotics Courier HST (14.4K bps), or HST Dual Standard, modem and various IBM-type PC communications programs and FOSSILs, including: BinkleyTerm 2.30 BNU 1.70 DSZ 10/24/89 Opus 1.03b OpusComm 5.31 ProComm Plus 1.1b QModem 4.1b X00 1.20c The first section has some miscellaneous information about running a high speed modem. The next section covers the setup for the HST itself. The remaining sections cover the various communications programs and FOSSILs. If you have any questions, suggestions, or setup information for other programs, please contact us on the New Orleans Tech BBS, FidoNet 1:396/1, 504-885-5928. On this board you will also find a current version of this file under the name HST_SET.ZIP. ================================================================ General Notes on High Speed Modems ------------------------------------ The RS-232C cable connecting the modem to the computer's serial port should have at least the following pins connected: 1, 2, 3, 4, 5, 6, 7, 8, and 20. Get an Ohm Meter, Multimeter, or other form of continuity tester and check your cable. Some connectors have pins which are looped back, and are not connected to the connector at the other end of the cable. To get the "most" out of your HST you will have to set the computer-to-modem speed higher than the modem-to-modem speed. This is called "locking" the serial port, since it won't be operating at the same speed as the modem itself is. Why is this necessary? FidoNews 6-47 Page 4 20 Nov 1989 For a few reasons: Most computer serial ports don't operate at 14400 bps, the basic speed of the HST. Thus the computer has to operate at a higher speed. Because of this, however, the computer and the modem have to be able to "handshake" to prevent overrun, and loss of data. Hardware handshaking, using the RTS and CTS lines (in the cable mentioned above) does the job. Avoid software handshaking, as it is protocol sensitive. Another reason is that the HST does not need to send the start and stops bit which make up part of the the asynchronous data from/to the computer. This means that for every 10 bits of computer-to-modem data, there is only 8 bits of modem-to-modem data. Given that each of these represents one character, the cps (characters per second) rating of both links is the same. When talking about bps (bits per second) however, this means that the computer-to-modem link needs to be 25% faster to keep up with the modem-to-modem link, even though both are at the same cps rate! Now you can see how it is possible to get more that 100% throughput with an HST. Now let's talk about data compression. This adds about 5% overhead to the data you are sending. So, if the data is already compressed, with PKZip for example, then you will probably just end up losing the 5%. If you are sending ASCII text however, the HST's compression will buy you about 50-100% improvement. The HST allows you to set up compression in one of 3 ways: Always on, always off, and do what the other end wants. In general, the calling modem should be set to match the type of transfers it expects to be doing. The answering modem should allow the caller to choose whether he wants compression or not. Transfers using compression, at 14400 bps, should generally lock the serial port at 38400 bps. 19200 bps probably won't be fast enough to allow the modem to run at full speed, depending on the type of file being compressed. In general, unless you expect to be doing lots of transfers using compression, it is our opinion that locking the serial port at 19200 bps is a better way to go. It is less demanding of the computer, thus reducing the changes of losing data in marginal cases. For transferring previously compressed data, where the modem is not doing the compression, 19200 bps will suffice, as the maximum rate you will be able to achieve will approximately 1650 cps, or 16500 bps on the computer-to-modem link. [Note: 1650 cps is 14400 bps, plus 25% due to start/stop bit stripping, minus about 8% for modem-to-modem overhead.] FidoNews 6-47 Page 5 20 Nov 1989 For the rest of this note we will assume that you want to lock the serial port at 19200 bps. If you want to lock at 38400 bps instead, just change the "19200"s to "38400"s. Some communications programs and most FOSSILs allow you to specify the size of the receive and/or transmit buffers. The best size will depend on many factors, and may require a bit of testing on your part. For starters however, we recommend that you make the transmit buffer 1K and the receiver buffer 2K. If you are running under a multi-tasking operating system then you might want to start with both set to 4K. One thing that you will notice when running a high speed modem is that all file protocols are not created equal! Protocols which require an "Ack" for every block sent do not perform well. Thus you will want to avoid XModem, for example. YModem does better because it uses a larger block size. Streaming protocols, such as ZModem, work fine. However, avoid protocols like YModem-G, which use error detection, but no error recovery, simply aborting the transfer upon an error. Although the modem-to-modem transfer is guaranteed by a 16 bit CRC used by the modems themselves, errors can still occur between the computer and the modem at either end. In some situations it is not uncommon to lose an occasional character (see below). It is not worth this chance for a less than 1% speed advantage. We highly recommend replacing the serial interface chip (UART), a 8250 or 16450, with a 16550a. This chip contains a 16 character FIFO, as opposed to a double buffer. If your communications program makes use of the FIFO, it will allow you longer interrupt latency and/or less interrupt overhead. Various manufacturers make versions of the 16550a. National Semiconductor was the first. Their full part number for the 40-pin DIP is NS16550AN. In all the cases that follow we recommend installing a 16550a. In some of the cases alternatives are also presented. Some computers (particularly 4.77 MHz, 8088 machines) are not fast enough to support 19200 or 38400 bps. If you have this type of computer, you can use 9600 bps instead, but this will not give you the HST's full speed. Certain disk controllers, with 1:1 track buffers, can cause problems. Perstor disk controllers can also cause problems. We understand that Perstor has a BIOS upgrade which helps. If you are running a program that makes heavy use of extended memory, like a RAM Disk or a Cache, you may lose characters. This is mainly a problem on 286 machines. With some programs, like VDisk, reducing the sector size and/or the number of sectors transferred at a time will help. FidoNews 6-47 Page 6 20 Nov 1989 Certain TSRs interfere with communications programs. If you