ejnihill@sactoh0.UUCP (Eric J. Nihill) (11/21/88)
I am going to be installing a TB+ on a 3B2/310 and rather than
re-invent the wheel, I would like to find out what S Register
settings that others have used on 3B2/310 & 400's. Also, are
there any tricks to setting up the Devices and Dialers files?
I have the paper that TB sent, and it seems pretty straight
forward.
Thank-you;
Eric
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| In God We Trust, || ...pacbell!sactoh0!ejnihill |
| All Others Pay Cash. || Flick Lives! |
-_-_-_-_-_-_-_-_-_-_J.S.-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-rk@bigbroth.UUCP (rohan kelley) (11/23/88)
In article <557@sactoh0.UUCP>, ejnihill@sactoh0.UUCP (Eric J. Nihill) writes: > I am going to be installing a TB+ on a 3B2/310 and rather than > re-invent the wheel, I would like to find out what S Register > settings that others have used on 3B2/310 & 400's. Also, are > there any tricks to setting up the Devices and Dialers files? > I have the paper that TB sent, and it seems pretty straight > forward. > Thank-you; > Eric Eric - this is the memo I did when I installaed my telebit. It may help you avoid some pitfalls. MEMO From: Rohan Kelley (novavax!bigbroth!rk) Date: 4-14-88 Subject: TELEBIT MODEM SETUP **** System paramaters and settings for modem. **** The /etc/inittab line setup for 2400 baud (assuming use of tty33) should be: 33:2:respawn:/usr/lib/uucp/uugetty -r -t 60 tty33 2400H # trailblazer modem for 9600 baud, it would be: 33:2:respawn:/usr/lib/uucp/uugetty -r -t 60 tty33 9600H # trailblazer modem for 19,200 baud it would be: 33:2:respawn:/usr/lib/uucp/uugetty -r -t 60 tty33 19200H # trailblazer modem The ps -ft tty33 (at 2400 baud ) should look similar to: root 16349 1 0 20:44:00 tty33 0:01 /usr/lib/uucp/uugetty -r -t 60 tty33 24 and at 19,200 baud ... root 28981 1 0 11:13:03 tty33 0:01 /usr/lib/uucp/uugetty -r -t 60 tty33 19200H The /etc/gettydefs line should be: 2400H# B2400 # B2400 SANE IXANY TAB3 HUPCL #login: #1200H and 19200H# B19200 # B19200 SANE IXANY TAB3 HUPCL #login: #9600H [You can confirm the /etc/inittab, ps -ft and /etc/gettydefs entries with the commands: grep 33: /etc/inittab ps -ft 33 grep 2400H# /etc/gettydefs The /usr/lib/uucp/Devices file must include these entries: ACU tty33 - 19200 tbfast ACU tty33 - 2400 tb2400 ACU tty33 - 1200 tb1200 ACU tty33 - 9600 tbfast Direct tty33 - 19200 direct \D The /usr/lib/uucp/Dialers file must include these entries: tbfast =W-, "" A\pA\pA\pT OK \pATS51=254DT\p\D\r\c CONNECT\sFAST tb2400 =W-, "" A\pA\pA\pT OK ATDT\D\r\c CONNECT\s2400 tb1200 =W-, "" A\pA\pA\pT OK \pATS50=2DT\p\D\r\c CONNECT\s1200 **** Settings for the modem itself **** Reach the modem with the command: cu -l tty33 | tee (file_name) Note, this will make a record of the standard out (screen) and in the file named (file_name), which you can then print. When you get the indication, CONNNECTED, give the command at [return] until you receive the response, OK. To set the modem to run at fast speed using the UUCP g protocol, the command line when CONNECTED to the modem is: at &f s51=254 s52=2 s54=3 s110=1 s111=30 s45=0 q6 &w [return] Then type atn? [return]. The current modem settings will print in the screen and also a copy is made in the file, file_name. The response should look like: at OK atn? E1 F1 M1 Q6 P V1 X3 Version BA4.00 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006 S10=007 S11=070 S12=050 S45=000 S47=004 S48=000 S49=000 S50=000 S51=254 S52=002 S53=000 S54=003 S55=000 S56=017 S57=019 S58=003 S59=000 S60=000 S61=045 S62=003 S63=001 S64=000 S65=000 S66=000 S67=000 S68=255 S90=000 S91=000 S92=000 S95=000 S100=000 S101=000 S102=000 S104=000 S110=001 S111=030 S112=001 S121=000 N0: N1: N2: N3: N4: N5: N6: N7: N8: N9: OK You can reset modem settings while CONNECTED to the modem with the command: ats0=1. This command sets the contents of register 0 to 1. See page 3-8 of the manual. ======================================================================= Rohan Kelley -- UNIleX Systems, Inc. (Systems and software for lawyers) UUCP: ...{gatech!uflorida,ucf-cs}!novavax!bigbroth!rk ATTmail: attmail!bigbroth!rk 3365 Galt Ocean Drive, Ft. Lauderdale, FL 33308 Phone: (305) 563-1504 "Go first class or your heirs will" -somebodyelse =======================================================================
eric@sactoh0.UUCP (Eric J. Nihill) (07/24/90)
I am attempting to convert a TB+ to on a AT&T 3B2/310 to Hardware
Flow Control.
(SVR3.2, EPORT Board, NCLIST=300)
I have already connected it up and and am getting fairly decent flow
using XON/XOFF control.
Here is the output from my TB+ connections. As you can see I can xmt
at a fairly decent rate, but my rec rate is poor. I am hoping that
converting to hardware flow control will help.
System Xfers Bytes rec Bytes xmt Connect Avg Xf Avg rec Avg xmt
============================================================================
csusac 58 613271 15366 0:14:47 10838 700 1306
pacbell 166 107262 181665 0:08:10 1740 365 923
pacengr 18 0 248993 0:03:13 13832 0 1288
I set S/REG58=2 and S/REG 67=01 in the TB+.
I changed the initab to read:
41:234:sh -c `stty -ixany -ixon -ixoff; epstty hfc; stty ixon ixoff; exec /usr/lib/uucp/uugetty -r -t 45 tty41 19200H`
I am using an "Automatic Call Unit (ACU) Modem" Connector (fig 2-7, pg 2-11
Enhanced Ports Manual, Issue 2)
Whenn I connect to the modem configured above, I get a utmp error and am
told that I must log in in the lowest level shell.
This port must be able to be used by dial up users at 12/24 and systems
at 12/24/19.2. The TB+ must also call systems at 19.2
I purchased the E-PORTS board used, I did not get the epstty(1) or eptermio(7) additions. Only the manual.
There must be a way that I can set tty41 to be hardware flow control
once and not have to keep resetting it by opening a shell. I think
that that may be the problem, but am not sure.
Any guiding light would be appreciated.
Thank-you;
Eric
--
Some do, some don't. | eric@sactoh0
Some will, some won't. | ames!pacbell!sactoh0!eric
I might! | ucbvax!csusac!sactoh0!eric
| USMail 95611-0785woods@robohack.UUCP (Greg A. Woods) (07/25/90)
In article <3580@sactoh0.UUCP> eric@sactoh0.UUCP (Eric J. Nihill) writes: > System Xfers Bytes rec Bytes xmt Connect Avg Xf Avg rec Avg xmt > ============================================================================ > csusac 58 613271 15366 0:14:47 10838 700 1306 > pacbell 166 107262 181665 0:08:10 1740 365 923 > pacengr 18 0 248993 0:03:13 13832 0 1288 Those numbers look quite low for 19200. > I changed the initab to read: > 41:234:sh -c `stty -ixany -ixon -ixoff; epstty hfc; stty ixon ixoff; exec /usr/lib/uucp/uugetty -r -t 45 tty41 19200H` Why the "stty ixon ixoff" again? It won't do anything. > Whenn I connect to the modem configured above, I get a utmp error and am > told that I must log in in the lowest level shell. You might try putting the 'sh -c' bit in paren's with a redirect of stdin from the port in question. But.... > I purchased the E-PORTS board used, I did not get the epstty(1) or eptermio(7) additions. Only the manual. Then how did you get the driver loaded? Better find a copy of the EPORTS disk, 1.3 is the newest version I've seen (came with 3.2.2). > There must be a way that I can set tty41 to be hardware flow control > once and not have to keep resetting it by opening a shell. I think > that that may be the problem, but am not sure. If you have the eptermio(7) man page, and the header files /usr/include/sys/{ep_dep.h,ep_lla.h,eppc.h}, then write your own version of epstty. It's not all that hard! Then you can have a fake front-end to uugetty that sets hfc, then execs the getty. You could even get a copy of one of the PD uugetty's. They seem to work fine too. -- Greg A. Woods woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA
brian@ucsd.Edu (Brian Kantor) (07/25/90)
My experience with the 3B2/310 is that it can't handle 19200 bps sustained flow such as it would get using a trailblazer in uucp spoof mode. It drops characters and thus uucp does lots and lots of retries. Dropping down to 9600 bps actually increased uucp performance in my tests. This is particularly true of the console and contty ports, and is true of the ports board as well, but to a lesser extent. Note that the retries are between the 3B2 and the modem - the other end of the connection will never see them, since the modem is spoofing the protocol. You need to run the 3B2 in debug to even see it happening, and you might not be able to get an idea of the delays involved unless you stick a serial-line data monitor between the port and the modem. I believe the E-ports board in the large 3B2s can handle 19200 better than that, but I've never gotten around to trying it on our 3B2/1000s. - Brian
pim@cti-software.nl (Pim Zandbergen) (07/25/90)
brian@ucsd.Edu (Brian Kantor) writes: >I believe the E-ports board in the large 3B2s can handle 19200 better >than that, but I've never gotten around to trying it on our 3B2/1000s. There is also a lot of difference between PORTS boards that are marked with HPP and those that are not. The latter are practically useless for uucp. -- Pim Zandbergen domain : pim@cti-software.nl CTI Software BV uucp : uunet!mcsun!hp4nl!ctisbv!pim Laan Copes van Cattenburch 70 phone : +31 70 3542302 2585 GD The Hague, The Netherlands fax : +31 70 3512837
friedl@mtndew.UUCP (Stephen J. Friedl) (07/28/90)
In article <16192@ucsd.Edu>, brian@ucsd.Edu (Brian Kantor) writes: > My experience with the 3B2/310 is that it can't handle 19200 bps > sustained flow such as it would get using a trailblazer in uucp spoof > mode. It drops characters and thus uucp does lots and lots of retries. > Dropping down to 9600 bps actually increased uucp performance in my > tests. > > This is particularly true of the console and contty ports, and is true > of the ports board as well, but to a lesser extent. The 3B2 has five different possibilities for serial I/O that I know of: console/contty 1 serial each PORTS 4 serial + 1 parallel PORTS / HPP 4 serial + 1 parallel EPORTS 8 serial fiber + expander various combinations The last takes just one slot and lets you put lots of ports (up to 32 or 64 or so), but I don't know much about it so I will defer on it. I also am not counting any Starlan issues (if any). All 3B2s have console and contty ports, and these ports are on the motherboard and serviced by the main CPU (by the DUART driver). They can handle quite a good data rate -- sustained full 19200 bps output -- but they degrade quickly when the system gets busy. We tell our customers to stick a 2400bps modem on the contty port because that's a pretty slow speed and is likely to be working even if the other serial cards go down (so we can dial in and fix stuff). Next is the PORTS board. These are worthless. In my tests, an unloaded 14MHz 3B2/310 (40% faster than standard) can only do about 6500bps output on a raw port, so clearly 9600bps is out of the question. Furthermore, there is a bug in the PORTS driver where backspaces always have delays in certain common modes. Try this on your PORTS board: echo 'xxxxxxxxxxxxxxxxxxxxx\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b' and watch it dump out the Xs very quickly and then take its time moving the cursor back. It can be maddening, so I "fixed" it by define the cursor-left character in terminfo as ESC[D. Sending three characters is MUCH faster than waiting on the delays. PORTS HPP is purported to be a high-performance version, but I don't know much about it (others are welcome to chime in here). I have heard that this was originally developed with the military in mind, but that very well could be idle gossip. I don't know if it has the same backspace delay bug. Last is EPORTS, which is a throughput monster. It's got a smart little 80188 or something like that, high-end Zilog serial controllers plus DMA channels for each. These things can do sustained 19200bps input/output on multiple ports without dropping a bit, and in general are very fast. They support CTS/RTS flow control, but it is done in a way that makes them not very helpful for many of us. The big bug is that CTS/RTS is mutually exclusive of XON/XOFF -- you can never run both at the same time. I would love to turn on HFC permanently and tell my Telebit to always run at 19200 in locked interface mode, and then allow dialin users to call in at (say) 2400bps and have them flow-control down to the right speed. Sure, the CTS/RTS works fine between the modem and the port, but the user hitting ^S on his/her end will be ignored. I use a TeleVideo 9220 and I tried hooking it up to use DTR handshaking. It worked great until I hit a ^S to stop some output. Because CTS/RTS was enabled, the ^S was echoed back to my terminal, locking it up. Wonderful. Anyway, the design of the board also means that using XON/XOFF at really high data rates will have significant problems. Rather than have each incoming character interrupt the EPORTS CPU, instead the UART just dumps it into local RAM via the DMA channel. Then, at periodic intervals, the onboard CPU looks at each input queue and transfers the data to the 3B2's I/O system. It's quite a slick system. The bummer is that an XOFF arriving from the other end won't be seen right away. Let's say that the XOFF arrives just after that particular queue has been examined by the onboard CPU. It will take some amount of time before its turn comes again, and at high data rates this time can be significant. I'm told that "skid" of 32 or 64 characters is not uncommon, and all the HP LaserJets that I've seen can't deal with this. You gotta either slow it down, use hardware flow control, or use a parallel port. Finally, the EPORTS have had >tremendous< problems in the past with bugs. I have had several customers ready to throw their computers out the window due to EPORTS problems, and only in the last year or year and a half has it been better (with the 1.3 driver). I understand that the EPORTS folks in Lisle had a very miserable summer of 1988. Whew! Steve -- Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl "I'm a simple girl; I wear a cat on my head." - Laura Dykstra @ NCR Orlando
pjh@mccc.uucp (Pete Holsberg) (07/28/90)
Speaking of EPORTS, HFC, XON/XOFF and Trailblazer Plusses, I have a question about setup when transferring files to an EPORT-equipped 3B2/400 from a 386 running MSDOS and ProYAM. (FROM the 3b2, no problem.) I always get "Got ZRPOS errors" every 8-9K when uploading to the 3B2. I'm already set for "handshake slow", but it seems that without HFC, I'm doomed to error recoveries and very slow transfer rates. Is there a way to change the setups of the two 'blazers temporarily to reduce or eliminate the errors? Is there a wway to turn on HFC remotely (I have a second phone line so I could call in on it and do something with the EPORT and/or the other 'blazer)? Thanks, Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690
elliot@alfred.UUCP (Elliot Dierksen) (07/28/90)
One small side note on this. Instead of using a shell script to do stty's
after login and then execute uucico, why don't you just create an entry in
/etc/gettydefs that does what you want?? that would work just fine!
EBD
--
Elliot Dierksen "I don't care if my lettuce has DDT on it,
as long as it's crisp!!" -- Jorma Kaukonen
Work) candi.att.com!fang!ebd%ralph (407) 660-3377
Home) elliot@alfred.UUCP (407) 290-9744woods@robohack.UUCP (Greg A. Woods) (07/29/90)
In article <470@mtndew.UUCP> friedl@mtndew.UUCP (Stephen J. Friedl) writes: > All 3B2s have console and contty ports, and these ports are on the > motherboard and serviced by the main CPU (by the DUART driver). They > can handle quite a good data rate -- sustained full 19200 bps output -- > but they degrade quickly when the system gets busy. We tell our customers > to stick a 2400bps modem on the contty port because that's a pretty slow > speed and is likely to be working even if the other serial cards go down > (so we can dial in and fix stuff). Even sustained UUCP at 2400 on contty can be a significant load on a system. However, it is true that contty will likely be one of the last ports on a system to die. > moving the cursor back. It can be maddening, so I "fixed" it by > define the cursor-left character in terminfo as ESC[D. Sending > three characters is MUCH faster than waiting on the delays. I've never seen this. I know it is possible to put backspace delays on a port inside the termio driver. Perhaps the default on PORTS was to use this delay (for those old 33's you know). I would hope you could turn off the delay with an ioctl() though. > PORTS HPP is purported to be a high-performance version, but I > don't know much about it (others are welcome to chime in here). > I have heard that this was originally developed with the military > in mind, but that very well could be idle gossip. I don't know > if it has the same backspace delay bug. This one does seem to work just fine, though it lacks hardware flow control. I ran two 2400 bps modems, and my dmd at 19200 on it for quite some time with no problems. > They support CTS/RTS flow control, but it is done in a way that > makes them not very helpful for many of us. The big bug is that > CTS/RTS is mutually exclusive of XON/XOFF -- you can never run > both at the same time. This is a serious design flaw in the EPORTS driver and firmware! > data rates this time can be significant. I'm told that "skid" of > 32 or 64 characters is not uncommon, and all the HP LaserJets > that I've seen can't deal with this. You gotta either slow it down, > use hardware flow control, or use a parallel port. It's too bad you can't set the port priorities in order to close the window. > Finally, the EPORTS have had >tremendous< problems in the past > with bugs. I have had several customers ready to throw their > computers out the window due to EPORTS problems, and only in the > last year or year and a half has it been better (with the 1.3 > driver). I understand that the EPORTS folks in Lisle had a very > miserable summer of 1988. The still do. Well, maybe not quite as bad. I seriously wonder if any of the drones at AT&T can write firmware (the 705 MT's I've been testing have serious firmware problems, even at rev.1.2). The EPORTS with 1.3 drivers still hangs occasionally on every modem except the AT&T 2224B. I've put my 1200 on the PORTS/HPP card, but the Microcom I had for a while required HFC, and was a real pain in the butt. I've seen reference (in the newest 3.2.2 docs) to a new command (relport) (though I've not tried it yet), which the documentation purports to be able to release a port from a hang without re-pumping the card (and dropping all connections). It is a real screamer though! -- Greg A. Woods woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA