root@grumbly.UUCP (rb duc) (08/27/90)
I've recently started using a Telebit T2500. I'm getting transmission rates of about 1700 cps from me --> uunet, but only 800-1100 cps from uunet --> me. Has anyone else noticed behavior like this? I'm on the West Coast - is the distance a factor in general? \\\ - - Richard Ducoty ..uunet!grumbly!root _] Capitola, California root@grumbly.com
david@twg.com (David S. Herron) (08/27/90)
In article <150@grumbly.UUCP> root@grumbly.com writes: >I've recently started using a Telebit T2500. I'm getting transmission >rates of about 1700 cps from me --> uunet, but only 800-1100 cps >from uunet --> me. > >Has anyone else noticed behavior like this? I'm on the West Coast - >is the distance a factor in general? Possibly ... if the phone circuit regularly had noise in only one direction then you would see this kind of behaviour. What's more likely is that your machines aren't "equal". That is, uunet is more able to recieve large bursts of characters than your system is. This might be because of small input buffers on your system. Poor implementation of hardware flow control (or no flow control) on your end. Or your system might be slow. (Face it.. Sequent's simply do not lack for CPU cycles... ;-) ...) -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
dean@coplex.UUCP (Dean Brooks) (08/27/90)
root@grumbly.UUCP (rb duc) writes: >I've recently started using a Telebit T2500. I'm getting transmission >rates of about 1700 cps from me --> uunet, but only 800-1100 cps >from uunet --> me. >Has anyone else noticed behavior like this? I'm on the West Coast - >is the distance a factor in general? Yup. Our site is using T2500's to connect to UUNET as well, and we only get between 900 and 1200 cps. When we first acquired our T2500, we were only getting around 300 cps and realized that UUCP spoofing wasn't enabled. I guess 1200cps is better than 300! Still, from what I hear, what you are getting is the expected throughput of UUNET via Trailblazer's. -- dean@coplex.UUCP Dean A. Brooks Copper Electronics, Inc. Louisville, Ky UUCP: !uunet!coplex!dean
rk@theep.boston.ma.us (Robert A. Kukura) (08/27/90)
In article <7841@gollum.twg.com> david@twg.com (David S. Herron) writes: In article <150@grumbly.UUCP> root@grumbly.com writes: >I've recently started using a Telebit T2500. I'm getting transmission >rates of about 1700 cps from me --> uunet, but only 800-1100 cps >from uunet --> me. > >Has anyone else noticed behavior like this? I'm on the West Coast - >is the distance a factor in general? Possibly ... if the phone circuit regularly had noise in only one direction then you would see this kind of behaviour. What's more likely is that your machines aren't "equal". That is, uunet is more able to recieve large bursts of characters than your system is. This might be because of small input buffers on your system. Poor implementation of hardware flow control (or no flow control) on your end. Or your system might be slow. (Face it.. Sequent's simply do not lack for CPU cycles... ;-) ...) It could also be due to size of the files being transferred. Your system and uunet might not be using the same batch size for news. On my system, 50-70K batches seem to consistently achieve better transfer rates than 20-30K batches. -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt! -- -Bob Kukura internet: rk@theep.boston.ma.us uucp: spdcc!theep!rk
rick@pcrat.uucp (Rick Richardson) (08/27/90)
In article <7841@gollum.twg.com> david@twg.com (David S. Herron) writes: >In article <150@grumbly.UUCP> root@grumbly.com writes: >>I've recently started using a Telebit T2500. I'm getting transmission >>rates of about 1700 cps from me --> uunet, but only 800-1100 cps >>from uunet --> me. >This might be because of small input buffers on your system. Poor >implementation of hardware flow control (or no flow control) on your end. >Or your system might be slow. (Face it.. Sequent's simply do not lack >for CPU cycles... ;-) ...) I think its 1) because outgoing speeds are lies, due to buffering, and 2) because UUNET has oversubscribed and is overloaded at all the popular times to call (like all night). Don't flame me, I can back this with stats and I've fooled around with calling at different times to avoid the problem. I'm a 'charter' subscriber, and I remember when I used to get good stats from uunet. Now, there are times when throughput drops to 600 cps at night, and it makes better economic sense to just call during 'prime time'. BTW, It doesn't take a rocket scientist to watch the lights on a modem and tell which side is dogging it. Question of the day: as long as busy signals don't occur, lower thruput translates to more revenue for UUNET. One wonders if they can maintain non-profit status if the thruput keeps going down. Personally, I think the bureau of weights and measures (or whatever) should get involved with all these data carriers and make them charge based on bytes of info delivered (over a particular nominal capacity channel), rather than connect time. UUNET's not that bad (yet), but compuserve is downright criminal. [Obviously, they get to measure and charge for time *my* side is wasting]. -Rick -- Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention PC Research,Inc.| FaxiX - UNIX Facsimile System (tm) |FAX# for uunet!pcrat!rick| FaxJet - HP LJ PCL to FAX (Send WP,Word,Pagemaker...)|Sample (201) 389-8963 | JetRoff - troff postprocessor for HP LaserJet and FAX|Output
chip@tct.uucp (Chip Salzenberg) (08/28/90)
According to root@grumbly.com: >I've recently started using a Telebit T2500. I'm getting transmission >rates of about 1700 cps from me --> uunet, but only 800-1100 cps >from uunet --> me. Such low throughput can be caused by using a "dumb" serial board with the fast modem. If you change to a smart board you will see a great improvement. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
david@monymsys.uucp (David Kozinn) (08/28/90)
In article <150@grumbly.UUCP> root@grumbly.com writes: >I've recently started using a Telebit T2500. I'm getting transmission >rates of about 1700 cps from me --> uunet, but only 800-1100 cps >from uunet --> me. Aside from what the others have mentioned, this could also be the dreaded 8250 slowdown problem. It seems that on many (most?) 386-based systems, the serial drivers can't keep up with input at full speed using the stock 8250 chip. The solution is to replace it with a 16550AN chip and use the FAS 2.06 replacement serial driver that's available out there in net-land. Due to hardware constraints, I wasn't able to replace the chip, but just the change in the driver made a substantial change in incoming speed. -- David Kozinn | UUCP: uunet!vmp!monymsys!david MONY Financial Services MD 75-14 | Domain: monymsys!david@vmp.com Glenpointe Centre West | GEnie: D.KOZINN Teaneck, NJ 07666-6888 | Phone: +1-201-907-6990
lmb@vicom.com (Larry Blair) (08/28/90)
In article <1990Aug27.023921.10506@pcrat.uucp> rick@pcrat.UUCP (Rick Richardson) writes: =>In article <150@grumbly.UUCP> root@grumbly.com writes: =>>I've recently started using a Telebit T2500. I'm getting transmission =>>rates of about 1700 cps from me --> uunet, but only 800-1100 cps =>>from uunet --> me. =I think its 1) because outgoing speeds are lies, due to buffering, =and 2) because UUNET has oversubscribed and is overloaded at all =the popular times to call (like all night). No question that it is because of the buffering. Most uucps only count the time required to transmit the packets for the SYSLOG file, not the time until the `REQUESTED (CY)' message is returned. Since the modem buffers about 10k, the time for sending is understated. Larger batches will reduce, but not eliminate the differential. I suspect that you are only sending very small batches and/or mail which do not exceed the modem's buffer. If you want to see how fast it really is watch the log and time it by hand by waiting for the `REQUESTED (CY)' message. -- Larry Blair ames!vsi1!lmb lmb@vicom.com
mikes@NCoast.ORG (Mike Squires) (08/28/90)
In article <1990Aug27.014916.1645@theep.boston.ma.us> rk@theep.boston.ma.us (Robert A. Kukura) writes: >In article <7841@gollum.twg.com> david@twg.com (David S. Herron) writes: > > In article <150@grumbly.UUCP> root@grumbly.com writes: > >I've recently started using a Telebit T2500. I'm getting transmission > >rates of about 1700 cps from me --> uunet, but only 800-1100 cps > >from uunet --> me. > > > >Has anyone else noticed behavior like this? I'm on the West Coast - > >is the distance a factor in general? > I have the same situation with a TB+ running at 19200 under SCO XENIX 2.3.2. I understand that part of the problem is that time between files is charged to the sending system. I've compared the rates for uucp transfers between my XENIX system and another and my system will show 1700 bytes/sec for transfers from my system to his but his will show about 1000 for the same file, and vice versa.
larry@nstar.uucp (Larry Snyder) (08/28/90)
root@grumbly.UUCP (rb duc) writes: >I've recently started using a Telebit T2500. I'm getting transmission >rates of about 1700 cps from me --> uunet, but only 800-1100 cps >from uunet --> me. >Has anyone else noticed behavior like this? I'm on the West Coast - >is the distance a factor in general? No. I've started feeding sites who dropped uunet and mentioned that they also were receiving transfers in the 850-950 cps range - and after switching to nstar, the transfers increased by 100-150 cps. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA uucp: iuvax!ndmath!nstar!larry -or- larry@nstar Public Access Unix Site (219) 289-0282 (5 lines/PEP/HST/Hayes-V)
rduc@uport.UUCP (Richard Ducoty) (08/28/90)
rk@theep.boston.ma.us (Robert A. Kukura) writes: >In article <7841@gollum.twg.com> david@twg.com (David S. Herron) writes: > In article <150@grumbly.UUCP> root@grumbly.com writes: > >I've recently started using a Telebit T2500. I'm getting transmission > >rates of about 1700 cps from me --> uunet, but only 800-1100 cps > >from uunet --> me. =======0 > Possibly ... if the phone circuit regularly had noise in only one > direction then you would see this kind of behaviour. > What's more likely is that your machines aren't "equal". That is, > uunet is more able to recieve large bursts of characters than your > system is. > This might be because of small input buffers on your system. Poor > implementation of hardware flow control (or no flow control) on your end. > Or your system might be slow. (Face it.. Sequent's simply do not lack > for CPU cycles... ;-) ...) >It could also be due to size of the files being transferred. Your >system and uunet might not be using the same batch size for news. On >my system, 50-70K batches seem to consistently achieve better transfer >rates than 20-30K batches. ================ I should have also mentioned that calling medsys (east coast I think) using YAM and Zmodem I get transfer rates medsys --> me of 1400cps I'm running SCO unix 3.2.1 (ODT) with an "Everex Magic I/O card" - the UART is an NS16550AFN . Does SCO Unix do hardware control very well at 19200 ? Is there anything that can be done to soup it up? The bigger batches would have more data/setup overhead wouldn't they. I notice that some of the 170 byte control files have transfer rates of 50 cps (and range up to 2500 cps depending on ? ) Richard Ducoty ..uunet!claris!netcom!uport!rduc ..uunet!grumbly!root -- Richard Ducoty Microport uunet!{amdahl,amdcad}!netcom!uport!rduc Scotts Valley, CA claris!netcom!uport!rduc 408 438-8649
rduc@uport.UUCP (Richard Ducoty) (08/29/90)
david@monymsys.uucp (David Kozinn) writes: >In article <150@grumbly.UUCP> root@grumbly.com writes: >>I've recently started using a Telebit T2500. I'm getting transmission >>rates of about 1700 cps from me --> uunet, but only 800-1100 cps >>from uunet --> me. >Aside from what the others have mentioned, this could also be the dreaded 8250 >slowdown problem. It seems that on many (most?) 386-based systems, the serial >drivers can't keep up with input at full speed using the stock 8250 chip. The >solution is to replace it with a 16550AN chip and use the FAS 2.06 replacement >serial driver that's available out there in net-land. Due to hardware >constraints, I wasn't able to replace the chip, but just the change in the >driver made a substantial change in incoming speed. ======= I was using an NS16550AFN (what is the difference twixt the AN, AFN and (FAN?) versions of the NS16550) Are you running Interactive with the FAS? I've got SCO Unix - anyone get the FAS and SCO Unix working together? Or is that unrealistic? Richard Ducoty -- Richard Ducoty Microport uunet!{amdahl,amdcad}!netcom!uport!rduc Scotts Valley, CA claris!netcom!uport!rduc 408 438-8649