Date: Wed, 17 Mar 93 04:30:16 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 #73
To: tcp-group-digest
TCP-Group Digest Wed, 17 Mar 93 Volume 93 : Issue 73
Today's Topics:
advanced-packet list is open for discussion
CSMA/CD on radio ? (I see a way CD can be done) (2 msgs)
Problem in SCC.C ? (2 msgs)
tcp-group charter
TOPS networking cards (2 msgs)
upcoming backbone plans in Utah
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, 15 Mar 93 13:27 CST
From: Jay Maynard <S0JM@ADMIN.HSC.UTH.TMC.EDU>
Subject: advanced-packet list is open for discussion
To: john@ITS.BT.CO.UK
> nos-users - (for want of a better name) which would be for end users to
> discuss configuration problems with their systems/networks. This could
> be a newsgroup say rec.radio.amateur.tcpip or both.
Just for general consumption...
There's a group of folks discussing a potential reorg (yet again) of
rec.radio.amateur.*. Among the proposals is renaming the existing
rec.radio.amateur.packet to rec.radio.amateur.digital, and adding
rec.radio.amateur.tcp-ip. The discussion is going on on the list
rra-reorg@amdahl.com; Joe Bob says check it out.
...Jay, K5ZC
------------------------------
Date: Tue, 16 Mar 93 13:32:17 GMT
From: agodwin@acorn.co.uk (Adrian Godwin)
Subject: CSMA/CD on radio ? (I see a way CD can be done)
To: tcp-group@ucsd.edu
------------------------------
Date: (null)
From: (null)
Subject: CSMA/CD on radio ? (I see a way CD can be done)
To: TCP-Group@UCSD.Edu
Jerzy Tarasiuk <JT@zfja-gate.fuw.edu.pl> wrote :
>A duplex channel can be used for collision detect, too. Simplest way to
>do it I see: need a "regenerator" retransmitting everything it receives
>witch frequency change; every station sends using frequency f1, receives
>on frequency f2, while regenerator sends on f2, receives on f1; station
>listens while transitting and must verify data from the regenerator is
>same as it sends, when it isn't it should stop transmission; regenerator
>can detect carrier lost or invalid packets but it isn't necessary.
That's hard, though, given the long paths typical of amateur radio :
they may be many bits long, even at less than 1Mb/s. The main and repeated
signals therefore have to be either decoded or time-shifted to allow a
comparison.
This is also a problem with the scheme to transmit a 'channel busy' signal -
it will take at least the round-trip time, plus a while to decode the
repeater's transmission, to determine that your station doesn't own the channel
and should back off. The smaller the back-channel, the longer it will
take to read from the repeater which station should be allowed to transmit.
As an example, a possible scheme might have a long, sacrificial, preamble,
during which the repeater attempts to recognise one of the contending
stations and identifies on the slower back-channel who has it's attention.
Losers (perhaps both, if the signals are similar in strength) must
recognise that they've lost and back off before they corrupt the
winning transmission. This preamble would take a significant chunk
of the transmission time, but without it, the contention wouldn't be
resolved until it was already too late to make use of the transmission,
so it doesn't seem to be any improvement over a full-duplex repeater
(and simplex user radios).
I've seen two proposals for alternative channel access methods - the MACA
system (ACK from the receiver indicates for how long the channel is busy)
from Phil Karn, and the Hubmaster (hub controlled time slots) from Glenn
Elmore et al.
Both have merits, but as far as I know, they haven't been implemented.
Is there any particular reason why, other than the usual problems of time,
energy and inertia ?
-adrian
------------------------------
Date: Tue, 16 Mar 93 15:56:12 GMT
From: simon@wise.demon.co.uk (Simon Wise)
Subject: Problem in SCC.C ?
To: TCP-Group@UCSD.Edu
I've been wandering through the code in SCC.C, with the initial
intention of playing with the p-persist implementation.
I've come across an unrelated problem, and I can't make up my mind
whether it's just a problem with the indenting of the source code,
or whether it is an error.
In function 'scc_sdlcex' in two places the code reads:
(I've stripped the comments in this extract)
if(scc->rbp != NULLBUF){
if(scc->rbp->next != NULLBUF || scc->rbp->cnt > sizeof(struct phdr))
scc->rxerrs++;
scc_tossb(scc);
}
As this stands, the only action of the second 'if' is to increment
rxerrs. Function scc_tossb() gets called if the first 'if' is
true. Is that what's supposed to happen, or should scc_tossb()
only be called if the second 'if' is true ??
(In other words, should the code above really be
if(scc->rbp != NULLBUF){
if(scc->rbp->next ......)
scc->rxerrs++;
scctossb(scc);
}
or
if(scc->rbp != NULLBUF){
if(scc->rbp->next ......){
scc->rxerrs++;
scctossb(scc);
}
}
??).
Every version of NOS source code I possess has the same ambiguous
indenting here, which doesn't help. I'm inclined to think that the
second case is correct, but then the braces on the outer 'if'
aren't necessary.
Any ideas anyone?
---
+------------------+---------------------------------------------------+
| G1FHY | AMPR.NET - g1fhy@hub.g1fhy.ampr.org [44.131.7.128]|
| Simon Wise | - g1fhy@g1fhy.ampr.org [44.131.7.138] |
| 51 Hamilton Road | AX25 BBS - G1FHY@GB7HSN.#32.GBR.EU |
| West Norwood | INTERNET - simon@wise.demon.co.uk |
| London SE27 9RZ | BT NET - 44-81-766-0120 |
+------------------+---------------------------------------------------+
------------------------------
Date: Wed, 17 Mar 1993 11:04:28 +0100 (MET)
From: Mario Illgen <Mario.Illgen@Informatik.TU-Chemnitz.DE>
Subject: Problem in SCC.C ?
To: Simon Wise <simon@wise.demon.co.uk>
Hi Simon,
On Tue, 16 Mar 1993, Simon Wise wrote:
>
> (In other words, should the code above really be
>
> if(scc->rbp != NULLBUF){
> if(scc->rbp->next ......)
> scc->rxerrs++;
> scctossb(scc);
> }
>
Thats the correct one. I looked at the original scc driver (for Atari ST)
and there is the TAB before "scc->rxerrs++;". It's only a decision what
should be counted as an rx error. The buffer is thrown away in both cases.
73! de Mario, DL3LSM
**********************************************************************
* Mario Illgen * INTERNET: illgen@informatik.tu-chemnitz.de *
* TU Chemnitz * *
* FB Informatik * AX25 BBS: DL3LSM@DB0LPZ.GER.EU *
**********************************************************************
------------------------------
Date: Mon, 15 Mar 93 12:36:01 EST
From: barry@dgbt.doc.ca (Barry McLarnon)
Subject: tcp-group charter
To: tcp-group@ucsd.edu
> Why not regularly *post* the charters of tcp-group and the other lists to
> remind us what topics the list actually serves. This would stop a lot of the
> noise as folks would be continually reminded where they should post their
> questions/ideas etc. Also we see subscribers on tcp-group posting because
> they are simply *unaware* that other lists exist such as the excellant
> <nos-bbs@hydra.carleton.ca> and many others. Some of you may be worried that
> if we 'advertise' tcp-group to the great unwashed we will increase the noise
> level again, but I feel that provided we advertise _all_ of the groups, people
> will be able to more carefully choose which list they wish to post the
> particular article to. When someone new subscribes to 'tcp-group' (or any of
> them) they could by default, be sent a copy of the FAQ and the charter of the
> group. I'm open to suggestions where each of these charters are posted as each
> should have references to the other but not necessarily have a full desription
> (was that clear?)
Deep within the bowels of ucsd.edu (in the hamradio/packet/tcpip/docs dir)
there is a FAQ file put together by Mike Gallaher which contains, among other
things, info on some of the mailing lists. Of course, people somehow have to
be made aware that the file exists, and not everyone has ftp access to the
Internet. Incidentally, the description of tcp-group's charter in the FAQ
file is a bit wide of the mark, mentioning only that it is a 'forum for NOS
developers'. The *only* place I have seen tcp-group's original charter
spelled out is in the helpfile from listserv@ucsd.edu.
So, I agree that periodic reminders of what the mailing lists cover (if we can
figure that out :-) are needed, and they probably need to be posted to the
lists themselves. They should also include the info on subscribing/
unsubscribing to the lists. The reduction in subscribe/unsubscribe stuff
appearing on the lists instead of where it belongs would itself probably
justify a monthly posting. If the material for all the lists could be
gathered into one concise file, it could be maintained and mailed from one
point. This has the drawback that subscribers to multiple lists will see
the thing multiple times. Anyone got a better idea? I'll take a crack at
preparing the file, if nobody's done it already...
> Steve - ZL1BHD
Barry
--
Barry McLarnon | Internet: barry@dgbt.doc.ca
Communications Research Center | AMPRnet: barry@bbs.ve3jf.ampr.org
Ottawa, Canada K2H 8S2 | PBBSnet: ve3jf@ve3jf.#eon.on.can
------------------------------
Date: Mon, 15 Mar 93 11:28:00 MST
From: "Marvin Match" <match@[128.110.44.31]>
Subject: TOPS networking cards
To: tcp-group@ucsd.edu
The TOPS networking card is a 8530-based serial card intended to attach
a PC to an Appletalk network. One port is configured as the input and one
as the output. They are interupt-driven and use DMA. Even on an Appletalk
network they provide 230K bps or so. Seems to me, as I follow the discussion
on this service about SCC cards, this card might be just the ticket for
providing a high-speed port to a PC.
I have a few of these cards that we gave up on as a networking solution.
TOPS (or Sitka or Sun or whoever now) says that their drivers don't run
fast eneough to use these cards in even a 16Mhz 386, and probably never
will as the card is not a big seller. But I think the hardware is fast
eneough (ISA bus is only 8-10 Mhz) and to use it as a port in a NOS-based
PC you'd have to write a driver anyway. (I'm refering to my previous
post about a backbone in Utah)
I think you can still find these cards, retail is about $110 as I recall.
Might this thing be usefull?
Marvin Match KA7TPH
match@sky.civil.utah.edu
------------------------------
Date: Tue, 16 Mar 93 14:49:08 HST
From: tony@mpg.phys.hawaii.edu (Antonio Querubin)
Subject: TOPS networking cards
To: match@civil.utah.edu
> From: "Marvin Match" <match@[128.110.44.31]>
> I have a few of these cards that we gave up on as a networking solution.
> TOPS (or Sitka or Sun or whoever now) says that their drivers don't run
> fast eneough to use these cards in even a 16Mhz 386, and probably never
> will as the card is not a big seller. But I think the hardware is fast
> eneough (ISA bus is only 8-10 Mhz) and to use it as a port in a NOS-based
> PC you'd have to write a driver anyway. (I'm refering to my previous
Support for the PC LocalTalk card in NOS is already available. There is a
packet driver for the card and the diffs to make NOS accept an AppleTalk class
packet driver are also available (look on ucsd.edu for the
hamradio/packet/tcpip/localtalk directory for the diffs and binary). The
catch is that the packet driver requires a DDP/IP gateway (FastPath, Gatorbox,
etc.) on the LocalTalk LAN for certain services before it will load properly.
Tony
------------------------------
Date: Mon, 15 Mar 93 10:49:38 MST
From: "Marvin Match" <match@[128.110.44.31]>
Subject: upcoming backbone plans in Utah
To: tcp-group@ucsd.edu
A while ago I posted a message asking for comments that went something
like "If you were Master of the Universe... had all the money in the
world... had support from the entire ham community... etc. how would
you build a backbone through Utah?" This post grew out of efforts by the
local TCP-IP users to get some discussion going.
I got a few responses. Thank you very much! But now it's time to either
fish or cut bait. I've stirred up a hornets nest, and you wouldn't believe
the response from the local packeteers. They're all dying to get something
done.
This past Saturday 13th I proposed to the Utah Packet Radio Association
what my own plan would be, and they decided to put their money where my
mouth is. Several clubs accross Utah have offered money to fund a proto-
type, and for test purposes install it between the University of Utah
and the Utah State Capital, which is line of site.
I want to share what I proposed with the tcp-group and ask for comments.
(P.S. I'm not hurt by flames, so blast away) If someone sees flaws, now
is the time to change plans.
I proposed a full duplex backbone using two microwave bands or on two
frequencies on one microwave band, running point to point, mountaintop
to mountaintop, each line-of-sight to the relay station to it's North
and to the relay station to its South. The u-wave radios at each relay
station are connected via a node controller/packet switch which provides
access to the backbone at each metropolitan area.
Some of the relay stations will be 200 miles apart in central Utah where
mountain peaks are few and far between (as are people), complicating
freq. selection. Seems to me the added gain/antenna size is offset by
increased path losses and u-wave absorbtion by rain and snow at 5700Mhz,
therefore maybe one freq. near 3300Mhz and one near 3500Mhz would be
better. Also, it's easier to make power at 3 Ghz than at 6 Ghz. Comments?
SS is a possibility, but probably should be viewed as an upgrade once
the non-SS concept is proven. Comments?
We decided to run the backbone at a minimum of 56K b/sec. and will try
toachieve 1.5M b/sec. Comments?
The controller can be anything, but why not use a 386sx motherboard, two
high speed serial ports for the u-wave link, two (or more) 9600-19.2
ser. ports to provide user access, stripped-down NOS on rom, no kybd,
no display, and maintain routing, configuation, etc by logging onto
the system via a user port (which connects to a TNC and 70cm radio like
we're all using now). Comments?
Modems? What's used in other areas? We can build our own. How can I find
out about the DSY modem? Has anyone looked at the Signetics NE5080/NE5081?
Comments?
The radios might be converted from surplus u-wave telephone relays
that are available, or could be easily built. We have some excellent
U-wave engineers at U of U. Comments?
Marvin MatchKA7TPH
match@sky.civil.utah.edu
------------------------------
End of TCP-Group Digest V93 #73
******************************
******************************