Date: Tue, 8 Feb 94 04:30:01 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 V94 #36
To: tcp-group-digest
TCP-Group Digest Tue, 8 Feb 94 Volume 94 : Issue 36
Today's Topics:
Apology
Can I attach (KA9Q) Net to Local Talk using Phonenet?
Does exist Ethernet Driver for Net /Mac? (2 msgs)
Mail Delivery Status
param slottime & persist command - description? (2 msgs)
PMNOS
Some Questions About Basics
WWW Ka9q Server?? (2 msgs)
X.400 Distribution Status Report
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: Mon, 7 Feb 94 11:56:35 PST
From: koster@mdd.comm.mot.com (Ken Koster)
Subject: Apology
To: tcp-group@ucsd.edu
My apologies to the group for the rash of old postings from 'gateway'
recently.
For approximately the last 3 years I've been redistributing this list
to the local tcp/ip community via a local mailing list. Users have
been able to subscribe to the list and respond back via my uucp connection
'algedi.data-io.com'. To the best of my knowledge we've never had a
problem. Until now. :-(
Due to a problem (as yet unknown) at one of the local stations at least
11 messages were resent to the list.
I've temporarily disabled the ability for local users to respond until
we can fix the problem.
73's, Ken N7IPB kenk@algedi.ampr.org
------------------------------
Date: Mon, 7 Feb 94 17:24 CDT
From: emillar@enlaces.ufro.cl (Eduardo Millar)
Subject: Can I attach (KA9Q) Net to Local Talk using Phonenet?
To: tcp-group@ucsd.edu
I have a Local Talk Network with Mac/TCP. We have connect the Local Talk
Network with another TCP Network by radio-links. For radio-links we
have used KA9Q package in PC. On the other hand I have Farallon Phonenet PC
to connect a PC with Local Talk. My question is: Can I use the PC like
Net/Router and connect this PC to Localtalk with Phonenet PC and using
TCP/IP protocols?.
I hope you anderstand to me. My English is not so good.
--------------------------------------------------------------------------------
Eduardo Millar C. e-mail: emillar@enlaces.ufro.cl
Area Telecomunicaciones
Proyecto Enlaces
Ufro-Mece
Temuco- Chile
--------------------------------------------------------------------------------
------------------------------
Date: Mon, 7 Feb 94 11:12 CDT
From: emillar@enlaces.ufro.cl (Eduardo Millar)
Subject: Does exist Ethernet Driver for Net /Mac?
To: tcp-group@ucsd.edu
I have been used Net/Mac in a Local Talk network. The installations where
I work, exist Ethernet
Macintosh Network and I have to links this netwok with another Ethernet
Macintosh Network by Radio. My question is: Anyone know a version of
Net O/Mac that support any ethernet driver?..
------------------------------
Date: Mon, 7 Feb 1994 10:31:23 -0900
From: dewayne@netcom.com (Dewayne Hendricks)
Subject: Does exist Ethernet Driver for Net /Mac?
To: emillar@enlaces.ufro.cl (Eduardo Millar), tcp-group@ucsd.edu
At 11:12 2/7/94 -0500, Eduardo Millar wrote:
>I have been used Net/Mac in a Local Talk network. The installations where
>I work, exist Ethernet
>Macintosh Network and I have to links this netwok with another Ethernet
>Macintosh Network by Radio. My question is: Anyone know a version of
>Net O/Mac that support any ethernet driver?..
NET/Mac does not support direct Ethernet connections. For
instance, it cannot talk to MacTCP when it is configured via its control
panel to use the Ethernet interface. NET/Mac does support EtherTalk, but
not Ethernet.
-- Dewayne
--------------------------------------------------------------------------
Dewayne Hendricks, WA8DZP ! CIS: 75210,10 AppleLink: D6547
Tetherless Access Ltd. ! Packet Radio: WA8DZP @ K3MC.#NOCAL.CA.USA.NOAM
43730 Vista Del Mar ! AOL: HENDRICKS
Fremont, CA 94539-3204 ! Internet: dewayne@netcom.com
Phone: (510) 659-0809 ! Fax: (510) 770-9854
--------------------------------------------------------------------------
------------------------------
Date: 07 Feb 1994 12:16:12 EST
From: "Central Postmaster" <HARRIS.POSTMSTR@IC1D.HARRIS.COM>
Subject: Mail Delivery Status
***** Error in Mail Delivery *****
INVALID RECIPIENT
Recipients:
HARRIS.GPARKE04@IC1D.HARRIS.COM
------------------------------
Date: Mon, 7 Feb 1994 14:12:28 -0600
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: param slottime & persist command - description?
To: gwillis@eleceng.adelaide.edu.au, tcp-group@ucsd.edu
On Mon, 31 Jan 1994 03:24:45 +1030 (CST) in <199401301655.IAA00574@ucsd.edu>,
gwillis@eleceng.adelaide.edu.au asked:
>
> Hello.
>
> I have been trying to find an accurate consise description of exactly
> what the function of the 'persist' and 'slottime' functions are that
> are set using the param command in NOS and how these parameters
> affect radio channel performance. My understanding is that they are
> a replacement for DWAIT which is found in many TNC software EPROMS.
>
P-Persist is a alternative channel access protocol that reduces the
"everybody waiting starts transmitting at once" problem found in
the DWAIT protocol.
First, a short explanation of DWAIT: When a station has data to send,
it first checks if the channel is busy. If so, then it waits until it
clears, then keys and sends its data. The DWAIT protocol says it will
wait y 10s of milliseconds for a digipeater to start transmitting
before seizing the channel. For digipeated frames, the DWAIT time is
bypassed, effectively giving priority to digipeated frames. Some of
the problems incurred with this scheme are: (1) the digipeater has to
check the crc, decide to send the data, and sieze the channel within
the dwait window for it to gain any advantage (which isn't possible in
KISS mode, because it has to go across the serial port to the host
twice), and (2) As the channel becomes more crowded, the chances of
having two stations waiting to send a packet increases. If their
timeouts are the same length, they will continue to key on top of each
other, resulting in a sequence of collisions.
P-Persist instead relies on probabilities and random numbers to keep
(2) from happening. When a station has data to send (be it new or
digipeating information), it waits for the channel to clear. At that
point, it picks a random number between 0 and 255. If it is less than
or equal to the PERSISTance, it will sieze the channel and transmit.
If not, it will wait SLOTTIME and then pick a new number if the channel
is still free, repeating the process. As long as the numbers don't
match, you won't continue to collide with the same station.
Some MFJ firmware releases combine the two protocols by waiting for
dwait before starting p-persist.
Advice on choosing parameters: [I am sure someone will correct me if I have
these wrong :-) I admit I haven't read the papers describing the
studies.]
The persistance plus 1 is divided by 256 to get the fraction of the
time you will sieze the channel during any given slot. To avoid
congestive collapse, it should be less than 1/(number of stations with
data to transmit at any given time). Be sure to allow for more
stations to come on your frequency, as it will run much better. But,
as someone else pointed out, be facist about getting their parameters
set right! (if they are too agressive, your station will kindly back
off and wait for them to finish :-). For slot time, the time should be
at least TXdelay, because that is supposedly how long it takes for a
station to key up and have all the recievers recgonize the station
being on the air. If all stations don't use the same slot time, then
the back off doesn't help as much because the decision slots will not
line up. If they are skewed far enough, a slot will appear as no
activity even though another started in transmitting in the "previous"
slot. Note this can still happen if the station decides it has data
during the middle of an idle slot.
[ brainstorm: this last issue could be addressed by requiring stations
to wait for the channel to go busy and then idle before transmitting,
unless the channel stays idle for some time >> slottime. Comments? ]
> Could somebody point me in the direction of a document or file that
> describes this function? Also which layer of the OSI protocol stack
> do these functions belong to? (I am guessing level 1?)
In addition to what I stated above, the Kantronics manual gives a
reasonable description (although I don't remember any more
information). Somewhere there have been a few papers written.
>
> Also I am interested to find out if there is any implementation of the
> T2 timer described in the AX.25 v2.0 protcol specification in the
> NOS package for AX.25 connections or IP virtual circuits carried on
> AX.25? (This parameter is the equivalent of what in the popular TNCs
> is seemingly called RESPTIME).
Well, I guess that is the frame ack timers, but haven't looked at the
source. I don't know the timers by their t number.
>
> Cheers de Grant VK5ZWI
Hope this helps. I haven't seen any replies to the list, and I finally
got a few minutes to type this in.
milton
--
Milton Miller KB5TKF miltonm@austin.ibm.com miltonm@bga.com
I never speak for IBM.
------------------------------
Date: Mon, 7 Feb 1994 17:05:11 -0800
From: Phil Karn <karn@qualcomm.com>
Subject: param slottime & persist command - description?
To: miltonm@inetnode.austin.ibm.com
>> Also I am interested to find out if there is any implementation of the
>> T2 timer described in the AX.25 v2.0 protcol specification in the
>> NOS package for AX.25 connections or IP virtual circuits carried on
>> AX.25? (This parameter is the equivalent of what in the popular TNCs
>> is seemingly called RESPTIME).
>Well, I guess that is the frame ack timers, but haven't looked at the
>source. I don't know the timers by their t number.
These timers are optional in AX.25. If you run with MAXFRAME=1, then
they don't do much since there's no point in waiting in case another
frame gets sent before you ack the current one. Also, the round-robin
scheduling in NOS usually (but not always) causes automatic piggybacking
of the AX.25 ack on any data being sent in response to the AX.25 data.
Phil
------------------------------
Date: Tue, 8 Feb 1994 09:04:08 GMT+1
From: Peter van der Post <P.vanderPost@ET.TUDelft.NL>
Subject: PMNOS
To: tcp-group@ucsd.edu
Hi everybody,
For a period of three months I have the chance to get some experience
with *real* E-mail, hi. Yesterday I took a subscription on this group
and, wow, a reply from ucsd.edu in 30 seconds, I couldn't dream of
such a quick response using packet radio, hi.
Well to the point now. As an OS/2 user, I am a happy user of the
Presentation Manager programs PMNOS en PMail by Walt Corey, KZ1F. It
has been quite some time since I've heard or read from Walt. The
latest news from Walt was that he had released version 1.1 of PMNOS.
That was in the very beginning of 1993. Walt told us that he was
working on something completely new, I guess, a Workplace Shell
integrated version of the NOS en PMail functions/services. He
mentioned the names WPNOS en WPMail some time.
Together with a lot of other OS/2 users, I would very much like to
know if Walt is still working on it. He made some promises about an
SCC driver, which is at the top of my PMNOS wish list, hi.
Well, thanks in advance for any replies,
73, Peter PE1NNH.
------------------------------
Date: Mon, 7 Feb 1994 14:39:32 -0600
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: Some Questions About Basics
To: JSTEWART@umiami.ir.miami.edu, tcp-group@ucsd.edu
On Sun, 30 Jan 1994 22:03:24 -0500 (EST),
John Stewart <JSTEWART@umiami.ir.miami.edu> asked:
Disclaimer: I don't use packet drivers, so I will answer best guess.
> I am trying to understand what interrupt buffers are used
> for in NOS? Are they used on both transmit and receive?
Only on receive (transmit buffers are allocated with interrupts
enabled).
> Given that ibufsize should be greater than or equal to MTU,
> does the TCP WINDOW setting have an effect on the number of buffers
> that you need?
Yes, but it is your advertised recieve window, not your (maximum) send
window. You need as many ibuf's as you expect packets from all hosts
in your processing loop time. This should be at least the number of
packets in a window (considering mss and mtu induced fragments). If
you often have several connections activly sending data (ie multiple
inbound ftps), you may need more. You can set it high for a while and
see what minfree is, then lower it if it is excessive.
>
> Does the transmit queue length on the ATTACH PACKET statement
> have an effect on the number of buffers that you need?
I am not familiar with that parameter.
> I have read the NOS documentation and some other references, but
> am still missing part of the story. Can someone enlighten me?
>
> Thanks.
>
> John, n4qi
> Internet: jstewart@umiami.ir.miami.edu
> AmprNet: n4qi@n4qi.ampr.org
milton
--
Milton Miller KB5TKF miltonm@austin.ibm.com miltonm@bga.com
I never speak for IBM.
------------------------------
Date: Mon, 7 Feb 1994 11:52:41 -0600
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: WWW Ka9q Server??
To: tcpgroup@ucsd.edu
I found a tidbit in alt.winsock and followed up to get the following
reference:
Current supports ....
searches (2 or 3 types)
CSO database
auto-index-file generation
ascii and binary transfers
IP based item access
Here is the address of my Gopher / HTTP server
gopher://biochemistry.bioc.cwru.edu/
or
http://biochemistry.bioc.cwru.edu/
Regards,
milton
--
Milton Miller KB5TKF miltonm@austin.ibm.com miltonm@bga.com
I never speak for IBM.
------------------------------
Date: Mon, 07 Feb 1994 20:40:27 -0500
From: ashok@biochemistry.cwru.edu (Ashok Aiyar)
Subject: WWW Ka9q Server??
To: tcp-group@ucsd.edu
>
>I found a tidbit in alt.winsock and followed up to get the following
>reference:
>
>Current supports ....
>searches (2 or 3 types)
>CSO database
>auto-index-file generation
>ascii and binary transfers
>IP based item access
>
>Here is the address of my Gopher / HTTP server
>
>gopher://biochemistry.bioc.cwru.edu/
>or
>http://biochemistry.bioc.cwru.edu/
>
I had not intended to advertise it, but there is an excellent
Gopher server for KA9Q. This is written by Chris McNeil of
Mt. Allison Univ., Canada. In the post on alt.winsock, when I
referred to my Gopher, I referred to the computer that I am
running Chris' Gopher server on.
Based on Chris' code, I do have a very crude HTTPD working on
the same machine. That is the second thing referred to above.
Later,
Ashok
--
Ashok Aiyar Mail: ashok@biochemistry.cwru.edu
Department of Biochemistry Tel: (216) 368-3300
CWRU School of Medicine, Cleveland, Ohio Fax: (216) 368-4544
MIME Enclosures OK
------------------------------
Date: 07 Feb 1994 14:56:14 EST
From: "X.400 Postmaster" <HARRIS.POSTMST1@IC1D.HARRIS.COM>
Subject: X.400 Distribution Status Report
To: TCP-Group@UCSD.EDU
Soft-Switch X.400 Gateway
Distribution Status Report
2/07/94 14:56:44
===============================================================================
Status: Unable to deliver mail as timeout occured while routing
Subject: TCP-Group Digest
Surname: GPARKE04
Country: US
Admin. Domain: TELEMAIL
Private Domain: HARRIS
Organization: COMM
Org Unit 1: HDD
Org Unit 2: ENGRPOST
------------------------------
End of TCP-Group Digest V94 #36
******************************
******************************