williams@cs.umass.edu (01/03/91)
I just installed an internal Trailblazer Plus in my 486/25 clone running SCO Unix 3.2. At first, I tried to use COM3 but that broke the mouse on COM1 so I guessed that the problem had to do with the interrupts, moved COM2 to COM4 and put the modem at COM2 (when I tried disabling COM2, the mouse on COM1 stopped working). I am calling SCO's sosco system for testing and the Systems entry is set to use the dialTBIT dialer with the speed set at 19200. uutry reports CONNECT FAST, but the xferstats shows that I'm only getting 76 bytes per second on large transfers! What am I doing wrong? Do I need to use the FAS driver instead of SCO's? Do I need to initialize the modem (dialTBIT -z?) at powerup since it has no non-volatile ram? Thanks for any help! Leo c/o williams@cs.umass.edu leo@aai.com
debra@svin02.info.win.tue.nl (Paul de Bra) (01/04/91)
In article <24558@dime.cs.umass.edu> williams@cs.umass.edu writes: >...[description of juggling with com ports deleted] >uutry >reports CONNECT FAST, but the xferstats shows that I'm only getting >76 bytes per second on large transfers! I have seen a similar problem when I had a board with a COM1 and not a COM2 (no second chip) and another board with a COM2 and COM3. The COM2 didn't work right because of the presence of the non-existent COM2 on the other board. I changed it to COM4 and all went well. It sounds like you have an interrupt or address conflict causing you system not to react properly to incoming characters. (btw i was using FAS 2.07) Paul. (debra@research.att.com, debra@win.tue.nl)
gil@limbic.ssdl.com (Gil Kloepfer Jr.) (01/04/91)
In article <24558@dime.cs.umass.edu> williams@cs.umass.edu writes: >I am calling SCO's sosco system for testing and the Systems entry is >set to use the dialTBIT dialer with the speed set at 19200. uutry >reports CONNECT FAST, but the xferstats shows that I'm only getting >76 bytes per second on large transfers! The internal Telebits only have the 16450 UARTs in them, so you would need to unsolder the 16450 and replace it with a 16550 in order to really get good performance, even with FAS. I had a friend who did this, and now the thing flies. Note though that you also may need to perform a procedure to turn hardware flow control on (I think even the internal telebit supports this internally). If this doesn't help, then you'll need to do the UART replacement. I don't recommend it to the meek or someone who thinks that they can do fine soldering with a 100W soldering gun :-) A fix that usually works (but is less than satisfactory when you consider the price of the modem) is to reduce the speed to 9600 baud. This will generally clear-up the overrun problems associated with the packet loss (which is why your throughput is so bad). Why Telebit didn't use 16550s on that modem beats the heck out of me ... -- Gil Kloepfer, Jr. gil@limbic.ssdl.com ...!ames!limbic!gil Southwest Systems Development Labs (Div of ICUS) Houston, Texas "There are beautiful people I wish would have never opened their mouths, because such ugliness oozes out." Philosophy Prof. at NYIT
jgd@Dixie.Com (John G. DeArmond) (01/05/91)
gil@limbic.ssdl.com (Gil Kloepfer Jr.) writes: >In article <24558@dime.cs.umass.edu> williams@cs.umass.edu writes: >>I am calling SCO's sosco system for testing and the Systems entry is >>set to use the dialTBIT dialer with the speed set at 19200. uutry >>reports CONNECT FAST, but the xferstats shows that I'm only getting >>76 bytes per second on large transfers! >The internal Telebits only have the 16450 UARTs in them, so you would >need to unsolder the 16450 and replace it with a 16550 in order to >really get good performance, even with FAS. I had a friend who did >this, and now the thing flies. This is absolutely correct. Telebit was brain damaged not to use the 16550. Another modification that I consider mandatory for internal modems of any sort is to add a switch to either the send or receive data line from the uart to the modem so that one can interrupt the data flow. If you don't and the modem gets to chatting with a getty, you'll find that (at least with ISC unix) the conversation takes up all the processor time and you'll be unable to even process keystrokes. Big Red Switch time. I've observed this even with 2400 baud modems. Plus, as KE4ZV (hi gary) can verify, an internal modem will conduct a lot of lightening into your machine and turn it back into silicon raw materials minus all the blue smoke. Of the 2 people I know of who have been heavily zorched by lightening in the last year, both had it come in over the phone line and both lost very expensive computers. John -- John De Armond, WD4OQC | "Purveyors of speed to the Trade" (tm) Rapid Deployment System, Inc. | Home of the Nidgets (tm) Marietta, Ga | "To be engaged in opposing wrong offers but {emory,uunet}!rsiatl!jgd | a slender guarantee of being right."
seg@ingres.com (scott e garfinkle) (01/05/91)
In article <1660@svin02.info.win.tue.nl> debra@svin02.info.win.tue.nl (Paul de Bra) writes: >In article <24558@dime.cs.umass.edu> williams@cs.umass.edu writes: >>...[description of juggling with com ports deleted] >>uutry >>reports CONNECT FAST, but the xferstats shows that I'm only getting >>76 bytes per second on large transfers! > >It sounds like you have an interrupt or address conflict causing >you system not to react properly to incoming characters. >(btw i was using FAS 2.07) I suppose that may also be possible; however, I think the fundamental problem is likely to be the 8250 UART that Telebit chose to use on the T18PC. Replacing that with a 16550 and using FAS let me go from ~80 cps to ~1300 cps on my system at home. -Scott E. Garfinkle
andrew@acwbust.incom.de (Andrew Wheadon) (01/05/91)
In article <24558@dime.cs.umass.edu> williams@cs.umass.edu writes: >I just installed an internal Trailblazer Plus in my 486/25 clone running SCO > >I am calling SCO's sosco system for testing and the Systems entry is >set to use the dialTBIT dialer with the speed set at 19200. uutry >reports CONNECT FAST, but the xferstats shows that I'm only getting >76 bytes per second on large transfers! You should be getting CONNECT FAST/UUCP if you want to have high transfer- rates with uucp. See the dictionary in comp.dcom.modems on "spoofing" Have you set S111=30 ? If yes then have SCO set S111=30 or S111=255 needed to get a uucp-g-protokoll-spoofing connection. > >What am I doing wrong? Do I need to use the FAS driver instead of >SCO's? I do not know how well SCO's driver works but if you start getting errors (Which will be between Computer and Modem as the PEP connection between Modem and Modem seems error-free to the software. Then you should switch to a FAS driver. > Do I need to initialize the modem (dialTBIT -z?) at powerup >since it has no non-volatile ram? Are you sure about this ? Is there no AT&W1 or AT&W2 command to save your configuration ? > >Thanks for any help! >Leo c/o williams@cs.umass.edu leo@aai.com Hope it was some help and you hadn't already checked all these things Bye Andrew andrew@acwbust.incom.de
gil@limbic.ssdl.com (Gil Kloepfer Jr.) (01/06/91)
In article <5626@rsiatl.Dixie.Com> jgd@Dixie.Com (John G. DeArmond) writes: >Plus, as KE4ZV (hi gary) can verify, an internal modem will conduct >a lot of lightening into your machine and turn it back into silicon >raw materials minus all the blue smoke. Make that three...'cept not with a Telebit... I recently had the unfortunate experience of one of those "one-hit-wonders" which come without warning. Nothing damaged on the electric lines, but it fried a voice processor (3B1 Voice Power board), a serial board (the modem survived, believe it or not), and a terminal connected to the same serial board as the modem. An interesting follow-up question is this: There is a small amount of lightning protection on the phone lines (usually of the carbon spark-gap variety), which obviously don't eliminate the problem nearly enough for sensitive electronic equipment. I also know (and have preached) that NOTHING can stop a good lightning strike from frying your computer, except for unplugging it from the power and phone lines. However, how effective are a pair of MOV's from each leg of the phone line to ground? (ie. ring-to-ground and tip-to-ground). One problem with both the voice power board (no MOVs) and the modem (only a MOV across ring and tip) was the lack of adaquate means of sending the offending high-voltage surge to ground. After having my unfortunate experience, I made a little phone-line surge suppressor as mentioned above...however I'm not too sure of how effective it may be. BTW: my device handles 4 phone lines, and it is connected at the first available place I can attach it to the phone line. -- Gil Kloepfer, Jr. gil@limbic.ssdl.com ...!ames!limbic!gil Southwest Systems Development Labs (Div of ICUS) Houston, Texas "There are beautiful people I wish would have never opened their mouths, because such ugliness oozes out." Philosophy Prof. at NYIT