lisbon@vpnet.chi.il.us (Gerry Swetsky) (05/15/91)
Vpnet uses two Trailblazer Plus'. We recently upgraded both of them to ROM version BC7.00. Here's the problem. Whenever someone calls us at 2400 baud and tries to cat a file, the modem loses sync after about 2,000 characters or so and from there on the result is garbage. We run a locked interface at 19,200. Being as one of the Blazers is ported to ttyd1 off the back of our '386 and the other one comes off our Digi- Board, I've all but ruled out the ports as cause of the problem though I suppose it could be a gettydefs problem. Our UUCP connections are fine and I don't want to do anything to the register settings that will jeopardize the performance of our high speed links. However, there should be a way to make our low speed callers happy too. Here's our register settings: at&n E1 F1 M1 Q6 T V1 W0 X1 Y0 &P0 &T4 Version BC7.00 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006 S10=007 S11=070 S12=050 S18=000 S25=005 S26=000 S38=000 S41=000 S45=000 S47=004 S48=000 S49=000 S50=000 S51:005 S52:002 S54:003 S55=000 S56=017 S57=019 S58:002 S59=000 S61:000 S62=003 S63=001 S64=000 S65=000 S66:001 S67=000 S68:002 S69=000 S90=000 S91=000 S92=000 S94=001 S95:002 S96=001 S97:001 S98=003 S100=000 S101=000 S102=000 S104=000 S105=001 S106:001 S107=020 S110:001 S111:030 S112=001 S121=000 S130:003 S131:001 S150=000 S151=004 S152=001 S153=001 S154=000 S155=000 S157=000 S158=000 S160=010 S161=020 S162=002 S163=003 S164=007 S169=000 S255=000 OK For grins, here's our gettydefs (locked interface). I've inserted C/R's to make it more readable..... 19200N8# B19200 OPOST ONLCR TAB3 BRKINT IGNPAR IXON IXANY ISTRIP ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # B19200 OPOST ONLCR TAB3 BRKINT IGNPAR IXON IXANY ISTRIP ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD HUPCL #login: #19200N8 Thanks in advance. E-mail responses are fine. -- ============================================================================ | Help stamp out stupid .signature files! Gerry Swetsky WB9EBO | | vpnet - Public access Unix and Usenet | | Home (708)833-8122 vpnet (708)833-8126 lisbon@vpnet.chi.il.us | ============================================================================
gandrews@netcom.COM (Greg Andrews) (05/16/91)
In article <1991May14.213151.8741@vpnet.chi.il.us> lisbon@vpnet.chi.il.us (Gerry Swetsky) writes: >Vpnet uses two Trailblazer Plus'. We recently upgraded both of them >to ROM version BC7.00. Here's the problem. Whenever someone calls us >at 2400 baud and tries to cat a file, the modem loses sync after about >2,000 characters or so and from there on the result is garbage. We run >a locked interface at 19,200. ^^^^^^ >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >S61:000 S62=003 S63=001 S64=000 S65=000 S66:001 S67=000 S68:002 S69=000 > ^^^^^^^ ^^^^^^^ > >For grins, here's our gettydefs (locked interface). I've inserted >C/R's to make it more readable..... > >19200N8# B19200 OPOST ONLCR TAB3 BRKINT IGNPAR IXON IXANY ISTRIP >ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # B19200 OPOST ONLCR TAB3 >BRKINT IGNPAR IXON IXANY ISTRIP ECHO ECHOE ECHOK ICANON ISIG CS8 >CREAD HUPCL #login: #19200N8 > You're running a locked interface speed at 19200 bps, and the caller is dialing in at 2400 bps. In other words, the computer pours data into the modem EIGHT TIMES FASTER than the modem can empty itself out. The modem has been told to use (full) duplex RTS/CTS flow control, but I see no evidence that the computer will obey it. After the modem's buffer gets full, it tries to tell the computer to stop (you can even see the CTS light turn off), but the computer isn't listening and it overruns the modem's buffer. Guess how big the TrailBlazer Plus modem's input buffer is? Yup, a little over 2000 bytes. It certainly looks like it's a flow control problem. You can't look to your uucp results because they won't necessarily be the same as catting a large file. Most uucp implementations still use a three packet window with sixty-four bytes in each packet. That means only 210 bytes would be sent before the sender halts - far less than the 2000+ bytes the modem can handle. If you're using uucp spoofing, then the whole thing goes out the window anyway - the modems don't need hardware flow control to work properly in spoofing mode. They use the protocol itself to perform flow control. You can test the flow control operation yourself - just dial in at slow speeds and watch the host modem's CTS and SD lights. They are conveniently next to each other. If hardware flow control is working properly, the lights will be in sync (SD will go off when CTS goes off). If not, then SD will continue shining even when CTS turns off. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
tech@mich-ns.Michigan.COM (Mich. Network Sys. TECH SUPPORT) (05/18/91)
In article <1991May14.213151.8741@vpnet.chi.il.us> lisbon@vpnet.chi.il.us (Gerry Swetsky) writes: >Vpnet uses two Trailblazer Plus'. We recently upgraded both of them >to ROM version BC7.00. Here's the problem. Whenever someone calls us >at 2400 baud and tries to cat a file, the modem loses sync after about >2,000 characters or so and from there on the result is garbage. We run >a locked interface at 19,200. Being as one of the Blazers is ported to >ttyd1 off the back of our '386 and the other one comes off our Digi- >Board, I've all but ruled out the ports as cause of the problem though >I suppose it could be a gettydefs problem. > Here's your problem: you aren't using any flow control and the machine is sending data to the modem faster than it can pump it out onto the phone line. Enable CTS on the modem and put CTSFLOW in your gettydefs entry and see if that works. Your modem's buffer is getting overrun with new data before its been emptied out onto the phone line. -- Michigan Network Systems Technical Support Division 1-800-736-5984 BBS: +1 313 343 0800 E-MAIL: tech@mich-ns.Michigan.COM TELEBIT DIGIBOARD WESTERN DIGITAL 3COM SCO INTERACTIVE UNIX MICROPOLIS ADAPTEC