dale@convex.com (Dale Lancaster) (11/22/89)
I am evaluating 9600 baud modems to attach to the serial port on my 7300 for terminal emulation. I currently have a Microcom QX/12K I am using on loan and it seems to me that I am not getting 9600 baud throughput even though all the status indicators say such. Can I assume that the 7300 can (using cu) keep up with 9600 baud on the serial line? I would think any decent computer including my Apple IIE could handle this. My reason for doubting is that a full screen update takes on order of 5-6 seconds, I am used to about 2-3 seconds when running full bore on a direct connect terminal at work, running a true 9600 baud. Also, I realize that the Microcom is not a real 9600 baud modem (it uses 3 to 1 data compression on a 4000 baud interface), but before I start trying other modems, I need to verify that the 7300 isn't the real bottle neck. I would appreciate Anyone using 9600 on a 7300 giving some feedback about what they see. thanks in advance dale ...!uunet!convex!dale still working on fancy signature line.
ecf_hap@jhunix.HCF.JHU.EDU (Andrew Poling) (11/23/89)
In article <3311@convex.UUCP> dale@convex.com (Dale Lancaster) writes: > >I am evaluating 9600 baud modems to attach to the serial >port on my 7300 for terminal emulation. I currently >have a Microcom QX/12K I am using on loan and it seems to me >that I am not getting 9600 baud throughput even though all >the status indicators say such. Can I assume that the 7300 >can (using cu) keep up with 9600 baud on the serial line? >I would think any decent computer including my Apple IIE >could handle this. Not true. My Apple II+ dropped characters at 4800 baud. And that was straight throughput - no terminal emulator. What really killed it was/were carriage-returns. >My reason for doubting is that a full screen update takes on order >of 5-6 seconds, I am used to about 2-3 seconds when running full >bore on a direct connect terminal at work, running a true 9600 baud. >Also, I realize that the Microcom is not a real 9600 baud modem >(it uses 3 to 1 data compression on a 4000 baud interface), but >before I start trying other modems, I need to verify that the 7300 >isn't the real bottle neck. I have never witnessed my UNIXpc (3b1 with 2.5M/40M and plenty of active drivers including ethernet, usually 30-35 proccesses running) handling 9600 baud incoming without flow control coming into play. But there may be other factors. Perhaps the termcap you are using calls for excessive padding on certain events. In other words, the change in terminal types may cause a difference in apparent transfer rate. -Andy
rick@kimbal.lynn.ma.us (Rick Kimball) (11/23/89)
From article <3311@convex.UUCP>, by dale@convex.com (Dale Lancaster): > > I am evaluating 9600 baud modems to attach to the serial > port on my 7300 for terminal emulation. I currently > have a Microcom QX/12K I am using on loan and it seems to me > that I am not getting 9600 baud throughput even though all > the status indicators say such. Can I assume that the 7300 > can (using cu) keep up with 9600 baud on the serial line? > I would think any decent computer including my Apple IIE > could handle this. I read somewhere that cu can only handle about 2400 baud. One way to verify it would be to connect a null modem cable between the two serial ports on your machine and do some timing tests using cu. I've got one of my serial ports hardwired to a Macintosh. Using my own terminal program on the Mac I can get about 18K baud zmodem transfers. How about using pcomm instead? It does a nice vt100 emulation and supports all the popular transfer protocols. Rick Kimball INTERNET: rick@kimbal.lynn.ma.us UUCP: ...!spdcc!kimbal!rick, ...!spt!kimbal!rick Personal USENET Site POTS: (617) 599-8864
jb@altair.uucp (John Birchfield) (11/24/89)
In article <1075@kimbal.lynn.ma.us> rick@kimbal.lynn.ma.us (Rick Kimball) writes: >From article <3311@convex.UUCP>, by dale@convex.com (Dale Lancaster): >> >> I am evaluating 9600 baud modems to attach to the serial >> port on my 7300 for terminal emulation. ... > >I read somewhere that cu can only handle about 2400 baud. One way to >verify it would be to connect a null modem cable between the two >serial ports on your machine and do some timing tests using cu. > Another thought ... If you are using ua (the user agent) instead of having multiple gettys for different windows your screen updating will be significantly slower with cu - I remember that cu became a whole lot better to use after I trashed ua. I still use pcomm 'cause it's a lot more flexible. +----------------------------------------------------------------------+ | John Birchfield 1575 Quail Ct., Turlock, CA 95380 | | jb@altair.csustan.edu Tel: (209) 634-6243 | +----------------------------------------------------------------------+
thad@cup.portal.com (Thad P Floryan) (11/24/89)
Dale Lancaster in <3311@convex.UUCP> laments the apparent slow data transfer
while evaluating a Microcom QX/12K modem at 9600 baud on his UNIXPC.
The "problem" (as it were) is the window driver for the UNIXPC and its s-l-o-w
screen writes.
The UNIXPC itself is more than capable of handling 19,200 baud over its
serial port(s).
Lenny Tropiano (and others) have Telebit modems which, in PEP mode, have been
reported by them as successfully and continuously achieving true data rates
in excess of 1100 bytes per second over the serial port.
I use Digicom 9624LE V.32 modems and also enjoy the same data rates, as I also
do with direct-connect serial-serial connections to other computers from the
UNIXPC.
The above transfer rates are for uucp (either e or g protocol) and, as I've
also verified, for zmodem.
Dale hinted he was using ``cu'' for his tests, and my recollection of cu's
docs is that cu artificially slows the data rates so you can read what's
appearing on the screen! :-)
The combination of cu's throttling-back and the window manager's slowness
will produce the apparent slowness observed by Dale.
As a suggestion for modem evaluation, get a second modem and call into your
UNIXPC from a { system | terminal } which is known to meet your specs, and
THEN evaluate the throughput. I believe you'll be pleasantly surprised.
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]thad@cup.portal.com (Thad P Floryan) (11/24/89)
As another suggestion when evaluating modems or whatever, if you have a modern terminal emulating a VT100(tm DEC), do NOT select VT100 mode when you log into your UNIX system; select, instead, DT80 which is a VT100 without all the brain-damage. In other words, DT80 mode does not have to send the humongous number of pad characters to accomodate the slow 8080 in a real VT100. The DT80 terminal (yes, I have some) is properly known as a DT80/1 and was manufactured by Datamedia Corp. It is one of the few PERFECT clones (and without the bugs) of a VT100. And when I say ``PERFECT'', I mean it. I have the Per Lindberg VT100 validation suite, and the DT80 passes. 99.999% of the terminals and/or the terminal-emulators available in the world today will FAIL the Per Lindberg test within just a few seconds (and the test normally takes approx. 10 minutes to run to completion). ``dt80'' is available in all termcap and terminfo data bases I've seen (i.e. it's on the UNIXPC, SysV, HPUX, etc.) Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
gst@gnosys.svle.ma.us (Gary S. Trujillo) (11/24/89)
In article <3311@convex.UUCP> dale@convex.com (Dale Lancaster) writes: > > I am evaluating 9600 baud modems to attach to the serial > port on my 7300 for terminal emulation... That reminds me - the Telebit Trailblazer discount deal lasts only until the end of December. They're available to half-price ($672.50 for the TB+) to folks with valid domain addresses (which are easy to get - just contact Ann Westine at ISI (westine@isi.edu)). For more details on the 'blazer deal, contact Tessie Ople at Telebit (tessie@telebit.com). Disclaimer: I have no connection with Telebit, Inc. whatsoever. However, I am about to order a Trailblazer for my own use. -- Gary S. Trujillo gst@gnosys.svle.ma.us Somerville, Massachusetts {wjh12,spdcc,ima,cdp}!gnosys!gst
wtm@neoucom.UUCP (Bill Mayhew) (11/24/89)
Cu is not a good way to judge the throughput of your serial connection. One obvious problem is that if you are logged in at the console of the UnixPC, you are using /dev/w... for tty output. The window driver has to do processing of the escape sequences, and deal with the bitmap of the window to display the output. Chances are, what you are seeing are the delays of the console driver and not the modem/port itself. There are also two flavors of cu. The stock cu that comes with the machine writes each character to stdout as it is received. This is s-l-o-w, and in fact can't even keep u with a 1200 buad modem. The cu that comes with Honey DanBer uucp is much better. It buffers something like 64 characters and writes them to stdout all at once. Of course, there is a time-out such that the characters are written anyway after a certain delay, even if an entire 64 aren't received. The HDB cu can keep up close to 4800 baud output to the console. Speaking of uucp, there's the ticket for gauging throughput more fairly. You have to make sure that you send big files though, as the LOGFILE or xferstats includes the overhead of closing the file in the char/sec times it reports. 30Kbyte minimum files for fair resuls are needed. My tests show that a UnixPC can keep up a steady rate of 1200-1400 char/sec in uucp if there aren't any other piggy processes running. With smart high speed modems, the best results obtain when the CPU feeds the modem at a higher rate than the physical transport will support, and allowing the modem to mediate flow. This works particularly well with the uucp spoofing in the Trailblazer mdoem since the uucp packets are small, and the modem can mediate flow by simply stopping ACKing packets for a while. Uucp will gag if the modem inserts an Xoff (control S) character in the data stream in attempt to do in-band flow control. While not pure ANSI RS232 spec, the Unix C does do hardware flow control with the RTS/CTS modem leads. The RS232 spec defines the leads only for initial handshake, so the Unix PC is in essence an upward compatible extension of the standard. The default for hardware flow control is OFF. The tty driver defaults to xon/xoff flow control. Use /etc/hfc +/dev/tty00x to endable HFC. One side effect is that you can not have your cake and eat it too. You will lose xon/xoff recognition when you turn on HFC. With the Trailblazer, it is best to leave xon/xoff enabled, since the packets are small enough in uucp to not need flow control. For the record, the only terminal I have used that actually has full cursor addressability and all the bells and whistles of a smart terminal AND can keep up a steady 9600 baud throughput without any flow control is an HP 2645. Of course, there may be others, but the 2645 is the only one I have seen. The 2645 was designed around 1976, and has a TTL bit slice processor; it is also about the size of a Yugo. An Apple ][ will not come anywhere close to displaying at 9600 baud on its console if you use the I/O routines in the monitor ROM. This is espically true if you have an Apple //e - enhanced model with the 65C02 and new ROMs with mouse support. The ROMs switch off interrupts for ~30 mS at various points so the mouse can be read (like when you write a CR to the display). I know about this from an Apple program I wrote that had to keep track of a A/D board and write to the console at the same time. It was a major pain in the neck on that machine. Even a program like Proterm that doesn't use the monitor I/O can't keep up becasue too much CPU time is required to swap bytes around in the screen character buffer to effect scrolling ... especially true if the 80 column screen is in use on a //e. Put a data monitor on the Tx leads of your apple and then cat a file to it at 9600; chances are good that the comm program will be sending a lot of xon/xoff to keep from dropping characters. Don't feel bad; a VT-240 will start to send xon/xoff at 2400 buad in text mode even without any cursor addressing! Cheers, Bill
bdb@becker.UUCP (Bruce Becker) (11/25/89)
In article <24425@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: |[...] |And when I say ``PERFECT'', I mean it. I have the Per Lindberg VT100 |validation suite, and the DT80 passes. 99.999% of the terminals and/or the |terminal-emulators available in the world today will FAIL the Per Lindberg |test within just a few seconds (and the test normally takes approx. 10 minutes |to run to completion). Is this validation suite available, and if so, is it public domain, or shareware? Thanks for any info, -- ^^ Bruce Becker Toronto, Ont. w \**/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/v/-e BitNet: BECKER@HUMBER.BITNET _/ >_ Ceci n'est pas une | - Rene Macwrite
wtm@neoucom.UUCP (Bill Mayhew) (11/26/89)
In article <1841@neoucom.UUCP>, I write: > While not pure ANSI RS232 spec, the Unix C does do hardware flow > ^^^^^^ > control with the RTS/CTS modem leads. In the sentence above, "Unix C," should read, "Unix PC". The P key on my 3b1 was sticking and dropping the letter P here and there. That one escaped my detection as I was typing. The C compiler per se has nothing to do with support of any particular flow control. I just wanted to clear that up. I took off the keycap on the P and doused the key post with alcohol. The weird thing is that the Unix PC keyboard is ferromagnetic sensing (like core memory), and as long as the button goes down, everything should work OK. It appeared that the key depressed normally, but failed to register a keystroke about 1/2 the time. After clean-up everything was fine ... eventhough the qualitative feel was the same before and after cleaning. Hmmm.... Bill
gil@limbic.UUCP (Gil Kloepfer Jr.) (11/26/89)
In article <24425@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >without all the brain-damage. In other words, DT80 mode does not have to >send the humongous number of pad characters to accomodate the slow 8080 >in a real VT100. The real VT100s have an 8037 micrcontroller (it's a preprogrammed MCU), not an 8080 (at least mine doesn't anyhow...). They do use some 8080-type support chips though to do some of the work. On an aside, this *is* the reason why the DEC VT100 is so slow. The VT220s I think might also use MCUs, but it's MUCH faster, and will show 19.2K really well! Also note, in line with what Thad has already said, using a terminal on the UNIX-pc rather than the built-in display for just text-based stuff, like reading the news, is definitely faster. The VT100 I use at 9600 baud (because of the speed problem) in the living room is still faster than the 3B1 display! A problem I *have* noticed is calling at Trailblazer speed to a system from my VT100 *through* the UNIX-pc results in many lost characters on my receiving end. I'm not sure whether this is due to the 3B1 not being able to handle 2 serial ports at high-speed, or the VT100 being too slow and causing too many characters to be queued-up at the device driver level. In any event, forcing the Telebit speed to 9600 baud doesn't fix the problem. Gil. ----- | Gil Kloepfer, Jr. | ICUS Software Systems/Bowne Management Systems (depending on where I am) | ...ames!limbic!gil
jbayer@ispi.UUCP (Jonathan Bayer) (11/26/89)
wtm@neoucom.UUCP (Bill Mayhew) writes: >In article <1841@neoucom.UUCP>, I write: >In the sentence above, "Unix C," should read, "Unix PC". The P key >on my 3b1 was sticking and dropping the letter P here and there. >That one escaped my detection as I was typing. >I took off the keycap on the P and doused the key post with >alcohol. The weird thing is that the Unix PC keyboard is >ferromagnetic sensing (like core memory), and as long as the button >goes down, everything should work OK. It appeared that the key Sometimes there is some dirt that prevents the button from going down all the way. It doesn't take that much distance (less than a millimeter) to prevent the magnetic sensing from working. By dousing it with alcohol you probably washed the dirt away. JB -- Jonathan Bayer Intelligent Software Products, Inc. (201) 245-5922 500 Oakwood Ave. jbayer@ispi.COM Roselle Park, NJ 07204
mdapoz@hybrid.UUCP (Mark Dapoz) (11/28/89)
In article <581@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes: >A problem I *have* noticed is calling at Trailblazer speed to a system >from my VT100 *through* the UNIX-pc results in many lost characters >on my receiving end. I'm not sure whether this is due to the 3B1 not >being able to handle 2 serial ports at high-speed, or the VT100 being >too slow and causing too many characters to be queued-up at the device >driver level. In any event, forcing the Telebit speed to 9600 baud >doesn't fix the problem. I use a Wyse 50+ as a terminal on my 3B1 and I run it at 19.2K baud (anyone know how to get 38.4K baud out of the serial ports?). The terminal is hooked up to one port of the combo card and the 'blazer is on the other port. I've called other systems at PEP speeds using the terminal and I always lose characters, but if I call using the console everything is ok. I have the 'blazer talking to the 3B1 at 19.2K so there isn't a speed mismatch between the terminal and modem. I've also noticed that I don't get any speed degregation on the terminal when I've got a uucp transfer taking place on the modem so I doubt that the device driver is at fault. I know the terminal can handle the speed because I've used it with other systems at 38.4K baud without any problems. Any other ideas? -mark -- Mark Dapoz (mdapoz@hybrid.UUCP) ...uunet!mnetor!hybrid!mdapoz I remind you that humans are only a tiny minority in this galaxy. -- Spock, "The Apple," stardate 3715.6.
flinton@eagle.wesleyan.edu (11/29/89)
In article <581@limbic.UUCP>, gil@limbic.UUCP (Gil Kloepfer Jr.) writes: > > A problem I *have* noticed is calling at Trailblazer speed to a system > from my VT100 *through* the UNIX-pc results in many lost characters > on my receiving end. I'm not sure whether this is due to the 3B1 not > being able to handle 2 serial ports at high-speed, or the VT100 being > too slow and causing too many characters to be queued-up at the device > driver level. In any event, forcing the Telebit speed to 9600 baud > doesn't fix the problem. > I have a comment and a question. The comment: here at Wesleyan U., which uses lots of VT220's and VT320's, the recommendation is always to set up the Communications Setup screen with the Limited (as opposed to Unlimited) Transmit option. Perhaps changing your choice there (whichever you've chosen) _may_ help you stop losing characters. The question: may I assume that "calling at Trailblazer speed" directly from the UNIX-pc is essentially error-free for you? (This I ask because I'm just now contemplating taking up Telebit on their 1/2-price TB+ offer, for use with my UNIX-pc, and I don't want to have to run it at 2400 on account of lost characters at higher speeds.) Thanks for listening. -- Fred (FLinton@eagle.Wesleyan.EDU) Linton
jcm@mtunb.ATT.COM (John McMillan) (11/29/89)
In article <4197@eagle.wesleyan.edu> flinton@eagle.wesleyan.edu writes: >In article <581@limbic.UUCP>, gil@limbic.UUCP (Gil Kloepfer Jr.) writes: >> >> A problem I *have* noticed is calling at Trailblazer speed to a system >> from my VT100 *through* the UNIX-pc results in many lost characters >> on my receiving end. I'm not sure whether this is due to the 3B1 not >> being able to handle 2 serial ports at high-speed, or the VT100 being >> too slow and causing too many characters to be queued-up at the device >> driver level. In any event, forcing the Telebit speed to 9600 baud >> doesn't fix the problem. Answer: The 3B1 suffers overrun of the RS232 chip input buffers (3) while driving an RS232 output device. I do not LIKE the above fact, but I've found no solution to it. There are just too few CPU cycles to handle all the interrupt-driven processing. Attempts to solve this have failed. If you were displaying the data on the console, the problem would not occur. john mcmillan -- att!mtunb!jcm -- saying "Good Byte for Now..."
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (11/30/89)
In message: <581@limbic.UUCP> from gil@limbic.UUCP, Gil Kloepfer Jr. writes: >A problem I *have* noticed is calling at Trailblazer speed to a system >from my VT100 *through* the UNIX-pc results in many lost characters >on my receiving end. I'm not sure whether this is due to the 3B1 not >being able to handle 2 serial ports at high-speed, or the VT100 being >too slow and causing too many characters to be queued-up at the device >driver level. In any event, forcing the Telebit speed to 9600 baud >doesn't fix the problem. | Gil Kloepfer, Jr. I have a similar problem when communicating through an intermediate host. While attempting to isolate the problem, I did the following: first, from machine hybl (a 3B1 with the old uucp), I "cu -l/dev/ph1 328xxxx" to machine unix65 (a unix-pc 7300 with HDB); second, from unix65, I "cu mbph | tee cu.mbph" over a direct connection at 9600 baud using the tty000 port (mbph is a 3B2 with HDB); third, I did a few "ls -CF" operations to demonstrate dropped characters. The characters that were obviously missing from the output displayed on the monitor of machine hybl were also missing from file cu.mbph. This suggests that the intermediate host is not able to properly control the flow of characters from mbph. Why? If I login directly to machine mbph from either machine unix65 or hybl, I can "cd /" then "ls -sailFR" and watch the output scroll faultlessly by on the monitor. A portion from file cu.mbph follows: (I have added some annotation to the file.) > $ ls -CF > Configure* README filexp* patch.c util.h > EXTERN.h all inp.c patch.man version.c > INTERh common.h inp.h patchlevel.h version.h ^^ Two characters lost from here > MANIFEST config.H message pch.c > Makefile config.h myread pch.h > Makefile.SH config.sh patch* util.c > $ ls -CF > Configure* README filexp* patch.c util.h > EXTERN.h all inp.c patch.man version.c > INTERh common.h inp.h patchlevel.h version.h ^^ It is reproducible > MANIFEST config.H message pch.c > Makefile config.h myread pch.h > Makefile.SH config.sh patch* util.c > $ ls -CF I* > INTERN.h ^^ These are the lost characters. Thanks, ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Office Phone: (301) 328-7940 Baltimore, MD 21201 Home Phone: (301) 243-1710 ---------------------------------------------------------------------- Responders--DO NOT USE: hybl@cs.umd.edu or ah@cs.umd.edu
elliston@msdrl.UUCP (Keith Elliston) (11/30/89)
Where can i get ahold of pcomm, and is it commercial or PD? Thanks Keith uunet!msdrl!elliston
gil@limbic.UUCP (Gil Kloepfer Jr.) (11/30/89)
In article <4197@eagle.wesleyan.edu> flinton@eagle.wesleyan.edu writes: >The comment: here at Wesleyan U., which uses lots of VT220's and VT320's, >the recommendation is always to set up the Communications Setup screen >with the Limited (as opposed to Unlimited) Transmit option. Perhaps >changing your choice there (whichever you've chosen) _may_ help you stop >losing characters. In the unix-pc.general newsgroup, someone mentioned that in the way the machine was designed that it was incapable of running both serial ports in this manner at the same time. The solution is one I mentioned at Usenix in June which was to make an intelligent ports card for the UNIX-pc. Good luck! :-) >The question: may I assume that "calling at Trailblazer speed" directly >from the UNIX-pc is essentially error-free for you? >[...]and I don't want to have to run it at 2400 on account of lost > characters at higher speeds.) >Thanks for listening. -- Fred (FLinton@eagle.Wesleyan.EDU) Linton Communications between a serial port and the console are relatively (if not completely) flawless. If you set-up your Trailblazer according to Lenny Tropiano's tb-setup scripts and use hardware flow control, you can (to any reasonable expectation) assume that the Trailblazer is as good as being there. I, myself, have never gotten ANY line noise running using PEP, but I definitely have at 2400 baud. If you need the tb-setup script, check-out the posting I made to the unix-pc distribution about the ICUS archives, or e-mail me for more information. ----- | Gil Kloepfer, Jr. | ICUS Software Systems/Bowne Management Systems (depending on where I am) | ...ames!limbic!gil
wtm@neoucom.UUCP (Bill Mayhew) (12/02/89)
I don't have any problems with my Trailblzer on my 3b1. I've been using a TB since 11/1987. I started with one of the old version 3.1 TBs and then switched to the white-cased TB+. The problem of over-runs happens when you use in-band signaling with xon/xoff. There is a ~30K byte buffer in the TB, and it can take a couple of seconds for the host on the other end to see your xoff. The Unix PC can use the RTS/CTS leads for signaling flow control, and the TB modem can be used to send the RTS/CTS lead status outside of the serial data stream when it is talking in PEP fast mode. This works great when you have two Unix PCs talking together, but you have to make sure that both Unix PCs and Trailblazers are set up correctly, obviously :-). The Unix PC won't do RTS/CTS signaling until you turn it on with /etc/hfc. When you have hfc on, you don't get xon/xoff recognition. The problem of over-runs really isn't the fault of the Unix PC, but rather the delays cuased as in-band signally ripples through the buffers at each end. The Unix PC seems to be able to keep up with a 9600 baud input as long as you aren't trying to view the result on /dev/w* on the console. At 19.2K port speed, you can get actual throughputs of around 11,400 buad before the system starts to get behind. When I talk to the Vax at work, I have to settle for xon/xoff, and I occasionally get over-runs when catting some immense file. But no problem for stuff like more and kermit that are essentially self-regulating or limit blobs of transmission to less than 30K at a time. Feeding from the Vax at 9600 to my Unix PC at 19.2K and letting the Trailblazer packetization handle the float, I can do a ~%take in cu and not lose anything. Obviously a ~%put doesn't work to the Vax, but does work between Unix PCs. Uucp is no problem since the Trailblazer does the protocol spoofing. You would have to be very persuasive to get me to give up my Trailblazer; I think I'd listen if you had a loaded Colt .45 or something like that, I suppose. 'nuff said. Bill wtm@neoucom.edu
jcm@mtunb.ATT.COM (John McMillan) (12/05/89)
In article <1846@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: > >I don't have any problems with my Trailblzer on my 3b1. I've been >using a TB since 11/1987. I started with one of the old version >3.1 TBs and then switched to the white-cased TB+. I'm totally 8-) for you! >The problem of over-runs happens when you use in-band signaling >with xon/xoff. There are three principle overruns: - RS-232 Chip overruns - 'seriobuf' overruns - C-list overruns The former occur when the duration of "high-level" interrupts exceeds ~2 * receive-time for a single character. This *DOES* occur, and it's easy to produce using a terminal off any port to CU to another system at 9600 baud. Just CAT a file and watch the bytes get lost. Then do a "~%take" into a file: all characters will be received, indicating it was the load associated with the DISPLAY of the characters to the terminal that induced the chip-overrun. 'seriobuf' overflow occurs when sustained low-level interrupts prevent the unloading of this temporary buffer into the C-list mechanism. C-list overruns occur when the CPU-usage is so high that user programs cannot read the data as fast as it is arriving and the C-list use-limits are being circumvented. Flow-Control (H/W or S/W) can deal with this, and only with this. The preceding comments are probably flawed -- I've other things to deal with -- but they're pretty accurate!-) john mcmillan -- att!mtunb!jcm -- tic-toc-tic-toc...
jbm@uncle.UUCP (John B. Milton) (12/05/89)
In article <583@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes: >In article <4197@eagle.wesleyan.edu> flinton@eagle.wesleyan.edu writes: ... >If you need the tb-setup script, check-out the posting I made to the unix-pc >distribution about the ICUS archives, or e-mail me for more information. One thing I recently discovered (I feal stupid) is that you have to go to some effort to support MNP. If you want to dial out to an MNP modem, and force an MNP connect, set S95=1. If you want ALL dial-ins to be MNP only, also set S95=1. If you want incoming connects to be MNP if they can do it, set S95=2. Use ONLY S95=0 to connect out to a UNIXpc 1200 baud and other stupid modems. I now have two sets of dialers in the Dialers file. I then configure the proper dialer on a per-system basis in the Systems file. You will notice the modem stay in audio monitor mode a few seconds longer with S95!=0, until the MNP handshake completes. MNP is great for quiet terminal users. I don't know what effect using MNP has on UUCP throughput. I goofed with other UUCP protocols with HDB. The version of HDB we have only seems to support "e" and "g" protocols. The TB only spoofs "g" protocol, and "e" drives it crazy. This part is where the protocol arbitration happens: --- msg-ROK Rmtname oink, Role MASTER, Ifn - 6, Loginuser - jbm rmesg - 'P' got Pge ^^ wmesg 'U'g ^ Proto started g ^ --- The set of protocols you allow for connections to a certain machine is specified in the Systems file, as a comma subfield of the device name: system Any pep,eg Any ... ^^^ The protoset may also be put after the same name in the Devices file. Anybody know what the "e" protocol is supposed to be used with? STARLAN? John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:252-8544, w:469-1990; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!
rkh@mtune.ATT.COM (Robert Halloran) (12/07/89)
In article <620@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: >Anybody know what the "e" protocol is supposed to be used with? STARLAN? The 'e' protocol is for use over Error-free transports such as a TCP connection, Starlan, etc. It basically sends the file length and then just does write()s at the port, and assumes the medium will deliver it intact. I suppose if you turned off spoofing that the Telebits could handle it, but you'd have to watch out for characters dropped between the modem and host. >John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu >(614) h:252-8544, w:469-1990; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform! Bob Halloran Distributed Programming Tools Group ========================================================================= UUCP: ...!att!mtune!rkh DDD: (201)957-6034 Internet: rkh@mtune.ATT.COM USPS: AT&T Bell Labs, 200 Laurel Ave Rm 3G-314 Middletown NJ 07748 =========================================================================
thad@cup.portal.com (Thad P Floryan) (12/14/89)
jbm@uncle.UUCP (John B. Milton) in <620@uncle.UUCP> writes:
Anybody know what the "e" protocol is supposed to be used with? STARLAN?
Yep, the "e" protocol works fine with StarLAN. Before Lenny clued me into
this (we both bought the StarLAN cards during that special deal during October)
,
my /usr/spool/uucp/.Admin/xferstats file was showing a MAX of only 2000 bytes
per second (this is with the "g" protocol); switching to "e" protocol raised
the speed to an average of 30,000 bytes/second (15 times faster) over the
StarLAN connection. I have four StarLAN NAUs, one in each of four UNIXPCs,
on the same LAN with two RS-232c-NAUs (aka NIU, for terminals, modems, etc.)
and it all works fine.
Some things weren't immediately obvious at first (requiring a LOT of research
to figure out solutions to some problems), but what I finally ended up with
was the following (skeleton form for clarity). The original problem I had was
"cu" not working over StarLAN; the solution was the split of the Systems files
per the entries in Sysfiles. I was almost about to patch the "cu" program to
NOT request service code 101 and instead use service code 1 (remote login)
when I found some docs in the SysVR3.2 manuals that started me thinking. Hope
the following gives ideas and helps someone else. The "split" also straigtened
out the "uuname" displays, so now one can do:
$ uuname -l # for local system name
thadlabs
$ uuname # for uucico connections
thadlabs
tlabs3
tlabs4
tlabs5
$ uuname -c # for cu connections
thadlabs
tlabs3
tlabs4
tlabs5
Devices extraction:
#
STARLAN starlan - Any STARLAN
Direct tty002 - Any direct
Direct tty003 - Any direct
Direct tty004 - Any direct
Direct tty000 - Any direct
ACU ph0 ph0 1200 PC7300 \T
STARLAN_NAU,eg starlan - Any STARLAN \D.serve pc_uucp
STARLAN_UU,eg starlan - Any STARLAN \D.serve SLAN_uucico
Sysfiles extraction:
service=cu systems=Systems.cu:Systems \
devices=Devices \
dialers=Dialers
service=uucico systems=Systems.uucico:Systems \
devices=Devices.hop:Devices \
dialers=Dialers:Dialers.SW:Dialers.ACU
Systems file has the "normal", non-StarLAN entries.
Systems.cu extraction:
# StarLAN entries for cu activity
#
thadlabs Any STARLAN - thadlabs "" \r\d\r in:--in: nuucp
#
tlabs3 Any STARLAN - tlabs3 "" \r\d\r in:--in: nuucp
tlabs4 Any STARLAN - tlabs4 "" \r\d\r in:--in: nuucp
tlabs5 Any STARLAN - tlabs5 "" \r\d\r in:--in: nuucp
Systems.uucico extraction:
# StarLAN entries for uucico activity
#
thadlabs Any STARLAN_NAU,eg - thadlabs "" \r\d\r in:--in: nuucp
#
tlabs3 Any STARLAN_NAU,eg - tlabs3 "" \r\d\r in:--in: nuucp
tlabs4 Any STARLAN_NAU,eg - tlabs4 "" \r\d\r in:--in: nuucp
tlabs5 Any STARLAN_NAU,eg - tlabs5 "" \r\d\r in:--in: nuucp
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]