| |
ZL3AI > APRDIG 06.06.03 15:01l 87 Lines 3356 Bytes #999 (0) @ WW
BID : 1434-ZL3AI
Read: GUEST
Subj: TAPR Digest, May 31, 8/8
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<ZL2TZE<ZL3VML
Sent: 030605/1359Z @:ZL3VML.#80.NZL.OC #:1730 [Chch-NZ] FBB7.00i $:1434-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: D7 not capable of full Voice Alert?
From: "Jeffrey P. Nast" <jpnast@lca.duluth.mn.us>
Date: Fri, 30 May 2003 22:23:34 -0500
X-Message-Number: 44
I ran into the same thing. After a little research on the internet
(http://www.eecis.udel.edu/~dra/pl.html) I reached an epiphany... Use the
CTCSS setting.
* Tone is encode (transmit) only
* CTCSS is encode/decode (transmit/receive).
-Jeff
kc0mks
----------------------------------------------------------------------
Subject: Re: APRS Internet System Design Philosophy
From: "Dave Anderson" <dandersn@citicom.com>
Date: Sat, 31 May 2003 23:41:33 -0400
X-Message-Number: 45
Scott,
>I really don't see how an extra second of latency is going to
>destabilize
>the network. Seems to me like a cheap way to increase the
>servers' usable
>bandwidth by 1/3.
Your numbers look very similar to what i've seen with sniffing my server
here locally.
The other problem I see is that the PPS requirements needed to run a server
are very rarely mentioned. It seems most are only concerned with the amount
of bandwidth, and that's not the only concern SysOps should have. Your
example highlights that rather eligantly.
Right now, on my network, core4 is chewing up around 500KBytes/sec (1/3 of a
T1) of traffic. It chews up 4 -times- more packets per second (PPS) than
10MEGABYTES (6 1/2 T1's) of webserved http traffic on the same VLAN.
Dropping the quantity of packets required in regards to the amount of
overhead in non-payload information would be a welcome sight, and I can
guarantee would also increase the overall reliability of connections,
especially those trying to do this on slower connections such as a modem.
The same issue applies to load requirments on the server CPU handling the
traffic, if you don't have a nic card that can offload TCP overhead, it will
also increase CPU load requirements to handle the data. For example, in my
case, with 80 users connected right now, a 2.8ghz Xeon Windows 2000 server
runs 0-1% cpu load with offloading enabled. If I -disable- offloading, it
hops up to 5%, not much, but it's also a fairly robust box. A slower server
without PCIX based nic cards would probably even see a higher difference.
In my case, it's not an issue with my server in question, a 400mhz NPE
processor in my router with CEF routing enabled and a gigabit card in the
server that does TCP offload. All I notice is the higher packet per second
numbers and about 30% more bandwidth used than a different traditional TCP
based application would require for the same payload.
Some of the servers though are running with ISP upstreams with as small as a
26xx series Cisco routers. By my math, on a 2620, a wee bit over 115 users
could potentially run the router out of the ability to process and pass
packets, suggesting they are not running a fast-packet switching system (as
was the case in one of the servers who was having major dropped disconnects
on users).
Some sort of improvment, being a "draw" between the best way to do it, and
the current method has to be easily implementable, and should have serious
consideration made. In it's current layout, as APRS-IS traffic quantity
grows, this will be more noticable.
Just my 2 cents as a network admin :).
Seeya,
Dave
KG4YZY
www.aprsfl.net
---
END OF DIGEST
Read previous mail | Read next mail
| |
