[news.sysadmin] How to speed up uucp with Telebits

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 ....