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 ]
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
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
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.
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
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...
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 ]