PCs and TACs


Frank J. Wancho (WANCHO@SIMTEL20.ARPA)
Fri, 11 Apr 1986 00:06 MST


BAD MSG:
speed above 300 bps with TAC input buffers defaulted to 64, and it is
ot so simple to get DCA to make a change for selected ports (it used
to take a phone call).

At one time there was some work in progress to implement one of
several protocols at the TAC level. That effort seems to have died.
We feel that such an effort such be revisited due to the proliferation
of these PCs and what currently amounts to packet/character file
transfers loading the network.

Could it be possible that the C/30 TACs currently in use might be
upgraded C/30e's? If so, then, depending on the amount of extra
memory available, it might be possible to seriously consider
implementing the basic protocols of either KERMIT, Christensen, or
maybe even X.PC at the TAC level.

In any event, we would like to see the input buffer pool on each TAC
redistributed to the *active* ports. In many cases, the default input
buffer size for each port can be easily raised to 134. With C/30e's
it may even be possible to raise that to 1,030 to accomodate the
latest variation of the Christensen protocol, without the paperwork to
make such a "simple" change request necessary. A low-overhead
Christensen transfer would then be possile at higher speeds and thus
reduce the duration of such transfers. (I intended to insert a pitch
for upgrading the TAC dialin modems to 2,400 bps, but I'm already
pushing my luck.)

Now, having said all that, are there data to back up our claim that
file transfers through TACs are becoming, if not already, a
significant factor in network loading to justify a TAC level protocol
implementation?

--Frank



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:05 GMT