Date: Tue, 6 Apr 93 04:30:02 PDT
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 #89
To: tcp-group-digest
TCP-Group Digest Tue, 6 Apr 93 Volume 93 : Issue 89
Today's Topics:
Bit-Regenerator
Fixed Source
It ain't so
Say it ain't so... (2 msgs)
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, 04 Apr 93 18:24:29 MST
From: w6swe@tapr.org (Bob Nielsen)
Subject: Bit-Regenerator
To: Jack Snodgrass <kf5mg@vnet.IBM.COM>
Jack Snodgrass <noao!kf5mg@vnet.IBM.COM> writes:
> I'd like to set up a TNC with a Bit-Regenerator. Someone suggested that
> I look at using a TAPR DCD board and connect up the TX<->DX lines. Anyone
> know if that will work. Is there a standard circuit someplace? I'll
> probably start with a TNC-2 clone at 1200b. We still don't have any
> > 1200b activity in the area yet. If we do use G3RUH modems in a TNC-2,
> how do you set that up as a bit regenerator?
> Last question... what about the Firmware in the TNC? What are my
> options. The setup will be running Full-Duplex. Any chance we can use
> a TheNet X1G EPROM? I'd like to be able to have a PC connected to the
> TNC, but not be involved in the Bit-Regeneration process. But I'd
> like to be able to have the PC use the TNC. That might be stretching it
> a bit. Any info or ideas would be appreciated.
With the TAPR 9600 modem and an optional set of parts for the bit
regenerator, you get all of the above. It shouldn't matter what firmware
you use.
Bob
-----
Bob Nielsen W6SWE Internet: w6swe@tapr.org
Tucson, Arizona ax.25: w6swe@kc7cg.az.usa.na
------------------------------
Date: Mon, 5 Apr 93 10:09:07 EDT
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: Fixed Source
To: nos-bbs@hydra.carleton.CA
I am placing at UCSD incoming jnos08df.zip a set of jnos108d sources
with MOST all prototype problems fixed. Also other nagging errors that
have been around awhile in the source.
I HOPE that Johan will use this source in the future and go on from here.
I will be VERY disapointed if I see these errors show back up again in a
future release of JNOS.
Since the code size changed (in some cases quite a bit) with the fixes
I suspect that some problems may be fixed. I would be interested to
hear if those who had crash problems see any improvement. I do not here, as
my system has generally been very stable. I just did not like to see these
errors. PLEASE leave -w-pro out of the compile options in the future and
fix the prototype errors before they get into distribution. As you know
this is a big peave with me. In making these corrections I did catch a
number of improper calls or improper number of parameters to a call.
Also I found quite afew incorrect assignments and equality checks that
were either always false or true.
I did not fix all prototype errors. Some still exist in the drivers. Those
that I do not use. If you find something bad let me know and I will correct
it. or if you do pass it onto Johan.
The source also includes the .asm files and makefile parameters for a
386 compile. The makefile also has the .h dependencies removed and
.autodepend inserted at the beginning. Anyone who needs those can just
use the old makefile and take the 386 compile option lines from this one.
Here is the read.me that is in the source zip...
Those not corrected are in some drivers - in particuliar the twin drivers.
Also other nagging errors have been corrected.
A compile should show NO errors unless you are using a module I was not
when I went over this.
Also -
- DOS 6.0 support added in MAIN
- ASM's are 386 compliant
- Makefile has 386 compile option
- Makefile uses strictly autodepend - no .h dependecies required - works
good for borland c 3.1 - This makefile should be included as an option
for those using BC!! It is much more reliable and less subject to problems.
- Ifdef's added on modules - some may still be missing - decreases compile
time significantly when that module is not defined
- Some other minor fixes.
I am CCing this to Johan against his desires to make sure he has it before
reading a digest. I could not get to wg7j to leave the source. I will try
later - it will be in his incoming if I am successful.
Doug
------------------------------
Date: Mon, 5 Apr 93 22:03:13 EDT
From: Mike Gallaher <mg@bds.bds.com>
Subject: It ain't so
To: tcp-group.;@bds.bds.com
As I had hoped, my question of "why aren't ibufs used?" is silly.
It turns out that I WAS LOOKING IN THE WRONG VERSION OF mbuf.c.
(RCS is so comfortable you can forget you're wearing it.)
alloc_mbuf does indeed check istate, and uses Intq, in JNOS/pa0gri/etc.
Now, if only this were April 1...
mg
------------------------------
Date: Mon, 5 Apr 93 15:14:40 EDT
From: Mike Gallaher <mg@bds.bds.com>
Subject: Say it ain't so...
To: tcp-group.;@bds.bds.com
In JNOS, I noticed that the ibuf (interrupt mbuf pool -- the list that
is controlled by 'mem ibufsize' and 'mem nibufs') is maintained
faithfully. refiq gets called frequently, and allocates the mbufs and
places them in Intq.
But nothing outside of that code ever does anything to Intq. It's not
mentioned anywhere else. Even in the device driver interrupt
handlers, which would be the prime candidate for using it.
So, I tried setting nibufs to zero. My ethernet interface couldn't
receive any packets. But the packet driver never touches Intq. Hmm.
Since ka9q doesn't have Intq, and neither does it have this problem, I
looked at what it does. I found that, very early in main, it
allocates a bunch of blocks of memory and then frees them. The
comment says that it does this to ensure there is memory on the heap
so that interrupt handlers can successfully allocate some.
When I put that code into my version, my Ethernet interface worked
fine, even with nibufs set to zero.
Which suggests that the only effect that setting nibufs nonzero has is
that it places memory in the heap as a side effect of allocating all
those ibufs, and that all the memory allocated to the ibufs just goes
to waste because nobody ever does anything with them.
So all this time we've been sacrificing memory to a god that nobody
understands.
Please, somebody tell me that I'm wrong.
mg
------------------------------
Date: Mon, 5 Apr 1993 20:18:49 -0500
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: Say it ain't so...
To: tcp-group@ucsd.edu
I know how it used to work: If you call for a mbuf with interrupts
disabled (read: from an interrupt service routine), you either got
(1) NULL, or (2) a mbuf taken from the interuupt buffer queue.
Calling malloc() and friends is(was) not allowed from an interrupt
routine (because: 1) malloc can search with interrups enabled, 2)
may need to call dos to allocate more memory).
The device interrupt handlers did not touch the Intq, only alloc_mbuf
did. I don't know if/how/when this changed. The queue was created to
decrease interrupts-off processing time (faster to remove a element from
a linked list than to search a long list of memory for a suitably sized
chunk).
If you are not running any device that calls for mbufs (packet buffers)
with interrupts off (eg imbeded serial port driver), then forget ibufs.
milton
------------------------------
End of TCP-Group Digest V93 #89
******************************
******************************