Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!astemgw!kuis!aegis!davidg From: davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) Newsgroups: comp.dcom.modems Subject: Re: ISC 2.2.1 FAS 2.08 Message-ID: Date: 12 Jun 91 22:05:13 GMT References: <676362130.17@egsgate.FidoNet.Org> Organization: Aegis Society Lines: 28 Dean.Carpenter@f98.n250.z1.FidoNet.Org (Dean Carpenter) writes: > I'm running ISC 2.2.1 on a Hauppauge 4860 33MHz. I recently installed > FAS 2.08 as the standard ISC asy driver couldn't handle 19200 inbound > properly (according to ISC). But I'm still seeing the same symptoms > with FAS - that is, outbound at 19200 (via TB2500) gets about 1500 cps > but inbound gets alarms. > > Watching the TX/RX leds on the tb2500 I can see that data pours into the > system for about 5 seconds, then stops. Neither led is alight. After > about 10 seconds, the alarm occurs and another 5 second burst occurs. > Due to these 10 second pauses, the cps rate drops to around 500 or worse. > Watching the output from Uutry -x9 shows the alarms happening when : I don't get the alarms but I see similar phenomena happening when aegis pools kyoto-u--the data comes in bursts and then stops. But the question is whether aegis is reading it in burts or the Sun at running kyoto-u is sending in bursts. Since the data comes in smoothly when I poll another copy of the aegis software (WAFFLE on a DOS machine) I concluded it was the Sun, not aegis. So I myself would hazard as guess that it's the sending side, not your receving side... Dave -- Dave McLane