jim@shograf.COM (jim morris) (03/01/91)
Hi, I have been having a problem, and was hoping that someone else has seen, and solved, this problem. I am getting my news files batched, compressed and about 100-50k blocks. After recving about 10 or so, (Sometimes less sometime more), files the modems stop talking to each other. I can see my end timeing out and resending something (Probabably ACK??). But I never get anything back from the other side. The same effect can be achieved by enabling XON/XOFF control in the modem and recving an XOFF. (But that is NOT what is happening). Both modems have NO flow control enabled, they both rely on UUCP protocol for the handshaking. Someone is locking up... Either my modem is not sending any more, or the other side is not recving or sending anymore. I have tried every S register setting I, or telebit support, can think of to no effect. Of course UUCP eventually times out and hangs up. I get the interrupted file on the next dial-in. Anyone got any idea what this problem is!! Has anyone else seen this problem. Please HELP if you can... Thanks Jim -- Jim Morris, E-Mail: jim@shograf.com Voice: (415) 903-3887 _ SHO graphics. Practical PEX
bill@bilver.uucp (Bill Vermillion) (03/04/91)
In article <554@shograf.COM> jim@shograf.COM (jim morris) writes: > I have been having a problem, and was hoping that someone else >has seen, and solved, this problem. >I am getting my news files batched, compressed and about 100-50k blocks. >After recving about 10 or so, (Sometimes less sometime more), files the >modems stop talking to each other. I can see my end timeing out and resending >something (Probabably ACK??). But I never get anything back from the other >side. The same effect can be achieved by enabling XON/XOFF control in the >modem and recving an XOFF. (But that is NOT what is happening). >Both modems have NO flow control enabled, they both rely on UUCP protocol >for the handshaking. Someone is locking up... Either my modem is not sending >any more, or the other side is not recving or sending anymore. >I have tried every S register setting I, or telebit support, can think of >to no effect. Of course UUCP eventually times out and hangs up. >I get the interrupted file on the next dial-in. >Anyone got any idea what this problem is!! Has anyone else seen this problem. Hm. When I started having this problem last summer I thought it might have been the machine I was using for transmission (old R/S6000 ) but it continued when I moved over to a '386 box. Unit was a Trailblazer plus. T'bit support gave me all sorts of undocumented registers, and we tried them all. Nothing. Nada. Zip. Still the problem. I would get a lockup after about 150k was sent. A big file, or smaller files. With the smaller files all was fine until total data transmitted was in the 150k to 200k range (typically). Sometimes a big file would go all the way through. This is with uucp g spoofing and cts/rts flow contol, as opposed to your xon/xoff. T'bit said they had not seen anything like this. Well that now makes two of us doesn't it. It pointed to the modem itself. Late December I switched over to a T2500. Guess what. Still happens. I think it is the serial ports. Have the wiring done and will try the changeover tonight. You are not alone. -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
jpr@jpradley.jpr.com (Jean-Pierre Radley) (03/05/91)
In article <1991Mar4.030916.3429@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: >T'bit support gave me all sorts of undocumented registers, and we tried >them all. Nothing. Nada. Zip. Still the problem. I would get a lockup >after about 150k was sent. A big file, or smaller files. With the >smaller files all was fine until total data transmitted was in the 150k to >200k range (typically). Sometimes a big file would go all the way >through. > >This is with uucp g spoofing and cts/rts flow contol, as opposed to your >xon/xoff. T'bit said they had not seen anything like this. Well that now >makes two of us doesn't it. Whatever I do in my dialTBIT binary, or any chat script, SCO's uucico will ALWAYS set: -ctsflow -rtsflow -ixon -xoff -ixany. Any time you have uucico running, go to another screen and do an stty reading on the uucico port and see it for yourself. So I've decided that S58=0 and S68=0 is the way to go, since uucico ignores everything in the way of flow control. Jean-Pierre Radley NYC Public Unix jpr@jpradley.jpr.com CIS: 72160,1341
gerry@jts.com (G. Roderick Singleton ) (03/08/91)
In article <1991Mar4.030916.3429@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: <In article <554@shograf.COM> jim@shograf.COM (jim morris) writes: < <> I have been having a problem, and was hoping that someone else <>has seen, and solved, this problem. < <>I am getting my news files batched, compressed and about 100-50k blocks. <>After recving about 10 or so, (Sometimes less sometime more), files the <>modems stop talking to each other. I can see my end timeing out and resending <>something (Probabably ACK??). But I never get anything back from the other <>side. The same effect can be achieved by enabling XON/XOFF control in the <>modem and recving an XOFF. (But that is NOT what is happening). <>Both modems have NO flow control enabled, they both rely on UUCP protocol <>for the handshaking. Someone is locking up... Either my modem is not sending <>any more, or the other side is not recving or sending anymore. <>I have tried every S register setting I, or telebit support, can think of <>to no effect. Of course UUCP eventually times out and hangs up. <>I get the interrupted file on the next dial-in. < <>Anyone got any idea what this problem is!! Has anyone else seen this problem. < <Hm. When I started having this problem last summer I thought it might have <been the machine I was using for transmission (old R/S6000 ) but it <continued when I moved over to a '386 box. Unit was a Trailblazer plus. < <T'bit support gave me all sorts of undocumented registers, and we tried <them all. Nothing. Nada. Zip. Still the problem. I would get a lockup <after about 150k was sent. A big file, or smaller files. With the <smaller files all was fine until total data transmitted was in the 150k to <200k range (typically). Sometimes a big file would go all the way <through. < <This is with uucp g spoofing and cts/rts flow contol, as opposed to your <xon/xoff. T'bit said they had not seen anything like this. Well that now <makes two of us doesn't it. < <It pointed to the modem itself. Late December I switched over to a T2500. <Guess what. Still happens. I think it is the serial ports. Have the <wiring done and will try the changeover tonight. You are not alone. < < <-- <Bill Vermillion - UUCP: uunet!tarpit!bilver!bill < : bill@bilver.UUCP I asked a similar question about three weeks ago ( Iknow I promised to summarize) and then went on vacation. My confguartion at the time was 2-TB+'s with 5.01 ROMs, but things got so bad during the first week I was away that I came in and put the 4.00 ROMs back. VOILA! The problems went away and I've been able to absorb and handle the recent news flood in Toronto ( handled 300 Mb in 3.5 days ) with no uucp/modem problems. This suggests, to me, that Telebit has bugs in recent versions of their TB+ code which affect uucp performance. I shall post my summary when I, eventually, get answers from Telebit. Hope this helps, ger -- G. Roderick Singleton, System and Network Manager, JTS Computers {yunexus | uunet | geac | torsqnt}!gerry@jtsv16.jts.com
dvv@hq.demos.su (Dmitry V. Volodin) (03/08/91)
In <1991Mar05.051051.27651@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes: >Whatever I do in my dialTBIT binary, or any chat script, SCO's uucico will >ALWAYS set: -ctsflow -rtsflow -ixon -xoff -ixany. Better do it in uucico binary. Or use FAS. -- Dmitry V. Volodin <dvv@hq.demos.su> | fax: +7 095 233 5016 | Call me Dima ('Dee-...) phone: +7 095 231 2129 |
jpr@jpradley.jpr.com (Jean-Pierre Radley) (03/10/91)
In article <1991Mar7.214200.20682@hq.demos.su> dvv@hq.demos.su (Dmitry V. Volodin) writes: >In <1991Mar05.051051.27651@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes: > >>Whatever I do in my dialTBIT binary, or any chat script, SCO's uucico will >>ALWAYS set: -ctsflow -rtsflow -ixon -xoff -ixany. > >Better do it in uucico binary. Or use FAS. Spasibo bolshoi, Dima, but would you have any idea which byte of SCO UNIX 3.2.2 uucico should be patched? And can I use FAS on a multiport board (Specialix, in this case). And how would FAS help anyways, if uucico makes its own decisions about flow control? Jean-Pierre Radley NYC Public Unix jpr@jpradley.jpr.com CIS: 72160,1341
jpr@jpradley.jpr.com (Jean-Pierre Radley) (03/10/91)
In article <1991Mar7.204240.5497@jts.com> gerry@jts.com (G. Roderick Singleton ) writes: >In article <1991Mar4.030916.3429@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: ><In article <554@shograf.COM> jim@shograf.COM (jim morris) writes: >I asked a similar question about three weeks ago ( Iknow I promised to summarize) >and then went on vacation. My confguartion at the time was 2-TB+'s with 5.01 ROMs, >but things got so bad during the first week I was away that I came in and put the 4.00 >ROMs back. VOILA! The problems went away and I've been able to absorb and handle >the recent news flood in Toronto ( handled 300 Mb in 3.5 days ) with no uucp/modem >problems. This suggests, to me, that Telebit has bugs in recent versions of their >TB+ code which affect uucp performance. > >I shall post my summary when I, eventually, get answers from Telebit. [Could you please not post lines that exceed 80 chars.? or better not over 78 chars.?] A month ago, I upgraded a Trailblazer Plus to Version 7 ROM. Since then, the majority of my major Usenet downloads end in FAILURE, and my feed is complaining. Maybe I should put the old chips back in? Jean-Pierre Radley NYC Public Unix jpr@jpradley.jpr.com CIS: 72160,1341
grr@cbmvax.commodore.com (George Robbins) (03/10/91)
In article <1991Mar10.014710.27032@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes: > > A month ago, I upgraded a Trailblazer Plus to Version 7 ROM. Since then, the > majority of my major Usenet downloads end in FAILURE, and my feed is > complaining. Maybe I should put the old chips back in? > > Jean-Pierre Radley NYC Public Unix jpr@jpradley.jpr.com CIS: 72160,1341 I'd certainly give it a try. Telebit seems not to have heard of regression testing and is becoming somewhat infamous for new rom versions which contain worse problems than they fix. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
ebersman@uunet.uu.net (Paul Ebersman) (03/10/91)
>> From: George Robbins; Subject: Re: Telebit T2500 -> TB+ UUCP spoofing problem, HELP: grr> In article <1991Mar10.014710.27032@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes: > A month ago, I upgraded a Trailblazer Plus to Version 7 ROM. Since > then, the majority of my major Usenet downloads end in FAILURE, and > my feed is complaining. Maybe I should put the old chips back in? > > Jean-Pierre Radley NYC Public Unix jpr@jpradley.jpr.com CIS: 72160,1341 grr> I'd certainly give it a try. Telebit seems not to have heard of grr> regression testing and is becoming somewhat infamous for new rom grr> versions which contain worse problems than they fix. Have you actually called Telebit Tech Support? Telebit has broken things in new ROM releases, but they are quite fast in getting new releases out if there is a problem. Most of the time, a configuration change is all that is needed. Admittedly, Telebit could be much better about release notes with new ROM's, warning of possible config changes, but since you can call an 800 number to get support, this is annoying, not fatal. Finally, while 6.00 and 6.01 had a few problems, the 7.00 ROM's are quite stable. We have 110 T2500's running it and, so far, all the problems we have seen in the last 4-5 months have been in customer configs or with really antique 2400 baud modems. -- Paul A. Ebersman @ UUNET Communications uunet!ebersman or ebersman@uunet.uu.net The difference between theory and practice in practice is greater than the difference between theory and practice in theory.
larry@nstar.rn.com (Larry Snyder) (03/11/91)
jpr@jpradley.jpr.com (Jean-Pierre Radley) writes: >And can I use FAS on a multiport board (Specialix, in this case). nope - FAS is for dumb multiport cards with the buffered 16550AFN chip and the Specialix is a smart board with an on-board processor -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}