| |
ZL3AI > APRDIG 06.06.03 15:01l 250 Lines 9834 Bytes #999 (0) @ WW
BID : 1428-ZL3AI
Read: GUEST
Subj: TAPR Digest, May 31, 2/8
Path: DB0FHN<DB0RGB<OK0PPL<RZ6HXA<SP7MGD<ZL2TZE<ZL3VML
Sent: 030605/1336Z @:ZL3VML.#80.NZL.OC #:1724 [Chch-NZ] FBB7.00i $:1428-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Coverage Map
From: KC7ZRU - Tate <kc7zru@arrl.net>
Date: Sat, 31 May 2003 00:02:15 -0600
X-Message-Number: 3
James Smith wrote:
>What program is needed in making a coverage area map of a Digipeater
>and/or Repeater?
For Windows, one of the most - if not the most - popular is "Radio
Mobile Delux"
Powerful
As with anything of power, it takes a bit of study and preparation to
get the best use out of it.
find it at:
http://www.cplus.org/rmw/english1.html
Get some data sets - plug in the parameters - view a coverage map for
either a station or a network.
Very cool stuff indeed!
73
--
"The Dungeon" online at http://go.to/kc7zru
Casper, WY | CARC Repeater
DN62tt | 146.940-
http://www.trib.com/~carc
----------------------------------------------------------------------
Subject: Re: APRS Internet System Design Philosophy
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Sat, 31 May 2003 06:22:26 -0500
X-Message-Number: 4
>-----Original Message-----
>From: Miller Scott Contr 30SCS/FTI
>[mailto:Scott.Miller@vandenberg.af.mil]
>Posted At: Friday, May 30, 2003 11:58 PM
>Subject: [aprssig] Re: APRS Internet System Design Philosophy
>
>I've got no problem with IGATE uplinks and inter-server
>connections using TCP_NODELAY. But the average client
>doesn't need the low latency, and client connections vastly
>outnumber backbones and uplinks.
But how do you differentiate?
>Just set it to flush out the buffer every 5 or 10 seconds if
>it's not full. And even at its slowest, I don't think my
>statewide connection ever goes that long without 1500 bytes of data.
If you flush the buffer, then you lose those packets. Now you have
introduced random packet loss. This has been seen with some software
that, as capacity would be reached, just started to randomly dump
packets. The connected client/IGate/server had no indication that
packet loss was occurring.
>The key is that it's NEAR real-time. APRS can stand a whole
>lot more latency than VoIP. Why not take advantage of that
>for some gains in efficiency and capacity?
Because of the issues I pointed out before, the latency that can be
introduced could defeat the dupe checking algorithms and therefore
destabilize the network (yes, we were able to find 45+ second loops
before). The gains in bandwidth utilization (what you call efficiency
and capacity) are minimal and are strongly offset by the potential
damage to the integrity of the APRS-IS subnet.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: Re: APRS Internet System Design Philosophy
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Sat, 31 May 2003 06:40:12 -0500
X-Message-Number: 5
>-----Original Message-----
>From: David L Norris [mailto:kg9ae@webaugur.com]
>Posted At: Saturday, May 31, 2003 1:26 AM
>Subject: [aprssig] Re: APRS Internet System Design Philosophy
>
>should be freely available to the community. It must be
>reasonably portable so it could run _native_ on Windows,
>Unix, etc without too much effort. By portable I mean
>written in C and no bulky emulation layers. i.e. not Java
>Think: bootable floppy disk
While Java VM's won't make it to a floppy disk, C and C++ are not
portable between operating systems (yes, I have programmed extensively
in both). They require recompiles and they require special
considerations depending on what OS they are run on. Java is, to my
knowledge, the only widely available, free application language that
apps are 100% transportable as-is between OS's. To point, javAPRSSrvr
and javAPRSFilter are being run on Windows, Linux, Unix, Max OS 9, and
Mac OS 10 without modification. Sorry, no DOS version of a JVM that I
am aware of.
When I started javAPRSSrvr, I had a major concern about the memory and
CPU impact on a system. And that concern intensified with the addition
of javAPRSFilter. I think all that were involved with the initial
testing had the same reservations about a Java-based server. What we
found is that Java, when used in these types of network applications,
can be surprisingly efficient. It will never be as efficient as well
written C or C++, but then you can't drop a compiled C or C++ program
into any operating system. Those are the ramifications of compiled vs.
interpreted.
Those of you who have worked with me during the development of
javAPRSSrvr will attest that I was no big fan of Java because of the
reasons you espoused in your post. I will say now, however, that Java
is much easier to write in, much easier to support, and much more
portable than C or C++. And it does surprisingly well in network
applications. By the way, I used 1.1.4 as the compatibility basis for
javAPRSSrvr (current Sun JVM is 1.4.1). And that code works across JVM
versions without modification.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: RE: APRS Internet System Design Philosophy
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Sat, 31 May 2003 07:08:15 -0500
X-Message-Number: 6
>-----Original Message-----
>From: Steve Dimse [mailto:k4hg@tapr.org]
>Posted At: Friday, May 30, 2003 4:07 PM
>Subject: [aprssig] APRS Internet System Design Philosophy
>
>needs of the APRS IS. Still, I am a strong advocate of the
>original design, because I feel that it offers the best
>chance of being implemented given the resources available to
>an amateur project like this. Most importantly, it requires
>the cooperation of a smaller number of people, and the
>monitoring of a smaller number of servers.
Except that a tiered system is already in place. One premise you have
stated is that the advocates of a tiered network say no clients should
connect to the core. Whether they should or shouldn't is not the
deciding factor for having a tiered network. See below.
>The shortcomings in the two tier system are it requires
>the cooperation of a much larger number of people, the
>multiple servers are more confusing to users, and it is
>much harder to monitor the system.
In actuality, a tiered system takes less coordination than a large
number of core servers because the lower tier servers do not need to be
coordinated. Yes, it increases the complexity of the network,
especially when people try to interconnect non-core servers to many
other non-core servers. With the core matrix properly designed and
implemented (which it is now), the need for these lower level
interconnects is diminished if not eliminated (this is a hint to all of
those that think they need 5, 10, or more outbound connections from
their server).
>Advocates of the two tier approach like to say that it
>allows more filtering options, but there is no filtering
>asecond tier server could do that a core server could not.
Except that, as you have indicated, the core servers need to be like
configured for ease of use (especially with features like
rotate.aprs.net). Without creating a port usage nightmare, attempting
to put regional filter ports, specialty ports, etc. across multiple core
servers that give all users what they want is an extremely difficult
coordination effort and one I suspect might be difficult to implement
with the different software implementations on the core servers and the
different time zones for work schedules. A case in point was the
configuration changes needed just to put fourth into the interconnection
matrix took most of a day to implement with many packets being lost
between RF networks.
I would say that keeping the core manageable and mirrored is of the
utmost importance for reliability and usability. As it stands now, the
users know that they can connect to port 23 or 10152 at the core for a
full feed and 1314 for a message-only feed. Port 10151 is now a
duplicate of 10152 due to the network problems encountered with having a
history port on the core servers. second and fourth both support 14580
as a client customizable filter port. There is talk about first and
third adding this port in the near future. That would give all users
the ability to say "I want to see all data, messages only, or just what
I tell the server I want to see."
Powerful for the core servers but it still does not negate the need for
non-core servers. Many tier 2 servers provide country or region
specific services. Some provide special ports for low bandwidth
connections needed by the CW program. Others provide specialized
SatGate ports that reduce the data flow to the client to almost nothing.
As long as hams come up with special needs, there will be a place for
non-core servers.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: Email Line Length
From: Bob Bruninga <bruninga@usna.edu>
Date: Sat, 31 May 2003 08:15:36 -0400 (EDT)
X-Message-Number: 7
Line Length?
What is the lowest common denominator of Email Line Length? My antique
email system uses the old TTY 72 character word wrap, but I see lots of
Emails that wrap much shorter and really make things harder to read.
The above paragraph is exactly 3 lines on my screen.
If it is not received that way, then I am embarassed because I assumed
everyone receives it that way and would hate to be the routine poster of
messed up email. ALso, I frequently use text colums:
Column 1 Column 2 Column 3
-------- -------- --------
D1 D2 D3
D4 D5 D6
D7 D8 D9
Is it unreasonable to expect it to show up perfectly in other's Email?
I suspect too many people use variable width fonts these days to expect
that..
Bob
(using PINE Email)
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
