Date: Mon, 8 Mar 93 04:30:11 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 #64
To: tcp-group-digest
TCP-Group Digest Mon, 8 Mar 93 Volume 93 : Issue 64
Today's Topics:
HELP: NOS/JNOS Shared Interrups.
Help with USCC Baycom Card.
hidden transmitter routing
PM NOS Question
TIPMAIL Problem and ASY buffers
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: Mon, 8 Mar 93 02:50:06 PST
From: algedi!aa6ed (aa6ed)
Subject: HELP: NOS/JNOS Shared Interrups.
To: tcp-group@ucsd.edu
I understand that there is an implementation that allows NOS/JNOS to utilize
shared interrupts. According to my search of JNOS 1.07, there doesn't seem
to be that capability. What am I missing? Does KA9Q offer this feature?
-------------------------------------------------------------
I8250.C
-------------------------------------------------------------
/* Interrupt handler for 8250 asynch chip (called from asyvec.asm) */
void
asyint(dev)
int dev;
{
struct asy *asyp;
unsigned base;
char iir;
asyp = &Asy[dev];
base = asyp->addr;
while(((iir = inportb(base+IIR)) & IIR_IP) == 0){
switch(iir & IIR_ID_MASK){
*** Text Deleted: This section receives a device number (pushed AX)
and calls the respective RX/TX service routine.
As you can see, it only seems to handle one device
per IRQ interrupt.
----------------------------------------------------------
ASYVEC.ASM
------------------------------------------------------------
; asy0vec - asynch channel 0 interrupt handler
public asy0vec
label asy0vec far
*** Text Deleted: As you can see, the last part of this service
routine pushes the device ID into AX, and then
calls the function I previously identified above.
>>>>>> mov ax,0 ; arg for service routine
push ax
call asyint
pop ax
jmp doret
------------------------------------------------------------
Am I wrong? Please help me find the proper fix. This fix will allow
the "4-COM" board found at a local store utilize interrupt sharing, which
will benifit both AT and AX machines. I desire to only use ONE interrupt
for NOS so that I can invest in other products requiring an interrupt.
Presently all my interrupts are used by Comm ports ( IRQ 4,3,7,
10,11,12,15).
I have a fix in mind, but want to see if the problem has already been solved.
Reference: STB Systems, INC "4-Com Four-Port Serial Board"
P.O. Box 850957
Richardson, Texas 75085-0957
Board supports 4 independently addressed Com Ports on either shared
or independent interrupts (IRQ 2 - 15) in any combination or
configuration. Emulates a 16550 UART in single chip, bought mine for
less than $115.00 retail.
73's
IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM;
: AA6ED Amateur Radio BBS & Packet Gateway (Phone BBS + JNOS 1.07b TCP/IP) :
LMMMMMMMMMMMMMMMMMMMMMMMMMKMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM9
: William [Bill] Bytheway : AX.25=aa6ed@aa6ed.wa.na.usa IP=[44.24.103.157] :
: 11108 SE 184th Place : Digital/BBS : (206) 271-4657 (300/1200/2400) :
: Renton, WA 98055 : UUCP/Internet : algedi!aa6ed@Data-IO.COM :
HMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<
------------------------------
Date: Sun, 7 Mar 93 21:58:02 EET
From: "Demetre Ch. Valaris - SV1UY" <dvalar@leon.nrcps.ariadne-t.gr>
Subject: Help with USCC Baycom Card.
To: nos-bbs@hydra.carleton.ca
Hello all,
Has anybody ever used a USCC Baycom 4 port card with NOS???
I cannot make it work. PLEASE HELP !!!!!!!! I am desperate.
73 Demetre SV1UY
E-mail dvalar@leon.nrcps.ariadne-t.gr
------------------------------
Date: 08 Mar 1993 12:43:48 +1000
From: CCDRW@cc.newcastle.edu.au
Subject: hidden transmitter routing
To: waltp@bingsuns.cc.binghamton.edu, tcp-group@ucsd.edu
In a message
>From: waltp@bingsuns.cc.binghamton.edu (waltp)
>Subject: RE: hidden transmitter routing
...
>
>It may be that repeaters are the best currently known way to
>avoid the hidden transmitter problem but shouldn't we question
>the effect it would have. It's pretty common here in semi-rural
>NY state for people to reach their local bbs by hopping
>along through one or even two other stations. I leave my
>system running all the time primarily so a couple of people
>can go through it to do just that. I'm happy enough to do that
>but wouldn't go to the extra expense of running a split freq repeater.
>
>CSMA is certainly problematic but it's not obvious that there
>can't be some sort of slotted protocol that would could serve.
>We do tend to have "hub" stations - bbs's, backbones nodes -
>that could provide centralized control over slots.
>What about "lone" stations in direct contact with the hub getting
>one slot per "cycle", stations in direct contact serving
>a two hop station getting two (or maybe 3 so that the two
>hop station could transmit to it?) ...
>
>Any scheme might get to be fairly exotic - maybe including
>periods of data exchange alternating with periods of control
>exchange - letting stations join and leave. ???
>
>It might seem to be too complex or the loss of bandwidth
>to control exchanges seem to high but
>it could be quite efficient at low loads and at higher loads
>almost anything might be better than the
>throughput collapse we see now - and
>it would preserve the friendly nature of packet radio.
>
>I haven't thought about this a lot yet (obviously).
>
>I've got my flack jacket on - please don't disappoint me.
>
>Walt
>
Right On!
I've been thinking this over a bit following from Warren's paper and the general
discussion (which I've been having trouble keeping up with lately, too much
WORK to do here). I like the slot idea, it's similar to Warren's Ring, but
perhaps a better name. The other name I had for this system is a
'wireless mux' (a play on 'wired OR' logic) but describing an analogy I find
useful. Asynchronous Statistical Muxes have been arround for a while!
I know 'cluster controllers' would help some of our problems but we are by
nature an ad-hoc group and have an emphasis on low cost. Central stuff has to be
funded, maintained, upgraded etc. Where a system exists now because of some
service it provides it is easier to get enhancements etc. so adding a little
work to the machine to act as default controller in a group where distributed
control is part of the protocol is easy. They will also likely be the station
with the most traffic, thus having the information avail. to make decisions
about, say, size of group, delays to use, routing etc. I'm not ruling out
existing repeaters, but suggesting they will need some processing power, rather
than just interconnected TNC's. This means BBS's, gateways etc.
As a station comes up it listens for a neighbour and identifies the curent
number of slots, and which one the neighbour's using, Places the call (straight
after his next transmission?) him requesting a slot, and enters the group.
We may be in a few groups (say we're hidden from the 'Group controller', but
can hear stations from them), so we need to add a 'group id' and some way of
negotiating slots/ co-ordinating them between groups. Also I guess we need to
avoid some of the entry/exit overheads and maintain a slot without data for
some few cycles.
On variable power we can try for the a station in the main ring, but throttle
back till only one neighbour can hear us if thats not possible (having due
regard for error rates and forward error correction as appropriate). thus we
can use a slot used by someone else in the main group and the neighbour can get
our traffic across in their slot.
I may be loosing the plot here, this looks like a cross between,
rings/cells/muxes and guesswork! but now I started typing I wanted to get
thoughts on paper.
While I'm here I'm all for variable length fields, with perhaps a default of
say 8 chars for source/dest callsigns we implement first. With no shifting etc,
just plain ASCII/whatever the new universal code is, we can be sure that wont be
much of a problem for 'Regulatory Authorities'.
I agree too, its probably time we put some basic definitions/guidelines/rules in
writing so we dont confuse each other with each different naming of things, so
I'll try to do that tonight (off line! rather than thinking with my fingers).
P.S. we all seem to want to see the death of AX25, so direct the flames that
direction :-)
Dave VK2XPX, sysop VK2RAP.
Internet | ccdrw@cc.newcastle.edu.au
Amprnet | vk2xpx@vk2xpx.ampr.org
------------------------------
Date: Sun, 7 Mar 93 17:58:56 EST
From: Rolfe Tessem <w3vh!rolfe@uunet.UU.NET>
Subject: PM NOS Question
To: tcp-group@ucsd.edu
A number of people have asked me to help them get SLIP working on
PMNOS, and I seem to be having some difficulty :-). The use envisioned
involves dialing a PSI terminal server for Internet access; after
successfully logging on and issuing a "SLIP" command, the server hands
out a unique IP address. The user is supposed to assume this address for
the remainder of the session.
I've done this in a number of Unix SLIPs and IBM's OS/2 SLIP by:
1) issuing an ifconfig command to configure the SLIP interface to the
IP address handed out by the SLIP server. In PMNOS, I believe this
would be: ifconfig sl0 ipaddress [136.161.128.205] (for example).
2) issuing a route add default for that interface. Again, in PMNOS,
this would seem to be simply: route add default sl0.
Doing this in PMNOS (after using tip to establish the connection and
get the IP address) results in no bits hitting the modem. The MTU is
set at 1500, which is what the terminal server wants. (I'm not sure if
VJ compression is on or off or even included in PMNOS, but it should
be off for this application -- is there a switch for this?)
What am I doing wrong?
For extra credit, is there any way to semi or fully automate the
dialup process though dialer scripts? I can't seem to find any
documentation on this at all, although something seems to be in there
:-).
Thanks,
Rolfe
---
Rolfe Tessem Lucky Duck Productions
rolfe@w3vh.UUCP 96 Morton Street, NYC, NY 10014
rolfe@ldp.com <NeXTMail OK> 212-463-0029
------------------------------
Date: Sun, 7 Mar 93 23:22:30 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: TIPMAIL Problem and ASY buffers
To: nos-bbs@hydra.carleton.CA
IMPORTANT TIPMAIL SERVERS READ!!!
Last week I sent in a fix for a memory crashing problem with tipmail
and constant stream outputs, like reading a long message or ascii
downloading a file. I did this in a hurry and although it works I
was not happy with it since it only addressed the one problem and
was not really done in the right place. Since then I have done some
more research and come up with a better solution, but first some
background...
When data is sent OUT over a serial tipmail connect, either via a
modem or directly connected terminal it goes thru a number of layers
in NOS. Here is a quick description of those layers from a 'tprintf'
in the BBS to the serial line.
tprintf >> MBUF >> MBUF >> asy_send >> enqueued >> 8250 >> serial
loop created received in tipmail ASY Q interrupt out
mailbox 2048 max in tipmail V
75,000 V
Chars. and growing!
This is a rather simplified flowchart. The important things to see here
are that the MBUF created has a maximum size of 2048 set by LOCSFLOW in
usock.h. In DOES block BUT, and here is the catch, it will NEVER block
because the bucket is being emptied as fast as it is being filled regardless
of the final serial speed!! The ASY queue grows with NO limit (shown above
with a series of V's growing down) and empties the previous MBUF queue
immediately. If the original 'tprintf' loop above is reading a message
that is 75K long and the final serial line baudrate is 2400 Baud, nearly
the entire message will end up in an asyinc queue within seconds. In
most cases this will severely rob NOS of needed memory and it may cause
it to crash.
Think of it this way - you hang a bucket in your basement with a high
water sensor in it, but the bucket has a rather large hole in it. The
water is turned on, flowing into the bucket, but it goes out as fast
as it comes in. The basement floods and the high water cutoff never
knows it. The bucket is the first mbuf, the high water cutoff is the
mbuf's high water mark and of course the basement is the ASY queue.
Now the basement has a sump pump but it can not keep up with the flow.
The basement gradually fills to disaster. The sump pump is the serial
output data flow.
Anyhow my answer was to create a new asy_send function called
asy_send_wait. This function waits (blocks) for the ASY queue to empty
on each enqueue. The biggest memory hit is the 2048 bytes transferred
from the MBUF to the ASY queue. I did not try it but I suspect you could
even lower the LOCSFLOW size and reduce the hit even further in really
marginal situations. The old asy_send function remains. The new
asy_send_wait function is ONLY called in tipmail.c EVERY asy_send
in that file is changed to asy_send_wait.
I did not change any other asy_send call in NOS to this function as
in some cases it may not be desireable to block. Other occurences
of asy_send should be looked at. Anytime you dump a large amount of
data over the serial port or if many processes are dumping to the
serial port and that port is slow this could happen. Perhaps this
could be implemented in the asy_send routine with, instead of a total
empty wait, as I have in asy_send_wait, some higher limit. I truely
believe that some limit must be put on the ASY output queue buffer
size in order to improve the reliability of NOS.
Here is the code added to the end of I8250.C with the protype added
to ASY.H under the i8250.c section. Also change ALL occurences of asy_send
in TIPMAIL.C to asy_send_wait.
/* Send a message on the specified serial line
Wait for queue to empty - for slow serial
lines where data flow control is desired
Eliminates large queue - I.E. memory hogging */
int
asy_send_wait(dev,bp)
int dev;
struct mbuf *bp;
{
if(dev < 0 || dev >= ASY_MAX)
return -1;
enqueue(&Asy[dev].sndq,bp);
while (len_p((struct mbuf*)&Asy[dev].sndq)){
pwait(NULL);
}
return 0;
}
ANYONE using tipmail who wants a reliable system should implement
this!! Please give me your comments on it's use or input on any
improvements. JOHAN: this should go into future code.
LATE NOTE -
As a test I implemented the above code for ALL asy_send calls. It seems
to have little effect on a busy two asy port system. This would be
expected as the KISS baudrate of 9600 baud certainly unloads the buffer
fast enough. The asy buffer would grow though if interrupts were off for
a period or if flow control was implemented and shutdown for an extended
time. It would eliminated the eating of large chunks of memory in these
cases. It is worth a try if you are having memory problems.
Doug
------------------------------
End of TCP-Group Digest V93 #64
******************************
******************************