Date: Wed, 28 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 #111
To: tcp-group-digest
TCP-Group Digest Wed, 28 Apr 93 Volume 93 : Issue 111
Today's Topics:
LA/Chicago wormhole info needed.
NE2000 & Desqview
Reply abt DV and NOS
Thoughts about alloc, bugs and RSPF.
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: Tue, 27 Apr 93 21:26:16 UTC
From: wb9mjn@wsu.n8fow.ampr.org
Subject: LA/Chicago wormhole info needed.
To: tcp-group@ucsd.edu
Hi, I helped set up the LA / Chicago wormhole, building the Chicago side
RF link. At present, the RF link is a 1.2 gig 9600 baud radio channel, using
No-Tune transverters, and DVR2-2s. Altho we started with back to back
NETROM TNC 2 nodes, the configuration has changed. At present the WORM
node (wb6wey-7) is running G8BPQ code, and has ports on the LA 6 meter
backbone (4800 / K9NG), 2 meter Simi Valley Lan Channel, and a port for
each of the three wormhole links (Chicago (Naperville, IL), St Louis, and
New Jersey (Secaucus)).
Recently, the port to Naperville , IL was converted to a KISS link, over
the commercial wire. The TNC2 NETROM at Naperville could not deal with
the additional node load of the new NJ links. It would operate very
slugisly, and stop working for many minutes at a time. So, we converted
the TNC2 to a KISS TNC, and WB6WEY had its ports upgraded to use 16550
SIO chips. The Simi Valley, CA LAN port, and 6 meter / 4800 baud port
were switched to KISS at WORM:WB6WEY-7, shortly after the improvement
gained by switching to KISS was apparent. This change gives a few more
years of service to our TNC2 based hardware in the Naperville office of
the wormhole sponsor. We converted the TNC2 to 19.2 Kb on the Rs232 port,
which goes thru the local statistical multiplexer, a 56 KB data wire, and
the sponsors headquarters site statistical multiplexer, to get to the
WORM node. Thru this arrangement, WORM can send packets right to the
ILNAP:K9VXW-1 PacketTEN node, over 1.2 Ghz, at 9600 baud in Naperville,
here.
We are using 1.2 Ghz because of the noisey office enviorment, and because
440 is used at K9VXW-1 site already. Using 440 would create a hidden
station situation, and retard thruput. I beleive this is how the St Louis
link is done , however, on 440/9600 with Kantronics D4-10s. The hidden
station problem has been noted howerver, and they live with it.
An added advantage to the KISS changeover, is that someday with either
newer G8BPQ or NOS software on the WORM site, we will be able to send
IP packets right from K9VXW-1 to WB6WEY-7, without the need to gateway
thru NETROM.
73, Don.
wb9mjn@wb9mjn.ampr.org
wb9mjn%wb9mjn.ampr.org@wb9uus.bradley.edu
WB9MJN@N9HSI.IL.USA.NA
------------------------------
Date: 25 Apr 1993 20:15:28 +0000 (GMT)
From: pa3cpl@pa3cpl.ampr.org
Subject: NE2000 & Desqview
To: tcp-group%pa2aga@pi8nos.UCSD.EDU
I have a problem working with desqview and TCP/IP.
The setup is as follows:
486DX-50, 4Mb. NE2000 Lan-card. Loadhi: LSL, NE2000 -w (from the clarkson
drivers.zip) and IPXDPI (an ethernet driver)
start desqview.
Open tcp/ip window (NET from pe1chl), attach packet on same INT as NE2000. Runs
OK with ping to sys2.pa3cpl, abt. 98% ping reply.
As soon as I open another DV-window, ping-reply rates drops dramatically
to abt. 15-20% !!!
I have to start the NE2000 driver with the -w option, otherwise the systems
hangs within seconds. But now the driver drops all the packets!
However, if I use a ordinary novell-lite client-server action (in a third
window) transfer-rate is still very high.
So why does the NE2000 driver drops all the packets???????
pse answers to pa3cpl@df0od.et-inf.fho-emden.de or in tcp-digest
73, aart pa3cpl
--------------------------------------------------------
| Aart Wedemeijer Groningen PA3CPL [44.137.12.13] |
| AX25: @PI8AWT SMTP: PI8ESK/PI8NOS/PI8GRO/PI8YRC |
| PACSAT: AO16 |
--------------------------------------------------------
PLEASE reply to the list, NOT to the From: address
because this mail is sent through a one-way gateway!
------------------------------
Date: Tue, 27 Apr 1993 22:49:29 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Reply abt DV and NOS
To: tcp-group@ucsd.edu
This is for PA3CPL.
Your problem is not specifically related to NOS, but to what happens when
you load a driver into UMB and then start DESQview. Your system is doing
a lot of time consuming work to create the illusion that UMB memory exists
in the first addressable megabyte. Under raw DOS, this is not a problem,
but it is under DESQview.
There will always be some performance penalty. DESQview does offer the
opportunity to minimize this with the "Optimize Communications" setting
in DVSETUP, and an important undocumented feature of this field is that
you can manually insert the number of an IRQ to optimize instead of the
ordinary "Y" or "N" option. For example, if your Ethernet card sits on
IRQ5, you can insert a "5" into the "Optimize Communications" field, and
this will let DV operate somewhat better.
You should also test without loading IPXDPI. When multiple protocol
layers are installed on a packet driver, this can result in performance
problems, depending upon how the drivers are written.
You also don't give enough ifmoration to look at your problem in detail.
For example, are you using QEMM? If so, are you using the "ROM" parameter?
Where is the Ethernet card mapped in address space? What sort of video
system do you have?
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Tue, 27 Apr 1993 22:04:04 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Thoughts about alloc, bugs and RSPF.
To: d8lars@dtek.chalmers.se, tcp-group@ucsd.edu
What a depressing message! I didn't even know that there were that many
bugs left in NOS. :-)
Let me respond to the RSPF issues first. The RSPF code I have been
running for some time does not crash. There was a lot of cleaning up
of memory allocation and pointer errors in RSPF by a number of people,
especially by me and by Walt Corey (kz1f@legent.com). As far as I am
aware, the bug that you caught does not actually trip off, although it
ought to be fixed.
The central problem of RSPF, about which there was an extensive series
of messages some months ago involving me, Fred Goldtein (goldstein@
carafe.tay2.enet.dec.com), and Anders Klemets (klemets@scis.se), is
that NOS provides no opportunity to test a route without using it. It
is not desirable that routes which are in the process of being tested
by RSPF be used for anything else. NOS provides no method by which to
do this, except to swap a test route onto the IP routing table, send
the test ping, wait for the test ping to be sent while somehow stopping
other frames from using that route, and then swapping the original route
back onto the table. Then the RSPF code will be responsible for keeping
track of which test route was responsible for the successful ping, and
so on. When RSPF learns of multiple routes to the same host and must
choose between them, this can become inordinately complicated. To make
matters worse, it seems important that RSPF should be able to route
across any type of interface which can carry IP frames, which precludes
binding RSPF too heavily to non-IP protocols such as ARP (which does not
exist on all such interfaces).
The issue about one way routes is related to this larger problem, but
is somewhat easier to solve. I suggested and Anders agreed that an easy
way out would be to keep a record of successful responses to ping attempts
with one-way routes, and to never add a route to the IP routing table
unless it was at least working at one time. This allows distinguishing
between a route that was good and has now gone bad due to propgation or
similar cause as opposed to a route that is bad and has always been bad.
The current implementation sticks one-way routes onto the table and keeps
rolling them through the suspect->bad->suspect->bad cycle. At least this
would be stopped, since the routes would be tested upon being newly
acquired and would then be disposed of immediately if they had never been
good. Note that this is out of compliance with the specification, but I
don't think there is any harm in it.
The issue of multiport routing, which you say you fixed, is dependent upon
solving the first problem of virtualizing the routing table for test routes.
Anders originally put in a rather vicious kludge, which was to flag as
"manual" any route acquired by RSPF which appears on a different interface
than would be consistent with the current routing table when the RSPF route
is acquired. This leads to extremely bad consequences, to the point that
RSPF becomes non-functional (actually disabling itself, really) when used
on a multiport router. The problem is that simply removing Anders' kludge
fixes this problem and creates others. In particular, RSPF will tend to
thrash the routing table back and forth as updates are recived, allowing
test routes which will prove to be no good to be substituted for real routes
that are actually working. It is relatively easy to path this up so that
RSPF will work for multiport routers where no false information is received,
or where the routing topology is static. However, there isn't any point to
RSPF at all when these conditions obtain. Netrom is a good example of a
routing scheme that is subject to similar limitations in practice, and we
all know from experience what happens when you try to connect to a node
several hops away in a moderately densely populated netrom network. A real
fix to the multiport routing problem requires solving the test route problem.
On a different subject, I think it is the intention to concatenate the
last free block in heap with any newly acquired memory from core when
morecore() is executed. This is a common condition, and trying to save the
time of another search through heap at the expense of this efficiency will
likely result in excessive demand for memory from core. NOS very rarely
requests large blocks of memory, generally 1K or less, usually far less.
This may be why "mem free" usually shows a lot of 16-byte blocks hanging
free in low heap. I may not have understood you on this issue, as I read
through your message rather quickly.
You are right about the semantics to realloc(), but K&R also says (and
ANSI explcitly requires) that calling realloc() for an amount of memory
smaller than the existing allocation must always succeed. The kludge
method in NOS for doing a realloc() cannot guarantee this, so there is
always going to be some degree of incompatibility until someone chooses
to attempt the nightmare exercise of coding a real realloc(). Calling
realloc(), by the way, is done by some of the library functions, depending
upon the compiler and version. For example, the stat() function in Borland
C++ 3.1 calls realloc(), while the one in Borland C++ does not. This led to
crashes in a lot of places, especially the POP servers, until fixed.
When I have to chance to read through your message more carefully, I'll see
if I need to retract anything. :-)
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
End of TCP-Group Digest V93 #111
******************************
******************************