🚀 go-pugleaf

Hi. Netters.

I posted an article about a throughput problem I was having.
I would like to report that the problem has been SOLVED somehow.

BACKGROUND: My uunet connection is through a Sun3, SunOS4.0.3, Taylor
UUCP 1.03, and a Trailblazer. We poll uunet from Tokyo, Japan via
international telephone line.  We have a tiny amount of mail traffic,
and much larger news traffic.  However, the amount of news is not big;
we only get news.*, gnu.* and a few comp.*.* newsgroups of our choice.

The througput problems were:

	- the throughput were on the average 500 chars/sec.

	- Sometimes it dropped somewhere around 200-300 CPS and
          connection time was rather long.

	- It was rare that my connection attained 1K CPS despite the
          usage of TB with built-in uucp protocol support. 

	- the througput changed from one connection to the other, and
	  puzzled me if there was any connection to the time of day,
          or the day of the week, and other factors.

	- Our another connection to a local Tokyo site via telephone 
          was more or less consistently good.

Even if I allow for the sometimes poor quality of telpehone call to
USA from Japan, the rate was too dismaying.
 
Well, with the help of Eric Ziegast at uunet, I have found the major
cause of problems and found that the throughput is now MUCH better.

In so doing, I needed to check the setting of TB registers carefully. 

At my site, the TB was set up by somebody else long time ago, even
before the news feed was requested from UUNET. So I had little clue
what can be wrong with it.  I used An? TB command to echo the setting
of registers. I just embedded it to the chat script and see the output
from the modem. I think you can use "uucico -x4 ..." or something like
similar to have the uucico package to echo the dialog between uucico
and modem. This is how I captured the output from TB. (Taylor UUCP
does not record the output from modem. So, I recorded the output using
Sun's stock uucico package.)

Here is the output from TB modem.

#> S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=003 S07=040 S08=002
#> S09=006 S10=007 S11=070 S12=050 S45=000 S47=004 S48=000 S49=000 S50=000
#> S51=005 S52=002 S53=003 S54=003 S55=000 S56=017 S57=019 S58=000 S59=000
#> S60=000 S61=045 S62=003 S63=001 S64=000 S65=000 S66=001 S67=000 S68=255
#> S90=000 S91=000 S92=000 S95=000 S100=000 S101=000 S102=000 S104=000
#> S110=001 S111=030 S112=001 S121=000 S150=000 S151=004 S152=001 S153=001
#> S154=000 S155=000 S160=010 S161=020 S162=002 S163=003 S164=007
#

Now from studying this output, we have found two problems.

(1) The LZ compression feature of the TB modem was ON. (S110 was NOT 0.)

    Since the major portion of our traffic is batch news which is
ALREADY compressed, the LZ compression done by two talking TBs is not
useful. Not only that, it may slow down the transmission as much as
30%. (I probably overlooked this bit somehow when we started to obtain
news feed.)

   Solution: Turn off the compression feature.  Send ATS110=0 to modem.
	
(2) PEP feature was not used all the time! (S50 was 0).

	My setting of the TB register showed that the connection to
UUCP may not use PEP feature all the time.  

    Solution: Sending ATS50=255 will tell TB to use PEP every time.

(The second problem was documented in the doc I used for installing
Bnews. I am sure the initially it was set correctly. I have no idea
what programs changed the setting. But, come to think of it, the same
modem is used by someone else to log into a commercial BBS or two,
they may have changed it inadvertedly.)

===== CHANGES ======

So, I made sure that the two registers (S110 and S50) are set
accordingly in the chat script when the connection is made.

This is the new entry of dail file for Taylor UUCP.

dialer	trailblazer

chat 	"" \d\d\d\d\dATS95=0\r "" \d\d\d\d\dATS50=255\r\d\d\d\d\dATS110=0\r "" \d\d\d\d\d\dATX0\r "" \d\d\d\d\dATX0\r OK \d\d\d\dAtn?\r\d OK \d\d\d\d\d\d\d\dATDT\D\r CONNECT ""

If you use Sun's stock&T UUCP, you need edit L.sys, I believe.

======= Improved result so far ========

The results have been good so far.  Now the trasnfer of large files
(>10K) seems to have CPS somewhere between 400 and 1190(!) and this is
much better than before.  (Before, sometimes it was as low as 280
CPS.) Since there seems to be genuinely bad telephone connection, I
can't complain about occasional 400 CPS.

======= Morale of the story. ========

I urge all of the news administrators to check the modem parameter
setting when you suspect throughput problem. You may never know if
some other programs/users/power-line-problem may have changed the
setting of your modem without warning. I myself was stunned to find
S50=0 in the modem output.

I should have done this before posting my earlier article. 

======= My future tasks =======

Now I can pay more attention to 

- when I should receive the news batch to cut down on the
  telephone bill. Telephone companies have a nighttime rate which is
  very attractive. Before, I really couldn't bother since the
  througput rate changed so much from one connection to the other and
  usually to worse, I really can't say that the night time connection
  would be better.

- Since taylyr UUCP supports call grading, and UUNET's UUCP also does,
  I may want to pass the news traffic during night time here with the
  LZ compression of TB disabled, and then send smaller mail files
  during the other time of the day with the LZ compression of TB
  ENABLED. I am studying Taylor UUCP doc to do this.

I thank Eric at UUNET for checking to see if uunet machines detected
something extraordinary with my connection (and they didn't except for
rather low throughput rate.) It was TB setting after all.