Date: Fri, 30 Apr 93 04:30:16 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 #113
To: tcp-group-digest
TCP-Group Digest Fri, 30 Apr 93 Volume 93 : Issue 113
Today's Topics:
Memory Allocation Size
Morecore Allocation Size
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: Thu, 29 Apr 1993 09:57:46 -0500 (CDT)
From: S. R. Sampson <ssampson@sabea-oc.af.mil>
Subject: Memory Allocation Size
To: TCP-Group@UCSD.Edu
Oops, I timed the time it takes for size 8 blocks, and it was faster than
size 16. Hmm, sounds fishy. Here's the correction. By the way, I said
modulo 16 rather than modulo 8 (ABLKSIZE) because the malloc() routine
asks for 2 blocks minimum.
/*
* sbrk_tst.c
*
* This program times the sbrk() call given various allocation sizes
*/
#include <stdio.h>
#include <stdlib.h>
#include <alloc.h>
#include <bios.h>
void
main(int argc, char **argv)
{
unsigned long i, core, sets;
int size;
long start, end;
float seconds;
if (argc != 2) {
fprintf(stderr, "Usage: sbrk_tst <alloc size>\n");
exit(1);
}
size = atoi(argv[1]);
core = farcoreleft();
sets = core / (unsigned long) size;
start = biostime(0, 0L);
for (i = 0L; i < sets; i++)
sbrk((int)size);
end = biostime(0, 0L);
seconds = (float)(end - start) * .055F;
printf("%lu bytes allocated in %d blocks, takes %.3f seconds\n",
core, size, seconds);
}
---
Steve N5OWK
------------------------------
Date: Thu, 29 Apr 1993 09:19:54 -0500 (CDT)
From: S. R. Sampson <ssampson@sabea-oc.af.mil>
Subject: Morecore Allocation Size
To: TCP-Group@UCSD.Edu
The recent comments about the allocation routines got me interested in
seeing what was going on. In comparing the K&R stuff I find that the
biggest difference is the modulo size of morecore(). K&R use modulo
128 (NALLOC) and NOS uses modulo 16 (ABLKSIZE). Their comment was that
since "asking the system for memory is an expensive operation" was the
justification for the 128 size. I decided to find out what the difference
was with a test. The result was that the modulo 16 was about 5 times
slower than modulo 128 at 8 MHz (No difference at 66 MHz). This wasn't very
scientific, I just used biostime() which probably could use better resolution.
But the bottom line was that I couldn't see why modulo 16 was being used
anyway. I've been running my JNOS with 128 the last day and it only runs an
"nrs" interface, but nothing buggy happens. What was the reason for the finer
allocation resolution in morecore()?
/*
* sbrk_tst.c
*
* This program times the sbrk() call given various allocation sizes
*/
#include <stdio.h>
#include <stdlib.h>
#include <alloc.h>
#include <bios.h>
void
main(int argc, char **argv)
{
register int i;
unsigned long core;
unsigned int size, sets;
long start, end;
float seconds;
if (argc != 2) {
fprintf(stderr, "Usage: sbrk_tst <alloc size>\n");
exit(1);
}
size = atoi(argv[1]);
core = farcoreleft();
sets = (unsigned)(core / (unsigned long)size);
start = biostime(0, 0L);
for (i = 0; i < sets; i++)
sbrk((int)size);
end = biostime(0, 0L);
seconds = (float)(end - start) * .055F;
printf("%lu bytes allocated in %u blocks, takes %.3f seconds\n",
core, size, seconds);
}
---
Steve N5OWK
------------------------------
Date: Wed, 28 Apr 1993 16:41:32 -0400
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: Thoughts about alloc, bugs and RSPF.
To: tcp-group@ucsd.edu
Andy warner asks,
>An idea occured to me while reading this; would it be possible for
RSPF function more as an autonomous process and source route any
tests it used ? If it judges the route reliable, then it
can update the routing table.
I don't know if NOS IP allows source route as an option. Perhaps it
would work, if it's a way around IP_ROUTE.
>I've never really understood why RSPF needs
to know so much about low level stuff like ARP
Okay, here's what's going on. The usual assumption of IP is that a
subnet (e.g., Ethernet) is fully connected, so everybody hears
everybody with tolerable reliability. Radio ain't Ethernet. So
RSPF never assumes connectivity. It technically has no subnets;
instead, each host is a subnet of its own and there are "node groups"
which imply a likelihood, but not certainty, of connectivity.
So before using a suspected adjacency, RSPF wants to test it to see
that it's really usable. If you run in VC mode then a good VC tells
you it's adjacent. But most ham IPers are miguidedly religiously
opposed to VC mode (IMHO). So in Datagram mode, you have to ping to
find out if the adjacency is really there, and you ARP to ping.
The problem, as Mike said, is that you can't ping without first putting
the adjacency on the IP Route table, and that bumps any previous
adjacency, and if the new adjacency is bad then you lost the old one
which might have been good. That's why it's hard to implement RSPF in
NOS: It has to go around IP Route and all the cherished assumptions
of IP subnetting that NOS has built in, but which don't work on the radio.
BTW, my address is
goldstein@carafe.tay2.dec.com or
goldstein@carafe.enet.dec.com but not the combined form Mike accidentally
posted.
fred k1io
------------------------------
End of TCP-Group Digest V93 #113
******************************
******************************