Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!highspl!fithp!mhw From: mhw@fithp (Marc Weinstein) Newsgroups: comp.sys.3b1 Subject: more on the HFC saga Message-ID: <1991May13.010730.4743@fithp> Date: 13 May 91 01:07:30 GMT Distribution: na Organization: Weinstein Consulting Lines: 92 To all those who are still interested... We've discovered quite a bit over the last few weeks about Hardware Flow Control on the 3b1. If the below findings are common knowledge to some, such is life. If anything is incorrect, please post a correction! In my last postings, I stated that a friend of mine and I had tried to get two Practical Peripherals 9600SA modems to talk, transferring files with a port rate of 19200. We were only able to talk consistently at 9600 baud port rates, but had a lot more to try. As stated before, we use the UUCP 'e' protocol and V.42bis, so we get a consistent 960Bps transfer, not bad, but not the best. [BTW: If anyone has purchased one of these modems, do yourself a favor and call the company to get the latest PROMs. We obtained some V1.31 PROMs from them, and they help - quicker connects (protocol negotiation) and less DCD problems causing lost lines.] Well, my friend installed 3.51m (giving us 3.51m on both ends) and we gave things a try at 19200. No luck - same problem. UUCP would get hung during file transfer - it appeared as though the connect bit stream was still too fast for the 3b1 port to keep up (tty000). We had almost given up. Then, just to see what was going on, we wrote a program to check the port configuration using an ioctl() call. We would run it before, during, and after various types of calls. What we found was that the Hardware Flow Control bit (CTSCD) was NOT getting set!!! Even if we checked immediately after calling the /etc/hfc_ctl program, the bit was NOT set. So, we wrote a program to set the CTSCD bit and did some experimentation. Here's what we found... First and foremost, the /etc/hfc_ctl program appears to ENABLE HFC, not turn it on. It seems that this program (somehow) configures the driver so that it pays attention to the CTSCD bit on the port. The trick is to get this bit turned on. The standard getty (/etc/getty) appears to recognize the 'CTSCD' string in the gettydefs file, but the HoneyDanber uugetty does not. It, instead, recognizes the string 'HFC', which should be placed in the gettydefs entry. It should be placed in both the second and third fields of the entry, to make sure it gets turned on during the entire connection. However, the uugetty program doesn't apply these settings until a connection is made. This means that the 'idle' condition of the port is NO HFC turned on. If you happen to try an outgoing call at this time, uucico doesn't set HFC, it just inherits the current state of the line. So, the outgoing call will not have HFC active. In fact, if the HFC bit is set and you kill uugetty, when it restarts the bit will be cleared. The solution (if that's what you can call it) was to write a program to condition the port, and have the program do its stuff right after uugetty has started. The program is actually invoked in the background from a script called from the inittab (rather than directly calling uugetty) - it gives uugetty a certain amount of time to get settled, and then it attempts to condition the port. The script then exec's uugetty. In this way, we can make sure that the HFC bit will be set during the 'idle' state. However, this obviously implies that if an outgoing call were attempted before the program finished execution, there could be an interval where HFC is not on. The other thing we discovered was that uugetty doesn't seem to recognize 19200 baud. We tried using the strings 'B19200' and 'EXTA' in the gettydefs entry, and yet our program which prints out port settings still showed B9600 as the baud rate. So, we added this capability to our port conditioning program. We also installed the patch to the kernel which offloads characters from the interrupt buffer more often - this patch changes the polling of the interrupt buffer from once every 4/60th of a second to once every 1/60th of a second. Unfortunately, with all this in place, we STILL can't get reliable connections with a port speed of 19200. We're seeing a very strange problem right now, where if we try to login, even manually, with the port speed set to 19200, we always get 'Login incorrect', even though the login name we type in is echoed back at us as we would expect. And, it appears that changing the way the 'init' program starts uugetty is not without its flakiness - uugetty doesn't get restarted after an outgoing call (it should, since the modem is configured to reset when DTR goes low). The last possibility would be to switch to the new getty which was posted a while back. We tried using it and saw all sorts of errors. Has anyone gotten this working?? If so, could they post the source they ended up with? Well, if anyone can offer any advice, we'd welcome it. I'd love to hear how those who say they got 19200 HFC to work actually did it. We're beginning to think that, yes, HFC does work, but it doesn't matter because the 3b1 isn't fast enough to administer it properly. By the time it detects overflow and reacts to it, it's too late. Complete conjecture on our part, though... -- Marc Weinstein {simon,royko,tellab5}!linac!fithp!mhw Elmhurst, IL -or- {internet host}!linac.fnal.gov!fithp!mhw