From wang!elf.wang.com!ucsd.edu!tcp-digest-relay Thu Feb 14 20:10:50 1991 remote from tosspot Received: by tosspot (1.63/waf) via UUCP; Fri, 15 Feb 91 10:20:45 EST for lee Received: from somewhere by elf.wang.com id aa07017; Thu, 14 Feb 91 20:10:49 GMT Received: from ucsd.edu by uunet.uu.net (5.61/1.14) with SMTP id AA07102; Thu, 14 Feb 91 12:07:59 -0500 Received: by ucsd.edu; id AA17001 sendmail 5.64/UCSD-2.1-sun Thu, 14 Feb 91 04:30:13 -0800 for jbloom Received: by ucsd.edu; id AA16995 sendmail 5.64/UCSD-2.1-sun Thu, 14 Feb 91 04:30:10 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -ftcp-digest-relay tcp-digest-list Message-Id: <9102141230.AA16995@ucsd.edu> Date: Thu, 14 Feb 91 04:30:09 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@ucsd.edu Subject: TCP-Group Digest V91 #41 To: tcp-group-digest@ucsd.edu TCP-Group Digest Thu, 14 Feb 91 Volume 91 : Issue 41 Today's Topics: G1EMM 113016 program size reduction (2 msgs) G1EMM NOS and Net/Rom Connect internet <-> packet ideas .. (3 msgs) Memory loss (NOS's, not mine) (3 msgs) TCP during the TAPR weekend Send Replies or notes for publication to: . Subscription requests to . 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, 14 Feb 91 11:07:18 GMT From: kelvin@kelvin.uk22.bull.com Subject: To: ELLSWORTH%BRAVO@utrcgw.utc.com Brian, a couple of suggestions might help. Firstly, if an alias file does not exist in the same directory as ftpusers, create one. Even an empty file will do. This may save part of the domain file access time. Secondly, if you are running a recent version of mine... eg 901130 (g1emm version 1.6) you can try using 'smtp usemx off' in your autoexec.net file. Lastly, the following entries in your domain file, right at the beginning might help:- *.ampr.org IN MX 10 *.org IN MX 10 There might have to be a . after the org field actually.... Give it a whirl and get back to me on the results. -- All the best, Kelvin. +-------------------------------------------------+ | Kelvin J.Hill - BULL HN Ltd, Hounslow, England. | | Internet - kelvin.uk22.bull.com [128.35.110.6] | | Amprnet - g1emm.ampr.org [44.131.7.6] | +-------------------------------------------------+ ------------------------------ Date: Wed, 13 Feb 91 08:34 CST From: S0JM@ADMIN.HSCH.UTEXAS.EDU Subject: G1EMM 113016 program size reduction To: tcp-group@UCSD.EDU I've finally gotten a DOS machine running again. One of the first things I did was to adapt my Data General One serial port driver for it, and compile up what I thought was close to a minimum configuration, with only the KISS, SLIP and packet driver interfaces, and no NNTP or POP or anything else but the basics and RSPF (which is becoming standard in the Houston IP world). The initial load module compiled to 686K! Ouch! PKLITE reduced that to 485K, and a bit of pruning got it to fit on my IP disk (with a grand total of 23K to spare). Then came the second hurdle: When I ran it, an immediate mem status command after startup showed a heap of 70K, with only about 10K free, and a coreleft value of less than 5K. Needless to say, it crashed almost immediately upon doing just about anything. I've gone back to KA9Q 900828, and it runs fine. The first command in autoexec.net was 'mem eff y'. Obviously, the DG1's effective address space under DOS 3.3 of 424K is not enough for this configuration. What do I do now? Can I shrink the loaded size of the program? I can get 20 to 30K back by going to DOS 2.1, but that's not a real wonderful idea...is it? What is the extra space taken up by the executable beyond the basic program for, anyway? Would removing the packet driver code get me anything? ...Jay, K5ZC ------------------------------ Date: Thu, 14 Feb 91 10:59:40 GMT From: kelvin@kelvin.uk22.bull.com Subject: G1EMM 113016 program size reduction To: S0JM@ADMIN.HSCH.UTEXAS.EDU Jay, I have to say that if you are getting 600kb+ executables, something is *VERY* wrong with your compilation environment. For a cut-down version I get a .exe of about 300kb which is reduced to about 160kb by pklite. I suggest you try compiling up an unmodified copy of my version and see what that generates on your system. If that works ok, then I suggest you look very carefully at your modifications. :-) -- All the best, Kelvin. +-------------------------------------------------+ | Kelvin J.Hill - BULL HN Ltd, Hounslow, England. | | Internet - kelvin.uk22.bull.com [128.35.110.6] | | Amprnet - g1emm.ampr.org [44.131.7.6] | +-------------------------------------------------+ ------------------------------ Date: Wed, 13 Feb 1991 23:22 EST From: Rich Clemens Subject: G1EMM NOS and Net/Rom Connect To: tcp-group@ucsd.edu I have Version 1.4 of the G1EMM NOS code up and running on an old IBM PC and expected that connects via the "Net/Rom" Node would result in a response from the BBS. I find instead that it sorta ends in Limbo with no respons{ to the user and no indication (as far as I can find) by the operator. A friend, NJ8J, has version 1.6 up but has the same result. Am I missing a command somewhere{ Rich Clemens KB8AOB WV Wesleyan College w3[44.58.0.3] ------------------------------ Date: Wed, 13 Feb 91 9:55:46 CST From: andyw@aspen.cray.com (Andy Warner) Subject: internet <-> packet ideas .. To: Anders.Klemets@CS.CMU.EDU > > > I've not thought through ALL the ramifications yet, and it would > probably require > > the use of SSID's which has been shunned so far. > > No it is not absolutely necessary to make NOS use different SSID's on > different ports. It is enough to check the next callsign in the > digipeater field, just as you suggest. > > [cunning plan deleted] Fine idea, I said I hadn't thought it out :-) :-). I hadn't thought of replacing calls on the fly like that. Might it not cause problems though, because the routes are not identical :- For example :- One route might be: g4jec -> g1xrl -> g1xrl-7 -> wb0gdb And the return: g4jec <- g1xrl-2 <- g1xrl < wb0gdb I wonder if this could confuse the hell out of both users and NET/Wrong ? But if different ssid's were used on each ax25 interface it might work beautifully... Then we could just use the REAL calls of each interface. -- andyw. andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835 ------------------------------ Date: Wed, 13 Feb 91 15:02:31 CST From: andyw@aspen.cray.com (Andy Warner) Subject: internet <-> packet ideas .. To: Anders.Klemets@CS.CMU.EDU > > > One route might be: g4jec -> g1xrl -> g1xrl-7 -> wb0gdb > > > > And the return: g4jec <- g1xrl-2 <- g1xrl < wb0gdb > > > > I wonder if this could confuse the hell out of both users and > NET/Wrong ? > > No, as long as g4jec uses the same path to send and receive frames for a > particular connection, I can't see that there would be a problem. The > g4jec TNC has no way of knowing that wb0gdb uses a different AX.25 path. You're right - this should work like a treat. The answer was staring me in the face. Now if only I could find the time to write it :-) :-) -- andyw. andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835 ------------------------------ Date: Wed, 13 Feb 91 15:18:56 -0500 (EST) From: Anders.Klemets@CS.CMU.EDU Subject: internet <-> packet ideas .. To: Andy Warner > One route might be: g4jec -> g1xrl -> g1xrl-7 -> wb0gdb > > And the return: g4jec <- g1xrl-2 <- g1xrl < wb0gdb > > I wonder if this could confuse the hell out of both users and NET/Wrong ? No, as long as g4jec uses the same path to send and receive frames for a particular connection, I can't see that there would be a problem. The g4jec TNC has no way of knowing that wb0gdb uses a different AX.25 path. Anders ------------------------------ Date: Wed, 13 Feb 91 8:53:12 MST From: dlf@phx.mcd.mot.com (Dave Fritsche) Subject: Memory loss (NOS's, not mine) To: tcp-group@ucsd.edu (tcp-group) I've been running G1EMM's NOS now for a little over 24 hours with RSPF blazing away, and I've run out of memory. I started out by compiling the sources so that I could "turn off" all the things that are never used around here, and "turn on" only those drivers that are necessary. I have disabled HOPCHECK, RIP, NRS, NNTP, DIALER, LZW, PPP, & VJCOMPRESS. When I first start it running, before kicking SMTP, or starting any other sessions, a "mem stat" shows about 130k coreleft. By comparison, KA9Q's system at the same point used to show about 190k-210k free. The problem is that in the first 24 hours of operation, the 130k free dropped to 6k free. At this point, there were no memory allocation failures reported in the "mem stat". After another 8 hours, the system was down to about 60 bytes free, and 80 or 90 alloc fails. I guess I'm wondering if this behaviour is considered normal? What begins happening to the system at this point? Is a crash immanent? My course of action was to exit from NOS and re-start it. In retrospect, I wish I had let it run to see what it would end up doing. I'm running this on an 8088 "true-blue" PC, with 640k of RAM, DOS 3.3, the ANSI console driver, and a serial-line network called The $25 Network. So to start with, I should have a relatively large amount of RAM for NOS to play in (the $25 network is a 20k tsr). But at this rate, it looks like I'd need to re-boot about once a day. I figure I must be missing something. I know there are folks out there that are firing up shells and BM from within NOS, and I don't see how that would be possible in my case, except just after startup (fortunately I don't need to, since the harddisk is networked to my 386sx system). I'm not using the "multitask" feature or spawning any other DOS tasks from within NOS. One last observation is that when someone connects to the Mbox, about 20k more memory disappears. Even though I only have 3-5 Mbox connects average per day, each one eats up a lot of RAM. Isn't this RAM being reused for the next Mbox connect? I understand that fragmentation of the available RAM occurs, and I assume that is why each mailbox session lops another large chunk of memory off the pile. Maybe one solution would be to add the "old" Mbox code back into the source base, and stick a #define in config.h so that a compile-time selection of either the "stripped down" or "full blown" Mbox can be included. Personally, I and most of the others in my area have no need for all the memory-hungry functionality in the current Mbox. Any insight into these memory problems would be appreciated. 73 . . . Dave Fritsche (wb8zxu) dlf@phx.mcd.mot.com (Tempe, AZ) ------------------------------ Date: Wed, 13 Feb 91 13:30:46 MST From: dlf@phx.mcd.mot.com (Dave Fritsche) Subject: Memory loss (NOS's, not mine) To: milton@ecn.purdue.edu (Milton D Miller) > One thing that you don't say you have tried is to turn on the "efficent" > memory flag. What that does is change the order of allocation in > malloc from round-robin to first-fit. Although slower, It usually > results in a tighter memory system. Ahh! That's what I need! Now that you mention it, I remember reading that Kelvin had made that selectable. I knew the algorithm had been changed to look from the top of the list, but I forgot that I needed to specifically request that action. > As far as the mbox code goes, the old code would break if more than > one users was logged in at once because there was one standard io > buffer for everybody. The new one allocates one dynamically per > user, and it is this combined with the round-robin allocation that > eats up the core so fast. Hmm, I see. I never really dug too deep into the Mbox code, since we've never really had any use for it. Honestly, the only reason it gets exercised at all, is probably because I'm broadcasting a Netrom ID. I suppose the folks jumping around the nodes just try connecting to see what it is. > Also, have you looked at the free list, to see what has been freed > for potential re-use, but not reused yet (use the mem free command). I'll do that. Guess there's quite a few possibilities I haven't explored yet, but that's why I asked the question. Wasn't sure what to try next. I'm fairly sure that turning the "mem efficient" flag on will help a lot. Thanks for all your help (sure hope you get on the air soon, we need you! :-). > milton 73 . . . Dave Fritsche (wb8zxu) dlf@phx.mcd.mot.com (Tempe, AZ) ------------------------------ Date: Wed, 13 Feb 91 16:20:15 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: Memory loss (NOS's, not mine) To: dlf@phx.mcd.mot.com, tcp-group@ucsd.edu Dave, I understand your problem! I have mine under control at this point with Kelvin's small version and using 'mem eff y'. The system starts with about 150K and is down to 102K after 24 days of operation. It has been sitting at the 102K point for a week or more. In other words it has settled there. I have had mbox, ftp, smtp, pop etc activity during this period. It is an XT clone, V20 8mhz, running dos 3.2 - I have three radio ports. The real answer would be to run a 286 (~$100) or better yet a 386SX (~$350) replacement motherboard in your system. That is what I plan to do in my system. Running DOS 5.0 with everything loaded high gives as much as 640K available to programs. This is at least 50K more than with 3.2 - so NOS (small) should report close to 200K at startup in a system like that. For some reason I do not seem to experience a lot of the problems that others do with NOS. My system has been very stable since I started using G1EMM almost a year ago. There were a few bad versions but it was always corrected. This is also true of the dozen or so local users running G1EMM. We do not use any auto routing (rip, rspf) Doug ------------------------------ Date: Wed, 13 Feb 91 9:09:06 MST From: dlf@phx.mcd.mot.com (Dave Fritsche) Subject: TCP during the TAPR weekend To: tcp-group@ucsd.edu (tcp-group) Anyone interested in operating TCP/IP portable packet while attending the TAPR meeting? We've finally got some TCP activity going down in Tucson now, and activity has picked up a bit here in the Phoenix area as well (despite the grumblings from the BBS crowd as seen in the BBS msg that Brian posted a while back). If you're interested in running TCP while here in Tucson, probably the smartest thing to do is just use a temporary IP address that fits into the current manual routing scheme set up here in AZ. I'll coordinate the temporary addresses here to avoid "collisions". Send me a message, and I'll return the next available address to you for use during the TAPR weekend. The address will be in the [44.124.12.*] group. The activity in Tucson is on 145.05 simplex, and the local netrom/IP gateway is John, 7C0C0A:N7DME [44.124.12.10]. In the return message, I'll include a host list of all the folks in NM and AZ that can be reached thru our network. 73 . . . Dave Fritsche (wb8zxu) dlf@phx.mcd.mot.com (Tempe, AZ) ------------------------------ Date: Wed, 13 Feb 91 09:55 EDT From: o2b fishin' To: tcp-group@ucsd.EDU hiya, I'm sure this is a 'dead horse', but is it possible that someone could take the time to educate me on the issue of domain file search times? As a relatively new user of nos, please forgive any ignorance on my part, but just as a casual observation I'd like to point out that somewhere between the 9008xx version of nos and the 901130 version, some 'enhancement' causes the interactive user (keyboard or bbs) to be completely locked-out during the interval when mail sockets are being opened. I realize that whatever changed must be in the users best interest, but the fact that the keyboard lockout continues for up to two full mins has virtually eliminated the use of the post 901130 version on the N.E. network. It appears that no matter how essential the delay is, local users will not tolerate it. There has been much discussion on this issue over our local network, and several things have been attempted to resolve it (disk caching, ram disks)_ all in vain. It does not seem to be an i/o (hardware anyway) related delay. Any help on this would be appreciated, and passed on to the users of the N.E. network. - brian ka1jy.ampr.org [44.88.0.20] ------------------------------ End of TCP-Group Digest ******************************