Date: Mon, 3 Jan 94 04:30:06 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #342
To: tcp-group-digest
TCP-Group Digest Mon, 3 Jan 94 Volume 93 : Issue 342
Today's Topics:
Packet repeater interface logic
What does this mean?
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Sun, 02 Jan 94 10:07:00 est
From: "Ackermann, John" <jra@lawdept.daytonoh.NCR.COM>
Subject: Packet repeater interface logic
To: "''TCP Mailing List''" <tcp-group@ucsd.edu>
I'm putting together a revised version of the interface/controller for our
full-duplex packet repeater. The goal is to directly tie the switch machine
into the repeater, without using a radio.
There are two data streams that could go the repeater transmitter -- the one
from the receiver, and the one from the switch. A simple design would
simply qualify each data stream with DCD or RTS as appropriate, and XOR them
together. This would work fine as long as the receiver didn't open up while
the switch was transmitting, or vice versa.
But if both receiver DCD and switch RTS went active at once, the two data
streams would mix and you'd get garbage. Of course, CSMA/CA should prevent
this; when the switch has the transmitter, no one else would dare transmit.
But we know that it doesn't always work this way.
The question: is it worth it in the real world to either:
a) give the switch priority (ie, when the switch is transmitting, lock out
the receiver datastream), or
b) come up with a latch that would work on a "first come, first served"
basis, giving priority to whoever grabs the transmitter first. I can see
potential race or deadly embrace problems with this, though.
Any thoughts?
73,
John AG9V
------------------------------
Date: Sun, 2 Jan 94 10:36:37 EST
From: Steve Urich <steve@zero.com>
Subject: What does this mean?
To: qualcomm.com!karn@vu-vlsi.ee.vill.edu (Phil Karn)
Phil wrote:
> NOS can return source quenches for several different reasons, but the
> most common in AX.25 operation is an unresolved ARP. When a NOS system
I've also noticed that if a NOS is low on memory it will dump
the packet and return a source quench if its a homesystem also
operating as a switch when there is too much going on at the
same time like nntp ftp to and thru it.
> So the bottom line is this: repeated source quenches from a gateway
> transmitting on an AX.25 channel are a very good indication that the
> next station on the path is down or unreachable and has been so for
> more than 15 minutes (the ARP cache timeout).
At least this code lets a user know that there is something
wrong at the other end with a returned quench.
I've been seening different problems with NOS especially JNOS
that is being used where I live. I've noticed that there are
hardly no "source quench" returns, however there are holes
in the packet switching and retransmissions that I cannot
understand. It seems that at times the JNOS goes deaf and
refuses any packets. I'm not talking about when someone is
shelled out reading and writing mail, but this is when things
are pretty busy and packets get lost. I've heard it from others
complaining about the same problem ever since thier switch
changed to JNOS. Its seems that the "source quench" code is
`NOT' compiled into the these NOSes used locally and therefore
it seems like they are loosing packets more then previous
NOSes used.
Is there a reason not to have it compiled in so it doesn't
waist bandwidth or something? It sure looks that way, also
I can't figure the reasons for the packetloss anymore because
I get no "source quench" return. This was helpful in debugging
and its making me and others think there is something wrong
with there tncs and radios now ;). Which there isn't but its
confusing when there are pockets of holes in the system without
any reference to why.
73 Steve
------------------------------
End of TCP-Group Digest V93 #342
******************************
******************************