| |
ZL3AI > APRDIG 25.07.03 08:56l 242 Lines 12304 Bytes #999 (0) @ WW
BID : 1665-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jul 22, 6/7
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<VK6HGR<ZL2BAU<ZL3VML
Sent: 030724/1124Z @:ZL3VML.#80.NZL.OC #:4920 [Chch-NZ] FBB7.00i $:1665-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: Running aprs in the car with a laptop
From: "Jerry Halmbacher" <halmbacher@swtexas.net>
Date: Tue, 22 Jul 2003 20:27:49
X-Message-Number: 38
I got a very expensive (over $100) DC-DC inverter called iGo Juice thinking
it would solve the RF problem. Not so. It puts out more RFI than the cheap
DC-AC inverter, at least on HF. No problem with VHF though.
Jerry Halmbacher
KD5SGT
----------------------------------------------------------------------
Subject: Reality check needed re uptimes and a soapbox rant, like it or not.
From: "Dave Anderson" <dandersn@citicom.com>
Date: Tue, 22 Jul 2003 21:55:31 -0400
X-Message-Number: 39
>I don't think Phil was being vague about anything. SECOND has been up and
>running continuous for more than 55 days. Yet, the longest connected user
>has only been there for 2 days. FIRST has been up for 12 days and only 1
>user has managed to stay connected for the same time period. FOURTH has
>been up 5 days, and 2 users have been there as long.
I try to stay out of this debate, however, being a Cisco CCIE and a 13 year
ISP veteran, i'm not going to sit back on this one, especially given the
current events of the network. I have to get on my soapbox first. My
appologies for this much needed soapbox rant. This is not politics,
mudslinging - this is technical. If it's over your head, i'm sorry.
There's tons of reading you can do about eBGP routing and how route peering
on the internet works. Trust me, you'll spend alot of time reading, and
then you'd understand the content of my following statement....
First.....................
This is a -HORRIBLE- week to even begin evaluating user uptime -ANYWHERE- on
the internet. We currently have one of the the -LARGEST- Cisco
vulnerabilities on the radar in history, and just about -EVERY- Cisco router
(which routes 90+% of overall traffic) on the net needing to be updated on
said routers. This is a arjious task, given the shear quantity of routers
affected by this. Read the following to understand why the FBI cyber
terrorism group has rated this vulnerability a level -HIGHER- than the Code
Red virus which took the net to a CRAWL a few years ago:
http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml
You can't base uptimes and stability of -any- connections when the amount of
route flapping and router rebooting is taking place. We're seeing record
quantities of route flaps on the net, and these flaps of huge quantities are
causing latency large enough to cause end clients to disconnect from a
server. That's the problem with a real time protocol such as APRS when you
are dealing with a unstable backbone mesh. My uptime count is only based on
I've had the 4 routers between that server and my THREE DS3 internet
connection across UUnet AT&T and Sprint rebooted with fixed code installed
this past weekend - and it causes all to disconnect during that reboot time.
I will not even mention the non stop list of maintenance messages posted in
the nanog (north american network operators group) from carriers doing the
same.
Second....................
Uptime in -any- capacity is going to greatly be affected by the end users
ISP policies. Many ISP's to keep you from abusing your broadband connection
will traffic-shape your connection, which essentially pools your data in a
router queue to slow the speed of packet delivery to a speed they specify.
Again, downloading a file, this just is represented by a speed cap. When
you are doing a download - AND being connected to a APRS-IS server, whether
you're on a filtered port only listening to -ONE- station or picking up the
entire feed, you have the potential of getting dropped if your output queue
on the said APRS-IS server gets backlogged. The nature of APRS real time
traffic simply makes this a possibility.
Pete, this is not targeted to you, but with your expertise, you should be
able to understand my point here --- when you need real time traffic across
a open WAN such as the internet, and using TCP connection oriented protocol,
drops will occur. TCP simply was never meant to be real time. That is one
of the reasons VOIP and other latency sensitive applications do not use the
TCP protocol. This is more of an explaination, so please don't take it as a
stab, it's not by any mean.
Bottom line. There is no perfect system. Every server, be it core, tier2,
mickey mouse, or na-na's server will have problems from time to time. Data
centers with farms of thousands of servers have been trying to get 100%
reliability for years and spending millions to do so. It's almost a
unattainable goal. Even with all the redundancy in my network, the best I
could do last year was 99.999% uptime (the gold standard) - but do the math,
it's still -more- time than you think.
I've had a bad NIC card in my aprsfl box which was causing dropped packets,
and drop users when I first setup aprsfl.net, I'll not even get into the
difference between multimode fiber and single mode fiber, but let's say that
gigabit over fiber does not like light refraction, and that caused my
problem. And that's --cutting-- edge gear. It can happen to anyone running
a server.
My biggest bitch at this point about my server is that I will most likely
bail running Windows for my APRS server --- every security update requires a
reboot, which knocks everyone off. Running on a Linux environment I can
patch the box and never knock anyone down.
Just my opinion. Before anyone goes off bashing any server or any system
beit core or tier 2, you need to have a true understanding of what happens
to the packets and more importantly how the packets of the APRS-IS stream
work. If you truly understand this, you'd understand that no matter what
you call your server, you are bound to run into issues occasionally.
Also -- the world is big enough for all the servers to exist. Each offers
benefits, each offers features, each offers different levels of reliability.
Remember, I started as a tier 2, moved to a core, now calling my self just
APRSFL, not "four". Think of it this way, if everyone that had a internet
connection connected to the same carrier the internet would collapse. There
is room for everybody. Let's work together to make APRS as a -WHOLE-
better. This non stop childish "mine is better than your" bull that I've
been reading since becoming a ham is becoming tiring. It's building walls
that do not need to be there. Let's move on.
All I know is that I take -great pride- in how aprsfl.net runs. I go to
great lengths to make sure it's as reliable as possible. Call it whatever
you want. As I've said before, I don't care about a server title. It
stands on it's own as www.aprsfl.net. As you all know, I don't
differentiate. ANYBODY can connect here.
Off my soapbox.
Seeya,
Dave
KG4YZY
www.aprsfl.net
----------------------------------------------------------------------
Subject: RE: Reality check needed re uptimes and a soapbox rant, like it or not.
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Tue, 22 Jul 2003 21:26:58 -0500
X-Message-Number: 40
>-----Original Message-----
>From: Dave Anderson [mailto:dandersn@citicom.com]
>Posted At: Tuesday, July 22, 2003 9:02 PM
>Subject: [aprssig] Reality check needed re uptimes and a
>soapbox rant, like it or not.
>
>Pete, this is not targeted to you, but with your expertise,
>you should be able to understand my point here --- when you
>need real time traffic across a open WAN such as the
>internet, and using TCP connection oriented protocol,
>drops will occur. TCP simply was never meant to be real
>time. That is one
>of the reasons VOIP and other latency sensitive applications
>do not use the TCP protocol. This is more of an
>explaination, so please don't take it as a stab, it's not by any mean.
You are absolutely correct. That is why I didn't mention anything about
drops. I have watched (always with a subtle smile) Cisco claim that
VOIP over the Internet was going to replace the class 5 and 4 switches
(the switches at the telephone companies' central offices and those that
connect the CO's to the long distance carriers). For the reasons you
stated, something major will have to change for the VOIP over the
Internet to even begin making inroads.
The near real-time nature of APRS-IS not only puts a bandwidth load on
the ISP; it puts a packet load on the ISP's router(s). These are just a
couple of reasons why one cannot simply look at the average bandwidth of
the data portion of an APRS-IS feed and make definitive statements about
the affect on the connection. Like your statement, this an explanation
for those following this thread, not a jab as you have noted this in the
past.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: Re: Reality check needed re uptimes and a soapbox rant, like it or
not.From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Tue, 22 Jul 2003 21:52:52 -0500
X-Message-Number: 41
>AND being connected to a APRS-IS server, whether
>you're on a filtered port only listening to -ONE- station or picking up the
>entire feed, you have the potential of getting dropped if your output queue
>on the said APRS-IS server gets backlogged. The nature of APRS real time
>traffic simply makes this a possibility.
The biggest problem with this premise is that it is not true. It is
rediculous to drop a connection based on backlog. If you are doing this at
the application level, then you are 1) ignoring TCPs ability to do this for
you and 2) don't understand how to build a fault tolerant distributed
system. The servers should flush the queues and maintain the connection
until TCP says it's gone. This can be a long time, if the machine is
removed from the network completely and noone is sending back ICMP messages
about the host route being lost.
It is perfectly possible to create UDP like behavior over TCP using
windowing protocols. What is at issue is that the APRS stream is ill
designed. A simple TCP stream is powerful, but not enough to create a
distributed system. If you look back at many of the serial data transfer
protocols such as kermit, and before that, X/Y/Z modem, you will find
design principals which help to make data transmission bandwidth efficient.
I've discussed my thoughts and ideas on an APRS-IS backbone that completely
eliminates the TCP path between nodes by letting the user put a proxy
server on their machine that their existing software can connect to with a
simple TCP stream. The proxy server then utilizes the distributed systems
technologies that work to create a reliable stream environment. Leasing
comes into play whereby the proxy reserves its right to stay connected to
the server. A windowing mechanism would allow the proxy to acknowledge the
current sequence in the window. This would let the server know that data
is still flowing. It could then not burden the kernel with too many
outstanding packets. Bursty network performance caused by rerouting, router
rebooting and other issues can create problems if you are not using end to
end acknowledgements. Both windowing and leasing (timeouts) are important
parts of data distribution over long haul, unreliable networks.
>Pete, this is not targeted to you, but with your expertise, you should be
>able to understand my point here --- when you need real time traffic across
>a open WAN such as the internet, and using TCP connection oriented protocol,
>drops will occur. TCP simply was never meant to be real time. That is one
>of the reasons VOIP and other latency sensitive applications do not use the
>TCP protocol. This is more of an explaination, so please don't take it as a
>stab, it's not by any mean.
I think the argument was about connection reliability not 'real-time'.
These are distinctly different issues...
>Bottom line. There is no perfect system.
Currently there is no perfect system, but there can be a system that is
much better than what currently exists, and people trying and experimenting
with new concepts is how we will achieve a better quality service...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
