Cooper, Stewart wrote:
> 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?
it may be that the tnc's aren't handling the ct backbone very well.
the ct backbone messages are fairly short, usually less than 80
bytes and contain a checksum character that may look like an odd
control character to the tnc. make sure that the tnc's aren't
trying to queue up too much of the backbone data for sending in
big packets. i think there are parameters you can change for
transparent mode to make it send smaller packets more often.
> 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)
i am testing a new version of telnetx that has a real windows
interface for setting up connections and routes. it needs some
more work, but should make it a bit friendlier to use.
--
David Robbins K1TTT (ex KY1H)
k1ttt@berkshire.net or robbins@berkshire.net
http://www.berkshire.net/~robbins/k1ttt.html
--
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
|