| |
PA2AGA > TCPDIG 31.08.96 15:19l 183 Lines 7390 Bytes #-10901 (0) @ EU
BID : TCP_96_176A
Read: GUEST
Subj: TCP-Group Digest 96/176A
Path: DB0AAB<DB0PV<DB0MAK<DB0SON<DB0SIF<DB0NHM<DB0FC<DB0SAW<DB0MGE<DB0ERF<
DB0SHG<DB0SM<DB0ACC<PI8DRS<PI8DAZ<PI8GCB<PI8WFL<PI8VNW
Sent: 960831/0911Z @:PI8VNW.#ZH2.NLD.EU #:58759 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA16598 ; Sat, 31 Aug 96 08:49:30 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.61/7.1) with SMTP
id AA00003760 ; Sat, 31 Aug 96 10:43:12 MET
Received: from pa2aga-1 by pa2aga with SMTP
id AA00003758 ; Sat, 31 Aug 96 10:42:26 MET
Received: from pa2aga-1 by pa2aga-1 (NET/Mac 2.3.61/7.5.4) with SMTP
id AA00008008 ; Sat, 31 Aug 96 10:42:11 MET
Date: Sat, 31 Aug 96 10:40:01 MET
Message-Id: <tcp_96_176A>
From: pa2aga
To: tcp_broadcast@pa2aga-1
Subject: TCP-Group Digest 96/176A
X-BBS-Msg-Type: B
TCP-Group Digest Fri, 30 Aug 96 Volume 96 : Issue 176
Today's Topics:
(fwd) Re: AX.25 - that darn PID (fwd)y
AX.25 - that darn PID
Full KISS TNCs
PPP/SLIP in connected AX25? (8 msgs)
Radio Links and AX.25 backoff (2 msgs)
TCP-Group Digest V96 #175
unsubscribe
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 ftp.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 Aug 1996 10:36:01 +0100 (BST)
From: Alan Cox <alan@cymru.net>
Subject: (fwd) Re: AX.25 - that darn PID (fwd)y
> Not to offend the hoards of Linux and BSD users, but:
>
> Weak argument IMHO. If we were that concerned about performance, we'd all be
> running nos.asm in native mode on pentiums or ppc 604's
Some of us are very very concerned about performance. 100baseT stretches
a PC pretty much. 1Gig ethernet is a "soon" item. Latency is critical
as well for parallel programming.
We don't care for amateur radio (and note KA9Q is not an efficient stack
in the sense we are talking here, it has too many branches, and does
multiple passes over memory).
> >From what I've seen, the difference in performance is small, 20% MAYBE
(based
> on informal testing of SVR4.2 vs FreeBSD on similar speed class machines).
> Wait a month and get a 20% faster machine for the same price :)
You don't generally get 20% faster memory.
> I can run right up to the theoretical Max on a 10Mb ethernet board with
> ftp's on a 586 120mhz box with a $50 ne2000 pci clone using standard SVR4
> streams without any Sun enhancements. (can't tell if it'll go faster, don't
> have a 100mb network yet :-)
It won't fill 100baseT. By comparison I can fill 10baseT with a clone Ne2K
with a low end 486, and anything faster I start to get capture effect
problems on the cable.
Again - not an issue with amateur radio (wish it was)
> Even the Free-BSD fanatics I work with recognize the value of Streams.
They have a value. Performance isnt that value. Flexibility is
> upper level protocol). In a system that dynamically loads drivers, UW 4.2mp,
> SCO UW, Solaris, you don't even need to rebuild the kernel.
Thats not exclusively a streams thing. I can just type "insmod ax25" too ;)
>From an AX.25 implementation point of view the things I do care about are:
o A common socket level API
o A common streams API for folk who use streams+AX.25 when its
finished
o That they interwork properly
Alan
------------------------------
Date: Wed, 28 Aug 1996 22:48:08 +0100 (BST)
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Subject: AX.25 - that darn PID
> > That prevents a user process that knows the protocol will be the one it
> > desires from issuing an initial greeting.
> Yup - I'll have to implement some kind of jumpstart mechanism.
Another area we added to the Linux one to think about is having a uid/callsign
map. Under Linux you can have a table of user<->callsign and multiple
callsigns
in use. Some users may not even have an entry (in which case they dont get
to play radio). Root can bind to any source callsign it likes (for stuff like
NODE software).
> Where exactly is the performance problem in streams? How exactly
> does streams cause significant latency? (hint: it depends on how a
> streams module operates). People grumble about the overhead of
> streams but almost never explain where the overhead is.
Partly this is because the original streams stuff is so bad. The SUN stuff is
very different and seems to be quite quick, and with pretty decent latency
figures on ethernet. [1]
The problems with streams in its original incarnation are generally held to
be
a) Too much state information. Bad for SMP
b) Too much allocating of small buffers into chains (not true now days)
c) Inability to do single pass copy/checksum/...
(some streams stuff has hacks for this but they are fairly
limited. A good socket stack can for example do
copy from user/checksum/fragment/send in one pass. When Im
feeling brave Im going to try a single pass
copy/checksum/SHA/
fragment/send for getting good IPSEC performance.
[Don't try this one at home kids])
d) Streams head is too complex and therefore slow (some of this is
implementation judging by the fact people like Spider had
streams heads of their own that were far faster).
I don't propose to quibble about latency issues on AX.25. Nor would I argue
about the 'elegance' of the streams concept. Finally Sun's streams setup
is clearly different from everyone elses both because of the figures and
also because it has different bugs.(here I mean streams level bugs like the
passed from root authentication bug not protocol handling differences).
> What exactly is this node software? FBB? I've never really looked
> at it.
the Linux NODE software lets a Linux box behave just like one of those
netrom thenet and/or BPQ nodes which (at least in the UK) infest the radio
network. FBB is the major BBS package used for amateur radio work in the UK
and much of europe. Its very nice but used to be DOS only.
[1] According to lmbench the only thing with better tcp latency than an
ultrasparc on 100baseT ethernet is a P133 triton chipset Linux box ;). The
ultra is a bit ahead on bandwidth and as always the thing to remember is
"Its only a benchmark".
------------------------------
Date: Thu, 29 Aug 1996 11:51:20 -0700
From: John Hight <hight@std.sri.com>
Subject: Full KISS TNCs
I've read some notes indicating that it's not required to implement
the full set of commands/options in order to comply with KISS. I'm
looking for recommendations for TNCs which do a good job at
implementing the full set. Absolute minimumm speeds of 2400 is
required and 9600 and greater is preferred. Right now, I'm
considering the Kantronics 9612, and I'm waiting to get a reply back
from Paccomm on their UP. I'm fortunate enough to have some funds at
work for this effort, so economics is not as much an issue as good
robust functionality.
Anybody care to make some recommendations?
John Hight
To be continued in digest: tcp_96_176B
Read previous mail | Read next mail
| |
