[ct-user] CT, Ethernet, Packet, etc

Cooper, Stewart Cooper, Stewart" <coopersg@odl.co.uk
Wed, 10 Sep 1997 13:48:26 0000

For information, in response to our our own group's (GM7V) 
requirements, and to some questions on this reflector:
I have just run a test with 5 PCs running CT 9.27.
PC #1 - Windows 95 486/33 running TELNETX, connected via internet to 
WU3V, feeding spots to network as a virtual TNC at 1200 Bd by null 
modem cable ('CT network cable') connected to...
PC #2 - DOS 386/16 with 4mb RAM running CT with a KPC4 TNC configured 
to run transparent mode 'radio' network on 144 MHz to a...
PC #3 - DOS 386/16 with 6mb RAM running CT with a KPC3 TNC configured 
to run transparent mode 'radio' network. This PC also runs NETTSR1 
and a 3COM network card and is connected using 'thin-ethernet' (ie 
UR43) to..
PC #4 - DOS 386/16 with 4 mb RAM running CT and the same NETTSR1 and 
a Trust network (NE2000) card. This PC also runs COMTSR1 and is 
connected via null modem cable to..
PC #5 - Compaq old 386/20 portable with 2mb RAM running CONGEST.
I had no real problems, other than with my own stupidity 
occasionally. All works well up to around 400 QSOs per hour (one way 
only - ie all generated at one end of the network) with the 
occasional packet spots from the internet (one every 30 secs or so). 
As to whether 400 Qs an hour is enough, I wouldn't like to say!! At 
least during busy times, the QSOs tend to be queued up, rather than 
dropped, but there must be a buffer which will fill somewhere and 
eventually drop some QSOs. I had one problem with the packet network 
connection - I got an 'Input buffer full on COM1' error. This 
occurred randomly and cleared when I opened and closed the TNC 
window. The device is not configured as a TNC at the time (as 
network).  Does anyone know what buffer this is, and why it 
occasionally fills? If the data is in the buffer on that particular 
PC, then why isn't it writing it to the log?
The way I see it is that if a Q is missed in multi-multi, it's not 
the end of the world as a final merge will sort it out. If a vital 
spot mult is missed that could be more critical. I think 9600 bd 
packet link would be better (and more expensive). TELNETX is 
excellent, although a little clunky to use, and the ethernet 
networking, of course, is very fast.
Stewart GM4AFF (GM7V)

Submissions:              ct-user@ve7tcp.ampr.org
Administrative requests:  ct-user-REQUEST@ve7tcp.ampr.org
WWW:                      http://www.ve7tcp.ampr.org/Software/ct
Questions:                owner-ct-user@ve7tcp.ampr.org