dan@hrc.UUCP (Dan Troxel) (07/06/89)
I feed several sites here in Arizona. Most of my sites get at least 1100 chars/second. But there are 2 that are getting 800-900 chars/second. Of course, we are running Telebits, and don't have uucp source code. Any ideas? -- Dan Troxel @ Handwriting Research Corporation WK 1-602-957-8870 Camelback Corporate Center 2821 E. Camelback Road Suite 600 Phoenix, AZ 85016 ncar!noao!asuvax!hrc!dan zardoz!hrc!dan hrc!dan@asuvax.asu.edu
amanda@intercon.uu.net (Amanda Walker) (07/07/89)
In article <200038@hrc.UUCP>, dan@hrc.UUCP (Dan Troxel) writes: > I feed several sites here in Arizona. Most of my sites get at least > 1100 chars/second. But there are 2 that are getting 800-900 chars/second. > > Of course, we are running Telebits, and don't have uucp source code. > My guess is that the two sites in question are talking to their Telebits at 9600 baud instead of 19200 baud, thus causing a bottleneck on their end. Either that or they're using T1000s, which only go up to 9600. -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
jack@csccat.UUCP (Jack Hudler) (07/07/89)
In article <200038@hrc.UUCP> dan@hrc.UUCP (Dan Troxel) writes: > >I feed several sites here in Arizona. Most of my sites get at least >1100 chars/second. But there are 2 that are getting 800-900 chars/second. > >Of course, we are running Telebits, and don't have uucp source code. > >Any ideas? My telebit only get's on average 580-640 (over one month). It all depends on how fast you can give it and how fast they can take it. Think about, some computer (mine) can't take having 9600 baud shoved down it's throat and unbatch news at the same time. :-) I should mention that I use a T1000. -- Jack Computer Support Corportion Dallas,Texas Hudler UUCP: {texsun,texbell,killer}!csccat!jack
johnk@opel.UUCP (John Kennedy) (07/07/89)
In article <1160@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: amanda>In article <200038@hrc.UUCP>, dan@hrc.UUCP (Dan Troxel) writes: dan> I feed several sites here in Arizona. Most of my sites get at least dan> 1100 chars/second. But there are 2 that are getting 800-900 chars/second. dan> dan> Of course, we are running Telebits, and don't have uucp source code. dan> amanda> My guess is that the two sites in question are talking to their amanda> Telebits at 9600 baud instead of 19200 baud, thus causing a bottleneck amanda> on their end. Either that or they're using T1000s, which only go up to amanda> 9600. Is it possible to tell if a given site (including your own) is suffering from a high amount of retried data due to UART overruns, etc.? All I've ever seen is a *net* throughput in chars/second, but can you monitor a success ratio on the protocol? -- John Kennedy johnk@opel.UUCP Second Source, Inc. Annapolis, MD
bob@tinman.cis.ohio-state.edu (Bob Sutterfield) (07/07/89)
In article <1160@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: In article <200038@hrc.UUCP>, dan@hrc.UUCP (Dan Troxel) writes: I feed several sites here in Arizona. Most of my sites get at least 1100 chars/second. But there are 2 that are getting 800-900 chars/second. My guess is that the two sites in question are talking to their Telebits at 9600 baud instead of 19200 baud, thus causing a bottleneck on their end. Either that or they're using T1000s, which only go up to 9600. Or those systems could be small and slow without enough horsepower or I/O bandwidth to shove that many characters per second through their serial ports, no matter the baud rate setting. Some little boxes wheeze heavily after climbing only two flights of stairs at 9600. Are any of those slow neighbors running Xenix on an AT? Or perhaps a VAX 750 with DZ-11 terminal interfaces? Those character interrupts will suck a Unibus VAX dry...
hakanson@mist.CS.ORST.EDU (Marion Hakanson) (07/08/89)
In article <1160@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >. . . >on their end. Either that or they're using T1000s, which only go up to >9600. > >-- >Amanda Walker >InterCon Systems Corporation >amanda@intercon.uu.net | ...!uunet!intercon!amanda > Don't sell the T1000 short -- they do go faster than 9600bps, even if they can't match a Trailblazer+ or T2500. The T1000 I use at home claims 11680bps. My measurements of file transfers (e.g. zmodem) show a very noticeable speedup if I run the rs232 connection to the T1000 at 19200bps as compared to 9600bps. -- Marion Hakanson Domain: hakanson@cs.orst.edu UUCP : {hp-pcd,tektronix}!orstcs!hakanson
dlu@wobble.uucp (Doug Urner) (07/08/89)
In article <1160@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >In article <200038@hrc.UUCP>, dan@hrc.UUCP (Dan Troxel) writes: >> I feed several sites here in Arizona. Most of my sites get at least >> 1100 chars/second. But there are 2 that are getting 800-900 chars/second. > >My guess is that the two sites in question are talking to their >Telebits at 9600 baud instead of 19200 baud, thus causing a bottleneck >on their end. Either that or they're using T1000s, which only go up to >9600. > Sadly that is not always the case. The best I have been able to do between wobble and uunet (both Trailblazer+'s and both running the link to the modem at 19.2) is in the same range. The B5.00 firmware doesn't make a difference either. I am able to get much better through put with local connections and even down to the Bay Area, but to uunet better than 900 is a real surprise. Any thoughts? Doug -- ----------------------------------------------------------------------------- Doug Urner, uunet!wobble!dlu, Uni-Ops Systems, Bellingham, WA 206/676-5759
debra@alice.UUCP (Paul De Bra) (07/08/89)
In article <1989Jul8.042330.19789@wobble.uucp> dlu@wobble.UUCP (Doug Urner) writes: >... >Sadly that is not always the case. The best I have been able to do between >wobble and uunet (both Trailblazer+'s and both running the link to the modem >at 19.2) is in the same range. The B5.00 firmware doesn't make a difference >either. I am able to get much better through put with local connections >and even down to the Bay Area, but to uunet better than 900 is a real >surprise. Any thoughts? The throughput is not just limited by the modems. I have no experience with Telebits, but I do use several hardwired links (rs232 at 9.6 or 19.2) and get very different results depending on the computer hardware and the load on the system. Sending data from a microvaxII to a 25Mhz 386 system for instance is much faster than receiving data on the microvaxII from the 386. Also, uucp to a heavily loaded Gould PN 6000 is much slower than to the microvaxII or the 386. Uunet handles lots of communications simultaneously. This means it must be under constant heavy load, implying low throughput. The limit is in uunet and its connection to the modems, not in the modem connection. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
snoopy@sopwith.UUCP (Snoopy) (07/08/89)
In article <3175@csccat.UUCP> jack@csccat.UUCP (Jack Hudler) writes: | Think about, some computer (mine) can't take | having 9600 baud shoved down it's throat and unbatch news | at the same time. :-) A quick and dirty way to keep news unbatching from dragging down uucp throughput is to set up a shell script rnews which invokes the real rnews niced down to 20. Also helps interactive response if you have user(s) trying to do stuff while news unbatches. I believe it is also possible to set news up to stash the batches away and process them later. This method, however, requires one to get their hands dirty reading the documentation. :-) _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ qiclab!sopwith!snoopy | | |___| parsely!sopwith!snoopy | tekecs | |___| sun!nosun!illian!sopwith!snoopy |_________| "I *was* the next man!" -Indy
pim@ctisbv.UUCP (Pim Zandbergen) (07/09/89)
In article <200038@hrc.UUCP> dan@hrc.UUCP (Dan Troxel) writes: > >I feed several sites here in Arizona. Most of my sites get at least >1100 chars/second. But there are 2 that are getting 800-900 chars/second. > You might want to make sure you have disabled the compress feature (S110=0) when you send or receive compressed newsbatches. I have witnessed an increase in transfer rates from 850-900 to 1250-1300 chars/second. -- --------------------+----------------------+----------------------------------- Pim Zandbergen | phone: +31 70 542302 | CTI Software BV pim@ctisbv.UUCP | fax : +31 70 512837 | Laan Copes van Cattenburch 70 ...!uunet!mcvax!hp4nl!ctisbv!pim | 2585 GD The Hague, The Netherlands
jack@swlabs.UUCP (Jack Bonn) (07/09/89)
In article <1989Jul8.042330.19789@wobble.uucp> dlu@wobble.UUCP (Doug Urner) writes: > The best I have been able to do between >wobble and uunet (both Trailblazer+'s and both running the link to the modem >at 19.2) is in the same range. The B5.00 firmware doesn't make a difference >either. I am able to get much better through put with local connections >and even down to the Bay Area, but to uunet better than 900 is a real >surprise. Any thoughts? I think the problem is with uunet. Both pcrat (Rick Richardson) and I are getting reduced throughputs to uunet. Let me look: System Mode Bytes Ave. CPS Burst CPS uunet Rcvd 3430 1706 1776 uunet Sent 1006756 690 982 This is on their (Non ATT) 800 line. Looks like uunet doesn't have enough horsepower here. What are you other folks getting for throughput? By the way, has anyone looked at what some of the PCM compression schemes (like Adaptive PCM) will do to PEP? What kind of compression is Sprint using? -Jack -- Jack Bonn, KA1SMW, <> Software Labs, Ltd, Box 451, Easton CT 06612 uunet!swlabs!jack (UUCP) jack%swlabs.uucp@uunet.uu.net (INTERNET)
gwang@berlioz (George Wang) (07/09/89)
Does anyone have the C source code for the Unix Version of Zmodem?? I am desperately looking for it and I'd appreciate it if someone could send me email if they do have it... Thanks George Gwang@logic.nsc.com
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (07/09/89)
In article <1989Jul8.042330.19789@wobble.uucp>, dlu@wobble.uucp (Doug Urner) writes: > ... The best I have been able to do between > wobble and uunet (both Trailblazer+'s and both running the link to the modem > at 19.2) is in the same range.... > > Doug Urner, uunet!wobble!dlu, Uni-Ops Systems, Bellingham, WA 206/676-5759 Turning compression <<off>> pushed compressed news batches from 800-950 to 1100-1300 here. Vernon Schryver Silicon Graphics vjs@sgi.com
grr@cbmvax.UUCP (George Robbins) (07/10/89)
In article <7102@swlabs.UUCP> jack@swlabs.UUCP (Jack Bonn) writes: > In article <1989Jul8.042330.19789@wobble.uucp> dlu@wobble.UUCP (Doug Urner) writes: > > The best I have been able to do between > >wobble and uunet (both Trailblazer+'s and both running the link to the modem > >at 19.2) is in the same range. .... > > but to uunet better than 900 is a real surprise. Any thoughts? ... > I think the problem is with uunet. Both pcrat (Rick Richardson) and I are > getting reduced throughputs to uunet. Let me look: > > System Mode Bytes Ave. CPS Burst CPS > uunet Rcvd 3430 1706 1776 > uunet Sent 1006756 690 982 > > This is on their (Non ATT) 800 line. Looks like uunet doesn't have > enough horsepower here. What are you other folks getting for throughput? Well, it's hard to make good estimates about performance without having some sense of the activity level at the far end. I seem 1200 cps type rates when my system (a 785) is unloaded and presumably uunet is lightly loaded. As soon as a news unbatching or batching run starts up on my machine, the speed drops by as much as 50%. The long term averages are pretty consistant though. I've attached some statistics for uunet and another system 'bpa' for comparison. The report is from an awk script that analyzes my SYSLOG file. Transfers are dropped in bins depending on the length of the transfer and apparent speed. Transfers of < 256 bytes are assumed to be itty bitty control files where the overhead is so large in comparision to the transmision time they are dumped in their own bin. Transfers with an effective speed of less thant 2500 bps are assumed to have taken place over 2400 BPS modems, which is a more or less supportable assumption. In examining these statistics, it is important to understand that the 'transmit' times reported by uucp with a Trailblazer tend to be completely bogus! The trailblazer buffers several (4->32k?) of data and claims it is 'done' before this data has actually been transmitted. The effect is that the first [buffer size] of any transfer can go as fast as 19.2KBPS and since most uucp transfers tend to be pretty small files, the tranmit times are badly skewed by this reporting retry. For a concrete expample. I recently changed the news batch size for bpa from 50K-byte to 250K-byte. Prior to this change, transmit rate averaged ~33% faster than receive, afterwards the disparity was chopped by a factor of two. What does this mean in terms of uunet/trailblazer performance? As the administrator of a fairly large multi-user unix system, I sense maybe half the "slowdown" is on my end. As long the overall transfer rate is about 4 times what I'd get on an olde fashioned 2400 baud modem, I'm fairly content. Someone running a lightly loaded hotshot 386 system might feel that sluggish performance on the part of uunet is costing them some bucks. The question of whether trailblazers are really 'faster' in the long run than a 'constant speed' V.32 modem remains an open issue. By the way, we dial directly into uunet over telco/AT&T lines. Anybody using various economy connections or dialing out thru a PBX might want to try it straight and see what effect this has. It would nice if Rick would publish some statistics on his end. We've shoved > 100M-Byte/month from/to uunet for the last 3 months and are only one of many sites. Another report I have indicates we move 14 M-byte/day over an average of .41 active transfers at any given time. I suspect Rick's numbers might be a teensy bit larger. uunet ================================================================================ system transfer files fail M-bytes hours speed peak retry ======= ============ ====== ==== ======== ====== ===== ===== ===== March 1989: uunet fast receive 1768 0 23.678 9:27 6959 bps 13334 bps fast send 697 0 5.984 1:31 10941 bps 15371 bps 0.2% slow receive 958 0 11.510 16:10 1976 bps 2444 bps slow send 252 0 3.206 4:45 1869 bps 2466 bps 0.2% misc control 3664 0 0.375 1:09 April 1989: uunet fast receive 3615 0 98.890 36:00 7630 bps 13277 bps fast send 724 0 6.426 1:43 10339 bps 16840 bps 0.1% slow receive 227 0 1.931 3:19 1613 bps 2500 bps slow send 15 0 0.080 0:06 1979 bps 2376 bps misc control 4794 0 0.506 1:45 May 1989: uunet fast receive 3703 0 132.472 48:49 7535 bps 13508 bps fast send 791 0 7.189 1:53 10600 bps 16987 bps 0.1% slow receive 166 0 0.949 1:39 1587 bps 2457 bps slow send 4 0 0.005 0:01 869 bps misc control 4769 0 0.463 1:50 June 1989: uunet fast receive 3312 0 109.088 42:06 7195 bps 13792 bps fast send 560 0 4.111 1:02 10889 bps 16568 bps 0.3% slow receive 154 0 1.257 1:53 1844 bps 2494 bps slow send 6 0 0.012 0:01 1329 bps 1165 bps misc control 4167 0 0.396 1:41 July 1989: uunet fast receive 741 0 26.443 9:18 7888 bps 13664 bps fast send 117 0 0.954 0:12 12565 bps 16017 bps slow receive 25 0 0.263 0:22 1966 bps 2402 bps misc control 953 0 0.102 0:21 bpa ================================================================================ system transfer files fail M-bytes hours speed peak retry ======= ============ ====== ==== ======== ====== ===== ===== ===== January 1989: bpa fast receive 5982 0 73.066 24:15 8368 bps 13437 bps fast send 550 0 12.014 2:44 12192 bps 17186 bps slow receive 190 0 2.297 3:05 2067 bps 2499 bps slow send 22 0 0.454 0:34 2191 bps 2263 bps misc control 6764 0 0.868 2:40 February 1989: bpa fast receive 5902 0 73.180 25:17 8037 bps 13042 bps fast send 518 0 12.190 2:55 11587 bps 17260 bps slow receive 206 0 2.527 3:17 2137 bps 2490 bps slow send 30 0 0.544 0:41 2195 bps 2270 bps misc control 6666 0 0.854 2:40 March 1989: bpa fast receive 5509 0 70.681 28:25 6905 bps 13103 bps fast send 1246 0 36.633 9:35 10609 bps 17076 bps 0.1% slow receive 890 0 11.174 14:33 2131 bps 2495 bps slow send 547 0 15.830 20:13 2174 bps 2301 bps 0.1% misc control 8210 0 0.966 2:58 April 1989: bpa fast receive 6120 0 74.420 28:28 7259 bps 13208 bps fast send 2549 0 73.646 19:03 10730 bps 16847 bps 0.1% slow receive 241 0 2.783 3:46 2047 bps 2458 bps slow send 245 0 6.993 8:54 2179 bps 2211 bps misc control 9175 0 1.015 3:01 May 1989: bpa fast receive 6061 0 74.971 29:25 7076 bps 13252 bps fast send 2633 0 76.044 19:43 10704 bps 17543 bps 0.1% slow receive 747 0 9.115 12:21 2049 bps 2499 bps slow send 594 0 17.043 21:35 2192 bps 2461 bps 0.1% misc control 10047 0 1.096 3:11 June 1989: bpa fast receive 4561 0 57.710 23:36 6788 bps 13206 bps fast send 1787 0 52.122 13:48 10490 bps 17553 bps 0.1% slow receive 1383 0 16.984 22:29 2097 bps 2489 bps slow send 1221 0 35.541 44:40 2210 bps 2486 bps 0.1% misc control 8960 0 0.964 2:50 July 1989: bpa fast receive 1208 0 14.708 5:37 7253 bps 12603 bps fast send 140 0 10.263 3:14 8817 bps 17288 bps 0.1% slow receive 255 0 3.292 4:19 2110 bps 2465 bps slow send 75 0 6.941 8:48 2187 bps 2388 bps misc control 1680 0 0.208 0:40 -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
amanda@intercon.uu.net (Amanda Walker) (07/10/89)
In article <11535@orstcs.CS.ORST.EDU>, hakanson@mist.CS.ORST.EDU (Marion Hakanson) writes: > Don't sell the T1000 short -- they do go faster than 9600bps, even if > they can't match a Trailblazer+ or T2500. I stand corrected. My only experience with the T1000 is skimming over Telebit's ads :-)... -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
amanda@intercon.uu.net (Amanda Walker) (07/10/89)
In article <7102@swlabs.UUCP>, jack@swlabs.UUCP (Jack Bonn) writes: > Looks like uunet doesn't have > enough horsepower here. What are you other folks getting for throughput? We only get 800-900, but when I try to run our 3B2/300 at 19200, it chokes and dies, so I thought the problem was on our end. BTW, has anyone successfully run a TB+ on a 3B2/300 at 19200? It's the only port being used on that serial board, if that makes a difference... -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
billc@wupulm.wustl.EDU (Bill Canning) (07/11/89)
In article <240@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: >In article <3175@csccat.UUCP> jack@csccat.UUCP (Jack Hudler) writes: > >| Think about, some computer (mine) can't take >| having 9600 baud shoved down it's throat and unbatch news >| at the same time. :-) > >A quick and dirty way to keep news unbatching from dragging down uucp >throughput is to set up a shell script rnews which invokes the real >rnews niced down to 20.... News2.11 can be configured to automatically do a nice on rnews for you, and the niceness is configurable. The #define is in defs.h. This is a little more elegant solution. I hope this helps, Bill Canning billc%wupulm@wupost.wustl.EDU
dg@lakart.UUCP (David Goodenough) (07/11/89)
dlu@wobble.uucp (Doug Urner): > Sadly that is not always the case. The best I have been able to do between > wobble and uunet (both Trailblazer+'s and both running the link to the modem > at 19.2) is in the same range. The B5.00 firmware doesn't make a difference > either. I am able to get much better through put with local connections > and even down to the Bay Area, but to uunet better than 900 is a real > surprise. Any thoughts? Probably a very simply explanation (Anyone who knows more, feel free to correct this). TB family modems do DAMQAM. The DAM part stands for Dynamic Adaptive Multicarrier. Now if memory serves, there are 500+ carrier frequencies available to a TB, of which it will use at most about 400 (?). Now, suppose it has such a grody line that it can only use 200 of them. Can you say lost bandwidth? There, I knew you could. wobble.uucp is in WA, so to the Bay Area it's about 1500 miles, but maybe twice that far to VA. .... Just some food for thought .... -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
caf@omen.UUCP (Chuck Forsberg) (07/12/89)
The problem with nice'ing rnews is its disk intensive operation. Nice'ing rnews doesn't make it all that nice :-)
john@jwt.UUCP (John Temples) (07/12/89)
In article <7102@swlabs.UUCP> jack@swlabs.UUCP (Jack Bonn) writes: >This is on [uunet's] (Non ATT) 800 line. Looks like uunet doesn't have >enough horsepower here. What are you other folks getting for throughput? I've been averaging about 550-600 cps from uunet. This is in contrast to 800-850 cps from a local site. I normally call uunet about 3 AM ET on the 800 number. I tried calling this morning about 10 AM, and got 840 cps on about 90 kbytes. Perhaps uunet is swamped overnight when the rates are lower? -- John Temples -- UUCP: uunet!jwt!john or {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!jwt!john
karl@ficc.uu.net (karl lehenbauer) (07/13/89)
In article <817@omen.UUCP>, caf@omen.UUCP (Chuck Forsberg) writes: > The problem with nice'ing rnews is its disk intensive > operation. Nice'ing rnews doesn't make it all that nice :-) Yeah, I have noticed this too. If one's system is mostly disk-bound, nicing does not have a substantial effect, at least under Sys V/3. I think what is needed is a nicer-than-nice nice where really low priority tasks do not always get to execute or get their disk requests fulfilled, even when there are no other run-ready tasks. -- -- uunet!ficc!karl
rick@uunet.UU.NET (Rick Adams) (07/14/89)
Here are excerpts from todays log with wobble. The speeds seem to be reasonable. ---rick root wobble (7/13-12:50-3343) sent data 43429 bytes 35.40 secs 9814 bps root wobble (7/13-12:51-3343) sent data 64565 bytes 54.41 secs 9493 bps root wobble (7/13-12:52-3343) sent data 51317 bytes 41.81 secs 9819 bps root wobble (7/13-12:53-3343) sent data 47841 bytes 38.14 secs 10034 bps root wobble (7/13-12:53-3343) sent data 46838 bytes 37.89 secs 9889 bps root wobble (7/13-12:54-3343) sent data 51615 bytes 41.42 secs 9969 bps root wobble (7/13-12:55-3343) sent data 54405 bytes 45.01 secs 9669 bps root wobble (7/13-12:56-3343) sent data 41147 bytes 33.35 secs 9870 bps root wobble (7/13-12:56-3343) sent data 25694 bytes 19.46 secs 10562 bps root wobble (7/13-12:57-3343) sent data 46562 bytes 37.34 secs 9975 bps root wobble (7/13-12:58-3343) sent data 44832 bytes 35.56 secs 10085 bps root wobble (7/13-12:59-3343) sent data 43780 bytes 35.49 secs 9870 bps root wobble (7/13-12:59-3343) sent data 22415 bytes 17.33 secs 10347 bps root wobble (7/13-13:00-3343) sent data 30747 bytes 24.65 secs 9978 bps root wobble (7/13-13:00-3343) sent data 17034 bytes 13.43 secs 10146 bps
rick@uunet.UU.NET (Rick Adams) (07/14/89)
In article <9585@alice.UUCP>, debra@alice.UUCP (Paul De Bra) writes: > Uunet handles lots of communications simultaneously. This means it must > be under constant heavy load, implying low throughput. The limit is in > uunet and its connection to the modems, not in the modem connection. God, don't you just love unsupported guesses presented as facts? Let's try and deal with facts instead of inuendo. There are basically 3 places there could be a problem: 1) The sending system 2) the modems themselves (includes getting a lousy quality phone line) 3) The receiving system. In my (quite extensive) experience, the probabilites are about 85% receiving system, 10% modems and 5% sending system. Typically the problem is with the receiving system. E.g. just because your system supports an interface speed of 19.2 kbps, has absolutely nothing to do with its ability to receive data at that speed (DEC systems are especially bad about this as are most PCs without "smart" IO cards) A relevant fact is that uunet was under CPU powered for about 3 weeks in June. (Sequent didnt deliver the board that they promised) but was finally upgraded on July 3 to 8 processors. When compaining about problems its useless unless you work with facts. Saying "my modem throughput sucks" is useless information. Saying "my modem throughput sucks when I can 8765055 between 1am and 5am PDT from Islip, NY" can actually elicit useful information. The only thing more useless is uninformed third parties speculating on the orignal useless data and presenting their speculation as fact. (Note that its is also considered normal practise to send mail to the postmaster of the site when you are having repeated problems. There may be a real problem that they are not aware of.) --rick
macy@fmsystm.UUCP (Macy Hallock) (07/14/89)
In following all this discussion about getting better throughput on Telebit Trailblazers, I'd like to know: How can I get a simple cheap 19,200 bps serial port on my 80386 running SCO Xenix 2.3.1? The /etc/gettydef seems to allow only for operation to 9600. Do I need special hardware? I am using simple, dumb serial cards (8250). What do I need to modify in Xenix? I have an Anvil Stallion mulitport board in my other (non-news) machine and it solves the problem nicely, but what can I do on my news machine? Regards, and thanks in advance to all who reply/post. Macy Hallock fmsystm!macy@NCoast.ORG F M Systems hal!ncoast!fmsystm!macy 150 Highland Dr. 216-723-3000 ext 251 voice, office Medina, OH 44256 216-722-3053 voice, home 19:00-23:00 EDT New path under construction: uunet!aablue!fmsystm!macy (Thanks JB!)
jbayer@ispi.UUCP (Jonathan Bayer) (07/14/89)
macy@fmsystm.UUCP (Macy Hallock) writes: >In following all this discussion about getting better throughput on >Telebit Trailblazers, I'd like to know: >How can I get a simple cheap 19,200 bps serial port on my 80386 >running SCO Xenix 2.3.1? >The /etc/gettydef seems to allow only for operation to 9600. >Do I need special hardware? I am using simple, dumb serial >cards (8250). >What do I need to modify in Xenix? Find the line in /etc/gettydefs which refers to the speed EXTA. That is 19200 baud. Make the change in /etc/ttys (for logins). Make the change in your /usr/lib/uucp/Devices file (and possibly /usr/lib/uucp/Systems) for uucp. JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 500 Oakwood Ave. ...uunet!ispi!root Roselle Park, NJ 07204 (201) 245-5922 jbayer@ispi.UUCP
allbery@ncoast.ORG (Brandon S. Allbery) (07/15/89)
As quoted from <1162@intercon.UUCP> by amanda@intercon.uu.net (Amanda Walker): +--------------- | In article <11535@orstcs.CS.ORST.EDU>, hakanson@mist.CS.ORST.EDU (Marion Hakanson) writes: | > Don't sell the T1000 short -- they do go faster than 9600bps, even if | > they can't match a Trailblazer+ or T2500. | | I stand corrected. My only experience with the T1000 is skimming over | Telebit's ads :-)... +--------------- Telebit's ads round the numbers. I typically get 10.6Kbps. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser * "ncoast" regenerates again! The 5th "ncoast", coming August 1 (stay tuned) *
vipoon@kepler1.UUCP (Victor I Poon) (07/19/89)
In article <1085@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: > >Find the line in /etc/gettydefs which refers to the speed EXTA. That is >19200 baud. Make the change in /etc/ttys (for logins). Make the >change in your /usr/lib/uucp/Devices file (and possibly >/usr/lib/uucp/Systems) for uucp. Interestingly enough, I called SCO about this once and they told me that they do not really support EXTA as a baud rate. I mean to say, it's there, you can use it, but you won't get 19,200 bps throughput. Generally at 19.2k, the UART must interrupt the processor every 521us which seems to me that the driver code better be well written otherwise it won't be serviced in time. I maybe wrong on this, someone please correct me if I am. Most of the stats that I've seen people post claim to get a throughput around 11k-12k bps. I was wondering if they ever did a comparison on how much time was wasted in logging in/out, the delay for creating a new file, etc. I guess this would be a comparison between the time on the phone vs. the time involved with transmitting the file. Victor -- Victor I. Poon {acsm, lilink, polyof, sbcs}!kepler1!vipoon Kepler Financial Management, Ltd. It was the best of times, It was the worst of times, ...
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (07/20/89)
In article <4979@ficc.uu.net> karl@ficc.uu.net (karl lehenbauer) writes: >In article <817@omen.UUCP>, caf@omen.UUCP (Chuck Forsberg) writes: >> The problem with nice'ing rnews is its disk intensive >> operation. Nice'ing rnews doesn't make it all that nice :-) > A few programs that do alot of disk i/o need a sleep(1) here and there. It made my system much more usable when cnews expire was running. -- Branch Technology | zeeff@b-tech.ann-arbor.mi.us | Ann Arbor, MI
terry@sunquest.UUCP (Terry Friedrichsen) (07/25/89)
Don't forget about phone line noise, either. Error correction will slow down the effective transfer rate. Some of the phone systems here in Arizona are OLD (in Eloy and Arizona City, we still gotta give the operator our phone number when making a long-distance call :-). Terry R. Friedrichsen Disclaimer: the company doesn't read my messages, so it can't possibly know what I'm saying.
peter@stca77.stc.oz (Peter Jeremy) (07/27/89)
In article <BOB.89Jul7105344@tinman.cis.ohio-state.edu> Bob Sutterfield <bob@cis.ohio-state.edu> writes: >Or those systems could be small and slow without enough horsepower or >I/O bandwidth to shove that many characters per second through their >serial ports, no matter the baud rate setting. Some little boxes >wheeze heavily after climbing only two flights of stairs at 9600. I was a bit worried about user load affecting UUCP performance, so I wrote the following piece of code. To use it, rename uucico and uuxqt to Uucico and Uuxqt respectively. Compile the code and create two links called uucico and uuxqt. It should run setuid root. What it does is up the priority for uucico to 0 (absolute), and reduce the priority of uuxqt to 25 (absolute). It then exec()s the relevant program after resetting its uid/gid. It has been checked under Xenix/286 and System V.3. The TIMEZONE code is a kludge and can be removed if your uucico/uuxqt were written properly. /* ** increase priority of uucico (with matching reduction for uuxqt) */ #include <stdio.h> #define TIMEZONE "TZ=EST-10" extern char *strrchr(); extern int putenv(); extern unsigned short getuid(); extern unsigned short getgid(); main(argc, argv) int argc; char *argv[]; { int now; /* current nice value */ char *myname; char *name; /* program to exec */ if ((myname = strrchr(*argv, '/')) == NULL || *++myname == '\0') myname = *argv; if (*myname == '-') myname++; now = nice(0) + 20; if (strcmp(myname, "uucico") == 0 || strcmp(myname, "UUCICO") == 0) { nice(-now); name = "/usr/lib/uucp/Uucico"; } else if (strcmp(myname, "uuxqt") == 0 || strcmp(myname, "UUXQT") == 0 ) { nice(25 - now); name = "/usr/lib/uucp/Uuxqt"; } else { fprintf(stderr, "%s: Unknown program '%s'\n", myname, *argv); exit(1); } if (putenv(TIMEZONE)) { fprintf(stderr, "%s: Unable to put environment\n", myname); exit(1); } setgid(getgid()); setuid(getuid()); execv(name, argv); } -- Peter Jeremy (VK2PJ) peter@stca77.stc.oz Alcatel STC Australia ...!uunet!stca77.stc.oz!peter 41 Mandible St peter%stca77.stc.oz@uunet.UU.NET ALEXANDRIA NSW 2015
snoopy@sopwith.UUCP (Snoopy) (08/05/89)
In article <817@omen.UUCP> caf@omen.UUCP (Chuck Forsberg) writes: |The problem with nice'ing rnews is its disk intensive |operation. Nice'ing rnews doesn't make it all that nice :-) It does when the process it is competing with is even more I/O bound, like a Telebit blasting news batches at the poor tty driver. _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ qiclab!sopwith!snoopy | | |___| parsely!sopwith!snoopy | tekecs | |___| sun!nosun!illian!sopwith!snoopy |_________| "But we're only up to the fourth inning."
wcs@cbnewsh.UUCP (08/15/89)
Two years ago I did a lot of work benchmarking UUCP over the then-current generation of Telebits, over a variety of transmission conditions. I was using an HP 68020 box in New Jersey. I was able to get about 1300 char/second talking to hoptoad, John Gilmore's Sun-3 in SF; I only got about 1000 char/sec talking to Telebit's own machine, which was some sort of 386 PC. Using 19200 instead of 9600 was critical; I typically got 500-800 cps at 9600. From Ft. Collins CO to either LA or NJ I typically got about 1000 cps; transmission was a lot noisier both on AT&T and Sprint. All these numbers were uncompressed, since compression wasn't available at the time. The comment that news transmitted faster with modem compression turned off was interesting; it may be worth experimenting with combinations of news compression off and modem compression on, though that's unlikely to win. Receiving machine speed is critical; it's highly unlikely that uunet will run out of gas, since it's a large Sequent multiprocessor box. Most of the transmission is from them to you. I found my machine went a lot faster when I put /usr/spool/uucp and /usr/spool/news in the same file system, since it didn't have to copy data to hand it to rnews. Alternatively, make sure if they're in different filesystems that they're on different physical disks so you don't get spindle-thrash. Bill -- # Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs # also cloned at 201-271-4712 tarpon.att.com!wcs # ... counting stars by candle light ....