Date: Sat, 11 Dec 93 04:30:02 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 #319
To: tcp-group-digest
TCP-Group Digest Sat, 11 Dec 93 Volume 93 : Issue 319
Today's Topics:
Appletalk PC cards
datagram vs vc
UDP Locking Things Up...
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: Fri, 10 Dec 1993 13:47:10 -0600 (CST)
From: kurt@cs.tamu.edu (Kurt Freiberger)
Subject: Appletalk PC cards
To: tcp-group@ucsd.edu (TCP-Group Mailing List)
I'm about to score 6-7 PC cards by Apple. they are purported to be
LocalTalk cards.
A) Is this what is driven by the AppleTalk driver in NOS?
B) Does anybody have any docs/schematics for it?
C) Does anybody have any info on what needs to be modified or how to
hook them up? They have the traditional DE-9 connector on the
back.
Thanks,
Kurt
--
# Kurt Freiberger, WB5BBW Dept. of Computer Science, TAMU #
# Internet: kurt@cs.tamu.edu | "Be assured that a walk through the #
# AuralNet: 409/847-8607 | ocean of most souls would scarcely #
# AMPRNet: wb5bbw@wb5bbw.ampr.org | get your feet wet." #
# Disclaimer: Not EVEN an official document of Texas A&M University #
------------------------------
Date: Fri, 10 Dec 93 09:32:13 GMT
From: hall@aeesa.navy.mil ("Jon L. Hall")
Subject: datagram vs vc
To: tcp-group@ucsd.edu
Hi,
I'm interested in hearing what others might think about the virtues of
different parameters in NOS. In particuliar I am refering to the choices
which impact on the performance of RF links. Here are a few questions
that I have been dwelling on with regards to getting the best performance
on our local tcpip backbones. In all cases the links I am refering to are
9600 or 19k2 baud.
1. VC vs Datagram - This seems to be the first decision needed. If you
choose datagram you can reduce your overhead a little, and in conjunction
with big mtu's, mss and tcp window you can send large chunks of data at
one burst. This serves to reduce the penalty of TXD, but, if you have a
link that is not 100% you create problems. In datagram retries are controlled
by the timers in NOS and can result in a unwanted backoff. If you use VC
it appears that packets are segmented to a length defined by AX Paclen.
Since AX Paclen is a system wide parameter you are pretty much stuck with
256. You can still have a large MTU but you get additional header info and
add to overhead. VC has the advantage of increasing the aggressiveness on
the link and will thus retry more effectively. I'd like to hear what others
are using and how it's working.
2. MTU/MSS - I don't want to beat a dead horse on this one. The one
question I have is regarding segmenting of packets. One school of thought
is to make everything a multiple of 196 since that is the mss on a 256
byte netrom circuit. Is this necessary? I would hope that NOS is fairly
effecient at segmenting packets as necessary for integration onto those
links which talk Netrom. Once again since MTU is a global parameter do we
need the overhead on our entire network just to communicate with Netrom?
3. Link Performance - What are others experiencing? I can't seem to do much
better than 90-95% return of 400 byte pings on a 9600 baud link running in
datagram. Is this good or bad? If I run the link VC, I can achieve 100%
with some retries.
I hope this is the correct forum for discussing these issues, if not, let
me know.
Jon...KF2EB
Internet - hall@aeesa.navy.mil
amprnet - kf2eb@kf2eb.ampr.org
------------------------------
Date: Fri, 10 Dec 93 22:45:51 UTC
From: n8wei@N8WEI.AMPR.ORG
Subject: UDP Locking Things Up...
To: nos-bbs@hydra.carleton.ca
Well Guys,
I don't know what to make of this reoccuring problem with UDP locking up the
console. I was sending a message to NOS-BBS when it happened again, so I
thought that I would put sending the message on pause for a minute, and go
look at things. Well, I ended up just telneting back to myself, shelling out,
and recording everything that I thought might be of any use in determining the
problem. There may be things here that realy don't matter, but I did not
know the ramification of the problem.
Anyway, here is the recording of my telnet session. (Edited for easier viewing)
----------------------------------------------------------------------------
| -------------------
| 133104 Net> socket
| -------------------
| S# Type PCB Remote socket Owner
| 128 Loc St 6b1c 6b20 cmdintrp
| 129 Loc St 6b1a 6b20 cmdintrp
| 130 Loc St 6b16 6b20 cmdintrp
| 131 Loc St 6b14 6b20 cmdintrp
| 132 TCP 6ff4 7178 Finger listener
| 133 TCP 6fe5 7159 Convers listener
| 134 TCP 6fd6 713a Time listener
| 135 AX25 I 6fc7 711b AX25 listener
| 136 TCP 6fb8 70fc SMTP listener
| 137 TCP 6fa9 70dd POP3 listener
| 138 TCP 6f9a 70be TTYlink listener
| 139 TCP 6f8b 709f Telnet listener
| 140 TCP 6f7c 7080 FTP listener
| 141 Loc St 7055 71bf bbs
| 143 Loc St 71ce 71bf bbs
| 144 TCP 71db 127.0.0.1:telnet 71bf bbs <------ Sending message.
| 145 TCP 73f5 127.0.0.1:1044 73da mbox <--/
| 146 UDP 73ea 6c0e timer
| 147 Loc St 71e9 7433 bbs
| 148 Loc St 723c 7433 bbs
| 149 TCP 741d 127.0.0.1:telnet 7433 bbs <------ This session.
| 150 TCP 7441 127.0.0.1:1055 77c6 mbox <--/
|
----------------------------------------------------------------------------
| --------------------
| 133104 Net> session
| --------------------
| # S# Sw Type Rcv-Q Snd-Q State Remote socket
| 1 144 E Telnet 0 0 Established Local BBS (127.0.0.1:telnet)
| 2 149 E Telnet 0 3 Established Local BBS (127.0.0.1:telnet)
| Record: \nos\dump\record\udp.hlp
|
----------------------------------------------------------------------------
| -----------------------
| 133104 Net> udp status
| -----------------------
| ( 1)udpInDatagrams 0 ( 2)udpNoPorts 0
| ( 3)udpInErrors 0 ( 4)udpOutDatagrams 21
| &UCB Rcv-Q Local socket
| 73ea 0 0.0.0.0:1053
|
----------------------------------------------------------------------------
| -----------------
| 133104 Net> stat
| -----------------
| JNOS version 1.10x13 (80186)
| by Johan. K. Reinalda, WG7J/PA3DIS
| Tty: 60 rows, 80 columns
| NOS load info: CS=0x1395 DS=0x5c8f
| The system time is Thu Dec 02 03:29:17 1993
| NOS was started on Wed Dec 01 22:08:56 1993
|
| Elapsed time => 0 days:05 hours:20 minutes:21 seconds.
|
| The station is currently Attended.
| The 'Message Of The Day' is
| Type: 'CONTROL T' to return to mailbox.
|
| Table of Open Files.
| --------------------
| Name length offset hnd acc PSP device type/owner
| ---- ------ ------ --- --- --- -----------------
| 22 .WRK 77 77 1 r 0CC0 drive C: [ei110x13.exe]
| TMP3 .$$$ 487 487 1 rw 0CC0 drive C: [ei110x13.exe]
| UDP .HLP 1562 1562 1 rw 0CC0 drive C: [ei110x13.exe]
|
----------------------------------------------------------------------------
| -----------------
| 133104 Net> info
| -----------------
| NOS 1.10x13 (80186), compiled Nov 08 1993 01:35:45 containing:
|
| TCP Servers: SMTP FINGER FTP TELNET TTYLINK DISCARD ECHO
| CONVERS POP3 TIME
| TCP Clients: SMTP FINGER FTP TELNET TTYLINK
| CONVERS POP3 TIME
| with LZW compression for TCP sockets
| UDP Servers: REMOTE
| Mailbox Server
| Full Service BBS with:
| Message and BID expiry
| 'Mail For' beaconing
| BBS 'R:-line' compatibility
| Internet Services: BBS Callbook Client
| 40 sockets, 2 interrupt buffers of 1024 bytes
| Async IP drivers: Serial Line (SLIP)
| FTP Software's PACKET driver interface
| Generic ethernet driver
| Hardware interface packet tracing code
| Multitasking capability when shelling out to MS-DOS
| User port monitor trace mode
|
----------------------------------------------------------------------------
| -------------------------
| 133104 Net> memory debug
| -------------------------
| "Mem stat" to log after failures: on
|
----------------------------------------------------------------------------
| ----------------------------
| 133104 Net> memory ibufsize
| ----------------------------
| Interrupt buffer size: 1024
|
----------------------------------------------------------------------------
| ------------------------
| 133104 Net> mem minheap
| ------------------------
| Minimum free heap when shelled out: 4096
|
----------------------------------------------------------------------------
| -----------------------
| 133104 Net> mem nibufs
| -----------------------
| Interrupt pool buffers: 2
|
----------------------------------------------------------------------------
| -----------------------
| 133104 Net> mem thresh
| -----------------------
| Free memory threshold (bytes): 4096
----------------------------------------------------------------------------
| -----------------------
| 133104 Net> mem status
| -----------------------
| heap size 85408, avail 25712 (30%), morecores 153, coreleft 133104
| allocs 17459, frees 17053 (diff 406), alloc fails 0
| invalid frees 0, overused 0
| threshold 4096
| garbage collections yellow 0, red 0
| interrupts-off calls to malloc 0, free 0
| Intqlen 2 Ibufsize 1024 Iminfree 1 Ibuffail 0
| EMS: 65535 bytes contiguous available.
|
----------------------------------------------------------------------------
| ----------------------
| 133104 Net> mem sizes
| ----------------------
| N>= 1: 90| N>= 2: 105| N>= 4: 267| N>= 8: 643
| N>= 16: 5376| N>= 32: 3472| N>= 64: 1761| N>= 128: 58
| N>= 256: 2667| N>= 512: 1916| N>= 1024: 1122| N>= 2048: 21
| N>= 4096: 8| N>= 8192: 0| N>=16384: 0| N>=32768: 0
|
----------------------------------------------------------------------------
| -------------------------
| 133104 Net> mem freelist
| -------------------------
| 6c34 16 | 6c42 32 | 6c5b 80 | 6f04 96 | 6f0c 96
| 6f14 112 | 6f23 32 | 6f47 480 | 7004 320 | 701c 16
| 7022 80 | 7049 16 | 7052 16 | 7057 304 | 71eb 16
| 71fd 16 | 7221 16 | 7239 16 | 7246 16 | 726f 16
| 72fa 16 | 73bd 16 | 73d3 16 | 7407 16 | 7418 16
| 7501 400 | 75c1 1056 | 770a 1664 | 78cf 608 | 78fc 576
| 7922 1312 | 7aad 17136 | 7f5d 544 |
|
----------------------------------------------------------------------------
| -----------------
| 133104 Net> exit
| -----------------
| Area: n8wei Current msg# 1.
| ?,A,B,C,D,E,F,GA,H,I,IH,IP,J,K,L,M,O,P,R,S,T,U,V,W,X,Z >
| b
| Telnet session 2 closed: EOF
| Hit enter to continue
|
----------------------------------------------------------------------------
Finally, the problem went away, and all of a sudden my corleft dropped from
what you see above to:
99376 Net>
I do not know what to make of this. As I said, I do not know anything about
the User Datagram Protocol (I believe that is what UDP stands for).
Hopefully someone who does understand what is going on can look at this and
figure out what, if anything, can be done about it. If nothing can be done
about it, just give me a simple explination so at least, I know what's going
on when this happens.
Thanks, and sorry for wasting so much space with this text.
Todd
------
. _____
\_ ) Ho,
Ho,
( )Ho,
<\ & 73
: : *
/> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> />
( (
)
(
)
Merry Christmas and Happy New Year from N8WEI @ N8WEI.AMPR.ORG
------------------------------
End of TCP-Group Digest V93 #319
******************************
******************************