peter@csd4.csd.uwm.edu (Peter J Diaz de Leon) (03/26/91)
Does anyone know if it is possible to run the 3b1 serial port
at 19.2K bps.
I need to transfer about 45MB of data between a ATT 3b1 and a ATT 6386EWGS
system. If anybody has any other ideas I on how to do it my ears are open.
By the way the 3b1 as one of those 20MB tape drives which uses DC600 tapes.
However, the 386 could not read them.
Thanks
-Peter
==============================================================================
University of Wisconsin - Milwaukee USMAIL: Peter J. Diaz de Leon
Computer Science Department 7411 W. Warnimont Ave
Milwaukee, WI. 53220
ARPA: peter@csd4.csd.uwm.edu Daytime: (414)229-3886
UUCP: {wuarchive, rutgers, lll-winken} !uwm!miller.cs!peter
==============================================================================thad@public.BTR.COM (Thaddeus P. Floryan) (03/26/91)
In article <10499@uwm.edu> peter@csd4.csd.uwm.edu (Peter J Diaz de Leon) writes: > >Does anyone know if it is possible to run the 3b1 serial port >at 19.2K bps. > >I need to transfer about 45MB of data between a ATT 3b1 and a ATT 6386EWGS >system. If anybody has any other ideas I on how to do it my ears are open. >[...] Man, I've been swamped with work the past 4 weeks and am about a month behind on usenet postings, but this question from Peter immediately captured my attention since I've been fighting the same problem myself. As a quick answer, I'd give a qualified "yes". BUT, it is mandatory that one use hardware flow control AND there's no "standard" software for the 3B1 that will correctly support hardware flow control and 19,200 baud. And before you say bullsh*t, please note that I've spent HUNDREDS of hours testing this using Data Line Monitors and special software on other computers connected to my 3B1 systems. Even WITH hardware flow control, I've been forced to run my Telebit 2500 locked at an interface speed of 9600 baud to assure reliable data exchange. I have tested modems, StarLAN, and direct hardlined connections to the 3B1 all in the hopes of getting reliable 19,200 data transfers. The {rz,rb,rz} and {sz,sb,sx} programs suck dead bunnies through a straw at 19,200; the same is true for EVERY other method I've tested, including HDB's uucico, with but one exception: "cat" and "cp". The ONLY method I've achieved reliable 19200 data transfers with the 3B1 in/out the serial ports and/or StarLAN NIU is using hardware flow control and the commands "cat file" and "cp /dev/tty file", and even then only after explicitly disabling ALL X-ON/-OFF flow control (e.g. stty -ixon) and disabling all input echoing (e.g. stty -echo -echoe -echok) [and, of course, enabling the hardware flow control on the respective port by: /etc/hfc_ctl +/dev/tty???). To say the least, I'm NOT pleased. I'm starting to come to the conclusion the 3B1 can support 19200, BUT that much of the extant software does "something" to foil successful operation. I'm still running tests to completely characterize the problem and will post when I have done so. Sigh :-( Unless Peter's files are ASCII and can be transferred along the lines of what I've stated above, his best courses of action are either to Ethernet the files or operate at a lower baud (start the stuff on Friday night and let it run all weekend). When 19200 works correctly, one can count on 6MB per hour, half that for 9600. Thus, 45MB would require (roughly) 8 hours at 19200 and 16 hours at 9600. The ONE thing that's really p*ssing me off on the 3B1 is that I can transfer uucp OUT just fine at 19200 with hardware flow control (getting 1800+ in the uucp xferstats), but I'm getting the distinct impression that hardware flow control doesn't work as well on input as it should ... it's "almost" as if HFC was mono-directional EXCEPT for the fact that use of both a breakout box and a Data Line Monitor has verified that HFC is being used (but probably not as well as it could be; sigh, without source ...... ) For the record, at 19200 baud and HDB UUCP, my send rate would be 1800+ and my receive rate would be 75 cps. Yes, 75 cps, due to retransmission delays. At 9600 baud, I both send/receive around 870 cps. Both cases with HFC and the same Telebit T2500 modem whose only change is the serial data rate. Several more tests yet to be run are putting the modem on StarLAN (via an RS-232 NAU) and on an Ethernet terminal server. SOMETHING has got to work, cause I sure as hell don't want to have to buy a 50 MHz 68040 computer solely to be used as a uucp transmit/receive point. Damn, even one of my present products using an MC6803 (yeah, an 8-bit computer) with MC68681 DUARTs can do both 19200 and 38400 on three (3) serial ports simultaneously continuously with 100% error-free data transfer and NO protocols. Sheesh. More later ... enough rambling for now, gotta keep my blood pressure down. Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
dnichols@ceilidh.beartrack.com (DoN Nichols) (03/27/91)
In article <2214@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: >Man, I've been swamped with work the past 4 weeks and am about a month behind >on usenet postings, but this question from Peter immediately captured my >attention since I've been fighting the same problem myself. > >As a quick answer, I'd give a qualified "yes". BUT, it is mandatory that one >use hardware flow control AND there's no "standard" software for the 3B1 that >will correctly support hardware flow control and 19,200 baud. > [ ... lots of relevant stuff deleted ... ] >The ONE thing that's really p*ssing me off on the 3B1 is that I can transfer >uucp OUT just fine at 19200 with hardware flow control (getting 1800+ in the >uucp xferstats), but I'm getting the distinct impression that hardware flow >control doesn't work as well on input as it should ... it's "almost" as if HFC >was mono-directional EXCEPT for the fact that use of both a breakout box and a >Data Line Monitor has verified that HFC is being used (but probably not as well >as it could be; sigh, without source ...... ) > >For the record, at 19200 baud and HDB UUCP, my send rate would be 1800+ and >my receive rate would be 75 cps. Yes, 75 cps, due to retransmission delays. >At 9600 baud, I both send/receive around 870 cps. Both cases with HFC and >the same Telebit T2500 modem whose only change is the serial data rate. I have my Trailblazer+ locked to 19200, and am getting about 700-800 both directions when communicating with a RT with AIX which is locked at 9600, but ONLY if I kill off my ethernet before the transmission starts. If ethernet is running, I get lots of 75cps & less, and frequent failures during uucp transfer of news batches to this system. Short files show up as 1800+, apparently those which fit in the buffer on the TB+. I may try locking the speed of mine at 9600, and seeing if that means that I don't have to kill of ethernet while uucico is running. [ ... more deleted ... ] I wish I could afford one of those boxes which turn an ethernet port into serial for the TB+ and allow TCP/IP through dial-up lines. Well, acutally two - one for my feed :-) Good Luck DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
dt@yenta.alb.nm.us (David B. Thomas) (03/27/91)
I haven't been nearly as thorough as Thad, so I can only speak for myself, but I have had my builtin serial port connected to a telebit locked at 19.2k for months, and the transfer rate is (lemme look!) typically around 900 cps both ways. I get a feed and I give a feed, so that's a lot of data moving both ways. Now maybe it'll quit working tomorrow, but anyway it's working right now. That's with HDB uucico by the way. I haven't tried to move significant amounts of data through the port in any other way. little david -- Bottom of stack = 0x40000 Stack pointer = 0x3fffe Don't push it!
kls@ditka.Chicago.COM (Karl Swartz) (03/27/91)
In article <2214@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: >... there's no "standard" software for the 3B1 that >will correctly support hardware flow control and 19,200 baud. >And before you say bullsh*t, please note that I've spent HUNDREDS of hours >testing this ... Duly noted. And while your pedantic interpretation may well be correct, in practice your answer is bullshit. My 3b1 has spent hundreds of hours just this month demonstrating otherwise. >Even WITH hardware flow control, I've been forced to run my Telebit >2500 locked at an interface speed of 9600 baud to assure reliable >data exchange. Funny, my TrailBlazer Plus, still with creaky old 4.00 ROMs, has been running just fine with hardware flow control and an interface locked at 19,200 for several *years* now. Currently traffic levels are near three-quarters of a *gigabyte* per month with nary a trace of data loss. (There may be an occasional HFC hiccup but uucp's g protocol obviously deals with it and even at that the data rates show minimal impact from retries. HDB uucp, BTW, not the stock garbage.) >For the record, at 19200 baud and HDB UUCP, my send rate would be 1800+ and >my receive rate would be 75 cps. Yes, 75 cps, due to retransmission delays. >At 9600 baud, I both send/receive around 870 cps. Both cases with HFC and >the same Telebit T2500 modem whose only change is the serial data rate. For the record, I happen to have some numbers for Tuesday of last week, an entirely ordinary day for ditka with respect to uucp. That day a total of 24 megabytes was transferred in and out over the modem in just over 7 hours. Outbound traffic outweighed inbound by about 1.24 to 1 and these numbers include a non-trivial amount a 2400 baud traffic (perhaps even a trace of 1200) along with some PC Pursuit in addition to Telebit (PEP) links. Despite all that when one accounts for g-protocol packet overhead the *average* rate is over 1,000 bytes per second. Ok, the numbers came from xferstats and there's known slop there on small files. But the average file size was 36K so most of the slop should be down in the noise. Still not convinced? Try this: the report was for a 24 hour period. If I were getting only 75 cps on input, the input alone (never mind the 13.5 megabytes of output) would have required over 40 hours. >More later ... enough rambling for now If you can't dazzle them with brilliance, baffle them with bullshit, eh Thad? You undoubtedly have provided a lot of help to numerous UNIX PC owners, but when I read nonsense like this (unfortunately not unique to this occasion) I really have to wonder. -- Karl Swartz |INet kls@ditka.chicago.com 1-408/223-1308 |UUCP {uunet,decwrl}!daver!ditka!kls |Snail 1738 Deer Creek Ct., San Jose CA 95148 "It's psychosomatic. You need a lobotomy. I'll get a saw." (Calvin)
gandrews@netcom.COM (Greg Andrews) (03/28/91)
In article <35907@ditka.Chicago.COM> kls@ditka.Chicago.COM (Karl Swartz) writes: >In article <2214@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: >>... there's no "standard" software for the 3B1 that >>will correctly support hardware flow control and 19,200 baud. > >>And before you say bullsh*t, please note that I've spent HUNDREDS of hours >>testing this ... > >Duly noted. And while your pedantic interpretation may well be >correct, in practice your answer is bullshit. My 3b1 has spent >hundreds of hours just this month demonstrating otherwise. > > [bunch 'o' stuff deleted] > >If you can't dazzle them with brilliance, baffle them with bullshit, >eh Thad? You undoubtedly have provided a lot of help to numerous >UNIX PC owners, but when I read nonsense like this (unfortunately not >unique to this occasion) I really have to wonder. > Karl, you should be aware that results acquired solely with a TB modem in uucp spoofing mode would have absolutely no relevance to other types of data transfer. The TB+ modems do not rely on just the hardware flow control when they are spoofing a uucp transfer. They accomplish flow control by witholding packet acknowlegements. In other words, the spoofing masks any problems caused by a lack of proper hardware flow control. If your computer is receiving, it can do exactly the same thing (withold acks) to prevent the modem from overflowing the computer's input buffer. Matter of fact, one well known 386 implementation of SysV Unix turns hardware flow control OFF in the computer when uucico starts running - and no trouble results. My reading of Thad's message was that he's been seeing trouble on other types of data transfer, not just the uucp transfers you mention. Therefore your results don't refute his as thoroughly as they would seem to. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
thad@public.BTR.COM (Thaddeus P. Floryan) (03/28/91)
In article <35907@ditka.Chicago.COM> kls@ditka.Chicago.COM (Karl Swartz) writes: > ... a variety of things claiming 19,200 works fine on his 3B1 with no loss > ... of characters and/or data. That's good for you, but I'm aware of at least 3 other people here in the Bay Area with exactly the same problems, all of whom have configured their 3B1 systems and T2500 modems independently from the others, and all are experiencing the same problems. In my case, the kernel is 3.51m with everything except the ksh "upgrade", sports 3.5MB RAM, and the modem is a T2500 with GF7.00 ROMs. Problem occurs with the onboard tty000 and with any EIA/RAM Combo port tty001-tty004. The problem occurs WITH and WITHOUT the modem (i.e. direct into another 3B1 with the same configuration), so I'm not blaming Telebit. The problem also occurs direct-connection to other systems, and manifests itself ONLY with input to the 3B1. 19,200 lossage also occurs using Ymodem-BATCH (sb and rb) and Zmodem (sz and rz), so it's not specific to HDB uucp. With one series of tests INTO an Amiga (with 68020/68881), its (the Amiga's) hardware flow control very clearly (monitored using alternately a bi-color LED breakout box and a Benedict Computer Systems Data Line Monitor) was doing the "right" thing. Turning around and feeding back into the 3B1, it was VERY clear the 3B1 was NOT asserting its hardware flow control with the same consistency as the Amiga was, hence the data lossage; the problem into the 3B1 was also observed during uucp transfers both hardlined and over a modem connection (from other 3B1 systems, and from HP-UX/Sun/other systems). Among the test parameters was the altering of NCLIST and NTTYHOG (via ktune) to no apparant benefit; i.e. the 3B1 consistently would lose characters using hardware flow control at 19,200. And using X-ON/-OFF flow control is NOT an option since binary data is being transferred. (And, yes, I did reboot after each ktune change :-) Since I doubt your 3B1's hardware is "different" from mine, I'm at a loss to explain why Karl claims 19,200 works fine and I assert it doesn't (on the 3B1). During the uucp tests, 19200 baud output from the 3B1 was clearly evidenced by continuous transmission. What occurs during INPUT is the first 6K to 7K of chars come in just fine, then *POOF*, everything falls apart; during uucp input transfers, there'd be several seconds delay with no data transfer, followed by a "packet" coincident with an "Alarm n", more delay, another incoming "packet" coincident with "Alarm n+1", ad infinitum, causing the 75 cps effective input rate. With Ymodem or Zmodem, the incoming chars would be OK for the first 6K up to sometimes the first 24K or so, then, *POOF*, CRC errors or "packet too long", followed by a wait, followed by a retransmission, etc. > If you can't dazzle them with brilliance, baffle them with bullshit, > eh Thad? You undoubtedly have provided a lot of help to numerous > UNIX PC owners, but when I read nonsense like this (unfortunately not > unique to this occasion) I really have to wonder. If the problem was ONLY with modem transfers, then I'd post the T2500 reg settings and ask for help. But since it's also with hardlines and with ALL protocol transfers (uucp, zmodem, ymodem, etc.), the nature of the problem must be a kernel and/or hardware limitation. And it occurs even when pulling ALL expansion cards (except the EIA/RAM Combo card) out of the system, so it's not a function of the presence/absence of Ethernet, StarLAN or VoicePower. OK, so what's YOUR explanation for the problem on at least 4 other peoples' systems? I don't mind having my assertions being proven wrong, but all evidence and test data I have (and anecdotal evidence from others) supports my contention the 3B1 with hardware flow control cannot support 19,200 baud correctly. Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
Mariusz@fbits.ttank.com (Mariusz Stanczak) (03/28/91)
In article <35907@ditka.Chicago.COM>, kls@ditka.Chicago.COM (Karl Swartz) writes: > In article <2214@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: > >And before you say bullsh*t, please note that I've spent HUNDREDS of hours > >testing this ... > > If you can't dazzle them with brilliance, baffle them with bullshit, > eh Thad? You undoubtedly have provided a lot of help to numerous > UNIX PC owners, but when I read nonsense like this (unfortunately not > unique to this occasion) I really have to wonder. Ho Karl, there's no need for that... our machines are not identical, and though your experience contradicts Thads, you'd have enough courtesy to accept his, ESPECIALLY after his assu- rances that he extensively had researched his problem in an at- tempt to fix it (and I understeand communications is his field). How'd you feel if you'd post your opinion first, and Thad came down on your statements with his so authoritativly. Thanks for posting your positive results (I'm in a process of choosing a high-speed modem), but it'd plenty enough if your presentation was limited to facts (as you know them ;-)). > Karl Swartz |INet kls@ditka.chicago.com -Mariusz -- INET: Mariusz@fbits.ttank.com CIS : 71601.2430@compuserve.com UUCP: ..!uunet!zardoz!ttank!fbits!Mariusz
almquist@brahms.udel.edu (Squish) (03/29/91)
Everyone keeps talking about 19.2k - I haven't seen anything about 38.4k. Some of the manuals I've got hint at the perhaps possibility of 38.4k. Am I reading the manual upside down or does someone there know more about this? - Mike
vince@tc.fluke.COM (Craig Johnson) (03/29/91)
Thad, your description of serial port problems makes me suspicious that you are suffering from spurious interrupts from an anonymous source. Its been a long time since I've looked into it, but I believe I once traced a problem like this to a suspicious connection on the parallel line printer port. Make sure anything connected there is powered on and that the connection is solid. If the printer drives the handshake lines with open-collector drivers, you may need to see if there is a problem with missing or bad pullup resistors. I hope this isn't a wild hair. It's been a long time since I last looked into it. Possibly related? Has anyone ever figured out the reason UA occasionally switches windows on you without you asking for it? Spurious keyboard noise? Is it dependent on SW version (I'm only sure I've seen it on a 3.0 machine)? --- Craig V. Johnson ...!fluke!vince John Fluke Mfg. Co. or Everett, WA vince@tc.fluke.com
emm@iczer-1.UUCP (Edward M. Markowski) (03/29/91)
In article <20068@brahms.udel.edu> almquist@brahms.udel.edu (Squish) writes: >Everyone keeps talking about 19.2k - I haven't seen anything about 38.4k. >Some of the manuals I've got hint at the perhaps possibility of 38.4k. Am >I reading the manual upside down or does someone there know more about this? No you are not reading the manuals upside down, they do talk about 38.4K. The system header files even comment about it, but it seems that 38.4K is not supported in the kernel. It looks that it is there like the 2400 baud stuff for the modem, expansion(sp?) room for future models. -- ------------------------------------------------------------------------------- Edward M. Markowski -- iczer-1 Administrator ...the garage is flooded from the sprinkler. VOICE : (201) 478-6052 It also left a man's decapitated body, lying UUCP : ..!uunet!iczer-1!emm on the floor next to his own severed head. -or- : ..!tronsbox!iczer-1!emm A head which at this time has no name.
todd@appmag.com (Todd Day) (03/29/91)
vince@tc.fluke.COM (Craig Johnson) writes:
%Has anyone ever figured out the reason UA occasionally
%switches windows on you without you asking for it? Spurious keyboard
%noise? Is it dependent on SW version (I'm only sure I've seen it on a
%3.0 machine)?
I have 3.50. I used to have the problem you described and then it all
of a sudden disappeared. The only thing I can track it down to was
the replacement of the phone manager. I now use the one from the
3.51m upgrade.
I also moved my machine several times, so take the above with a
grain of salt...
--
Todd Day | todd@appmag.combruce@balilly (Bruce Lilly) (03/29/91)
In article <1991Mar28.215833.1372@tc.fluke.COM> vince@tc.fluke.COM (Craig Johnson) writes: >Thad, your description of serial port problems makes me suspicious that >you are suffering from spurious interrupts from an anonymous source. >Its been a long time since I've looked into it, but I believe I once >traced a problem like this to a suspicious connection on the parallel >line printer port. Make sure anything connected there is powered on >and that the connection is solid. [ ... ] That (parallel port) isn't the problem. I've also seen character loss at 19.2k, using a non-telebit modem, w/ HFC, running V.32/V.42 (which does software flow control on the link), independent of UUCP protocols (since I wasn't using uucp). >Possibly related? Has anyone ever figured out the reason UA occasionally >switches windows on you without you asking for it? Spurious keyboard >noise? Is it dependent on SW version (I'm only sure I've seen it on a >3.0 machine)? I've never seen this in 3.51 or 3.51m. -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
bruce@balilly (Bruce Lilly) (03/29/91)
In article <1991Mar27.033750.29895@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (DoN Nichols) writes: [...] > I have my Trailblazer+ locked to 19200, and am getting about 700-800 >both directions when communicating with a RT with AIX which is locked at >9600, but ONLY if I kill off my ethernet before the transmission starts. If >ethernet is running, I get lots of 75cps & less, and frequent failures >during uucp transfer of news batches to this system. Short files show up as >1800+, apparently those which fit in the buffer on the TB+. Could you please clarify "kill off my ethernet". Do you mean "ifconfig en0 down", or a reboot without the ether driver, or do you kill -9 the daemons, or do you blast the board with a shotgun? And in what order do you have the drivers loaded? -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
kak@hico2.UUCP (Kris A. Kugel) (03/30/91)
In articles <2225@public.BTR.COM> and <35907@ditka.Chicago.COM>,
thad@public.BTR.COM (Thaddeus P. Floryan) and kls@ditka.Chicago.COM
(Karl Swartz) disagree over whether the 3b1, HFC, and 19200baud
get along together. Thad says he has a vanilla 3.51m.
I remember recently installing the kernel serial patch, which
is supposed to make serial i/o work "better" by checking for
serial interrupts more often.
I've included some relevant quotes from the original article below.
I believe that I got this from osu-cis, rather than the original posting.
+ From: steveb@shade.UUCP (Steve Barber)
+ Newsgroups: unix-pc.general,comp.sys.att
+ Subject: Kernel Patch to Improve Serial Line Response Time (update)
+ Date: 15 Apr 90 06:15:25 GMT
+ Reply-To: steveb@shade.ann-arbor.mi.us (Steve Barber)
+ Organization: Ripley Computing/Consulting Services (Ripley, MI)
+
+ Back in December, Gene Olson (gene@digibd) posted information explaining
+ how to patch your 3.51a kernel to allow it to move characters from the
+ raw interrupt queue to the raw input queue every 1/60th of a second,
+ rather than every 4/60ths of a second as the code in the kernel is written.
+ The rest of this article is an update to Gene's original article
+ explaining how to make the change to the 3.51m kernel. (Yes, due to
+ the MeterMaid code, the addresses are different.)
+
+ I should add a few comments here regarding the use of this code, now
+ that I've been running this way for a while:
+
+
+ 4) My friend whose Sun I'm now connected to used to have a 3B1. When we
+ applied this patch to both of our machines, our average UUCP transfer
+ rates jumped from around 750 bytes/sec to almost 1400 bytes/sec. When
+ only one machine of the two had the patch, average transfer rates were
+ around 1000 bytes/sec, but presumably the machine with the patch could
+ read data at 1400 bytes/sec, and the other machine was still reading
+ at 750 bytes/sec, thus causing the average to be 1000 bytes/sec.
+
+ 5) Just as another data point in the hardware flow control issue (please
+ don't start another argument out of this!): I've been using hardware
+ flow control on 19200 ports on my 3b1 since OS 3.51. For the most part,
+ it works. uucp works great that way, and in fact due to the packet
+ nature of the g protocol, I seem to recall that it doesn't end up needing
+ to use the flow control much anyway. The only problems I've noticed
+ have been when I'm logged in with cu over a 19200 serial line with
+ flow control. Occasionally there are lost characters and sometimes I
+ suspect (during a long ls, for instance) that sometimes I lose more like
+ a few lines than a few characters, but I've never worried about it too
+ much. pcomm 1.1 handled the speed with no problem, but 1.2 seems to lose
+ some characters now and then too. (That and the feeble vt100 emulation
+ slows it down a lot. I may just comment that out.)
(remainder of article deleted)
This sure sounds like it could explain the difference
between Thad and Karl's machines.
Could you two let the rest of us know if you are using these patches?
At least that will make it clear if we are talking about a difference
in machines or kernels.
Kris A. Kugel
( 908 ) 842-2707
uunet!tsdiag.ccur.com!hico2!kak (maybe)
{daver,ditka,zorch}!hico2!kak
internet: kak@hico2.westmark.comjcs@cbnewsb.cb.att.com (John "C". Sucilla) (03/30/91)
In article <2225@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: >I don't mind having my assertions being proven wrong, but all evidence and >test data I have (and anecdotal evidence from others) supports my contention >the 3B1 with hardware flow control cannot support 19,200 baud correctly. For whatever its worth, my 3B1 will also consistantly deliver >900cps performance in both directions also. I'm using HFC and a Telebit Trailblazer+ HDB and the 3.5.1.4 kernel. Maybe your kernel is the problem? Have you tried an earlier version? -- AT&T Bell Laboratories, Naperville Il. JC Sucilla IX Room 1F-210, (708) 979-0599 jcs@ixstar.att.com
dnichols@ceilidh.beartrack.com (DoN Nichols) (04/01/91)
In article <1991Mar29.110050.20635@blilly.UUCP> bruce@balilly (Bruce Lilly) writes: >In article <1991Mar27.033750.29895@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (DoN Nichols) writes: >[...] >> I have my Trailblazer+ locked to 19200, and am getting about 700-800 >>both directions when communicating with a RT with AIX which is locked at >>9600, but ONLY if I kill off my ethernet before the transmission starts. If [ ... ] > >Could you please clarify "kill off my ethernet". Do you mean "ifconfig en0 >down", or a reboot without the ether driver, or do you kill -9 the >daemons, or do you blast the board with a shotgun? Well, when it kept panicing on of my 3b1's I was close to considering the shotgun :-) When I moved it back to the 7300, (with the disks and other boards, so the only difference was the main-board/power supply and the floppy-drive, it stopped panicing the system every half-hour or so. (Depending on ethernet usage) Re-boot before each scheduled uucp call would be awkward, so I use a shell script which nukes the daemons, and unloads the driver. (Essentially a pared-down version of the one under the UA choices for shutdown (and startup). I may try the "ifconfig en0 down" to see if it makes enough difference, although I suspect that the daemons are contributing enough load to be a problem, as well. Let's face it, there just isn't much muscle for handling interrupts at the rate that 19.2k requires. (I'd love for an intelligent serial card with its own dma to be produced for the system (with appropriate drivers). >And in what order do you have the drivers loaded? As follows: DEVNAME ID BLK CHAR LINE SIZE ADDR FLAGS wind 0 -1 7 -1 0x9000 0x54000 ALLOC BOUND nipc 1 -1 -1 -1 0x7000 0x360000 ALLOC BOUND xt 2 -1 14 1 0x3000 0x5d000 ALLOC BOUND tp 3 -1 9 -1 0x3000 0x367000 ALLOC BOUND cmb 4 -1 -1 -1 0x3000 0x36c000 ALLOC BOUND ether 5 -1 10 -1 0x13000 0x3de000 ALLOC BOUND DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
cmv@cbnewsc.att.com (C M Votava) (04/02/91)
DoN Nichols writes: > Let's face it, there just isn't much muscle for >handling interrupts at the rate that 19.2k requires. (I'd love for an >intelligent serial card with its own dma to be produced for the system (with >appropriate drivers). Well, an interesting project would be to take the DOS-73 board, any of the many available public domain RS-232 software drivers available, toss the DOS 3.1 OS (et. al.), and write some "glue" code to come up with your own intelligent serial card for running RS-232 at various speeds. Actually, it's not as easy as it sounds (I've looked into it a bit), but I think that using the DOS-73 interface description from the maintenaince manual, and an assembly language RS-232 driver, it is possible to do. You'd also have to write a device driver to talk to it, the first crack at it could be farly "simple minded" reserving the complicated garbage (line disiplines, etc.) for later. Taking this project further, it would be nice for this thing to be able to interface with DOS boxes running programs like "Brooklyn Bridge". What this program does is allow you to connect 2 DOS boxes together via the RS232 connections, and changes the baud rate to somewhere around 115K to transfer information. One machine ends up being the "slave" and one is the "master". I haven't even looked into this much, but it sounds interesting on the surface. Anybody game? -Craig
jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) (04/02/91)
In article <1991Mar31.211207.5490@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (DoN Nichols) writes: >(I'd love for an >intelligent serial card with its own dma to be produced for the system (with >appropriate drivers). Don, someone already beat you to the suggestion. Nobody thought it was "glamorous" enough to pursue it. Has anyone looked back at the old BOF notes? There was a plan for an intelligent card, built around a standard UART. And now, with the availability of 386 drivers, (wasn't there even a SLIP driver just posted?), this would be an interesting project to chase. If someone would be interested in making the card, I'd lend a hand in doing the driver development. j -- Jeffrey L. Bromberger System Operator---City College of New York---Science Computing Facility jeffrey@sci.ccny.cuny.edu jeffrey@ccnysci.BITNET Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffrey
dnichols@ceilidh.beartrack.com (DoN Nichols) (04/02/91)
In article <1991Apr1.161805.29133@cbnewsc.att.com> cmv@cbnewsc.att.com (C M Votava) writes: >DoN Nichols writes: >> Let's face it, there just isn't much muscle for >>handling interrupts at the rate that 19.2k requires. (I'd love for an >>intelligent serial card with its own dma to be produced for the system (with >>appropriate drivers). > >Well, an interesting project would be to take the DOS-73 board, any of the many >available public domain RS-232 software drivers available, toss the DOS 3.1 OS >(et. al.), and write some "glue" code to come up with your own intelligent [ ... ] >information. One machine ends up being the "slave" and one is the "master". >I haven't even looked into this much, but it sounds interesting on the surface. Halleluliah! A use for the DOS-73 board which I have (without the software that goes with it). Only problem is that I've actively avoided the Intel instructions sets, for reasons that only became more obvious when the went from the 8080 to the 8086 :-). I've worked with 6800, 6809, and 68k instruction sets. (I wish I had a board comprable to the DOS-73, except with the 6809 on it.) Anybody remember how much ROM space is actually present on the board? (Not that we'd need more than about (1 or 2)k, at least for the simple-minded serial-I/O. The Brooklyn Bridge would be another thing, but that could be loaded into the board's ram from disk.) >Anybody game? Anybody have enough time :-) DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
ssb@quest.UUCP (Scott Bertilson) (04/04/91)
In article <1991Mar27.033750.29895@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (DoN Nichols) writes: >9600, but ONLY if I kill off my ethernet before the transmission starts. If >ethernet is running, I get lots of 75cps & less, and frequent failures Well, I find it very interesting that you say killing your Ethernet makes things work better, because I've had no problems running "async_main" to tty000 with V.32/MNP-5 at 19200 *UNTIL* I tried to do it with MGR running. Please note that I say "with MGR running"...I don't even have to run the terminal manager under MGR. Someone suggested that MGR was too CPU-intensive to run a terminal emulator, so my second test was to "Suspd" myself to another "wind.o" window and run the terminal emulator..which normally shuts down MGR and drops you into a shell in the window you left. That worked just fine, so I then tried the following: 1) "Suspd" to a spare window 2) "Suspd" back to the MGR window 3) Enter "sleep 5; exit" so that the shell will exit and fire up MGR after 5 seconds 4) "Suspd" back to the spare window and be ready to enter "clear" to hide the MGR gunk 5) Run the terminal emulator and note that it now loses characters. If I delete steps 2-4, I find that HDB "cu" or "async_main" works just great. I don't know that much about the internals of MGR, but I am inclined strongly to believe that the only thing it is doing when "idle" but alive is calling "select". I'm convinced that somewhere in "select" there is a long critical section run with interrupts blocked, but I can't figure out where it is. The fact that Ethernet exhibits the same symptoms leads me to believe that this is an insurmountable problem inherent in applying the "select" wart to our SysV hog. (I assume that BSD on VAXen solves it using the NETISR code, but I haven't had access to BSD kernel source for a number of years so I can't see how they make "select" work better.) I've wondered if one might be able to solve this problem by carefully applied optimizations to "select", but I don't know what part of the code to concentrate on and haven't had time to experiment until I figured out. ---- Scott S. Bertilson ssb%quest.UUCP@cs.umn.edu scott@poincare.geom.umn.edu -- Scott S. Bertilson ...ssb@quest.UUCP scott@poincare.geom.umn.edu
botton@i88.isc.com (Brian D. Botton) (04/05/91)
In article <1991Apr04.144939.587@quest.UUCP> ssb@quest.UUCP (Scott Bertilson) writes: [ stuff deleted ] >have to run the terminal manager under MGR. Someone suggested that >MGR was too CPU-intensive to run a terminal emulator, so my second >test was to "Suspd" myself to another "wind.o" window and run the >terminal emulator..which normally shuts down MGR and drops you into >a shell in the window you left. That worked just fine . . . . . Brad and I found out about this a couple of months ago, and Brad has been too busy to really look into it. [ more stuff deleted ] > I don't know that much about the internals of MGR, but I >am inclined strongly to believe that the only thing it is >doing when "idle" but alive is calling "select". The select call does indeed seem to be the problem, but at least you have source so you can investigate instead of speculate. > I'm >convinced that somewhere in "select" there is a long critical >section run with interrupts blocked, but I can't figure out >where it is. I'm sure Brad wouldn't mind it if you should happen to find the problem and fix it. > The fact that Ethernet exhibits the same symptoms >leads me to believe that this is an insurmountable problem >inherent in applying the "select" wart to our SysV hog. (I >assume that BSD on VAXen solves it using the NETISR code, >but I haven't had access to BSD kernel source for a number >of years so I can't see how they make "select" work better.) The code for select was based on code from the person that did the TCP/IP port and from the BSD 4.3 select code. >I've wondered if one might be able to solve this problem by >carefully applied optimizations to "select", but I don't know >what part of the code to concentrate on and haven't had time >to experiment until I figured out. You're not alone. Good hunting. -- ... ___ *** _][_n_n___i_i ________ ******* Brian D. Botton (____________I_I______I_I_______I laidbak!botton or /ooOOOO OOOOoo oo oooo oo oo laidbak!bilbo!brian