OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   08.02.04 14:52l 267 Lines 10750 Bytes #999 (0) @ WW
BID : 2797-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 05, 7/7
Path: DB0FHN<DB0RGB<DB0AAB<F6KFT<DB0GE<DB0GH<F6KMO<ON0AR<ON0AR<LU6DTS<
      W4JAX<VK4TUB<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040208/1134Z @:ZL3VML.#80.NZL.OC #:18657 [Chch-NZ] FBB7.00i $:2797-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: Re: maps
From: Steve Dimse <k4hg@tapr.org>
Date: Thu,  5 Feb 2004 21:34:02 -0500
X-Message-Number: 48

On 2/5/04 at 9:13 PM Vince <heffer@mindspring.com> sent:

>Yeah, that's the way.  Skulk around like a thief in the night.
>
>What would it hurt to ask mapblast what happened, or ask them
>for privs to use their maps. Especially since amateur radio here
>in the states seems to be part of the latest "home security"
>contingent.

Over the last four years, I sent perhap 10 emails to them, they never
bothered to send a reply. Not surprising, another map service quoted me
$250k/year for 1 million maps/month (and had no interest in the public
service or non-profit angles).

MapBlast was without doubt aware of what was going on (or else they had
grossly incompetent web managers), as each http request includes a refer
line. While the requests actually came from all user's IP, the referer
field always pointed to findU.com. Hard to miss millions of hits/month!

In Microsoft, there will be even less of an interest. The last thing they
want to admit is there is any need for any communication mode other than
Microsoft products via the internet. The admission that ham radio might
fulfill a niche runs counter to their philosophy. Also, since there is no
non-profit incorporation for APRS, there is no way for them to write off
the contribution.

I'm not going to waste my time pursuing this. The only answer is to roll
our own system. I'm writing something up to float tomorrow, stay tunded...

Steve K4HG

----------------------------------------------------------------------

Subject: Re: maps
From: Steve Dimse <k4hg@tapr.org>
Date: Thu,  5 Feb 2004 21:48:34 -0500
X-Message-Number: 49

On 2/5/04 at 4:32 PM Jeff King <jeff@aerodata.net> sent:

>Tit for tat aside, the  fact that FINDU is having a problem validates my
>point. You have no drop-in replacement to solve the problem. Nothing is free
>in this world, and if you depend on single source to freeload massive amounts
>of bandwidth, their will be disruptions and continued scrambling to fix them.

I've been depending on the single source because it works, and it is simply
impossible to come up with an affordable alternative to MapBlast. The data
we would need, even if given a unlimited amount of programming, bandwidth,
and hardware resources, would cost far more than APRS could afford...we
couldn't even buy the Canada data!

>BTW, the tower analogy works both ways. When designing a RF system, do you go
>with a big hooting tower (big pipe) or lots of smaller towers on folks that
>have vested interests (hams or small servers). It was my understanding, that
>basically APRS is designed on this principle and by and large, high profile
>digi's are frowned upon.

Actually I'd disagree. The APRS system was built in three phases...first
with a haphazard network of low, mostly home digis, followed by high, long
range digis. It was only after the APRS Internet System became the primary
transport medium that there has been some return to the lower digi model,
but in this case it is carefully managed regarding the placement of the
digis and Igates.

>Not unless they want you to take recourse against them, this would be a
>violation of contract law.

Maybe you never heard about bankruptcy??? Many co-lo sites have gone under!

>>>If your going to (re)design a system to service a non-profit hobby
>>>market, you want to remove choke points in the system, be they
>>>technical, political or monetary.
>
>>To me, the issue is no different than the ancient ham dilema of
>>tower space. Hams generally can't afford prime space on tall towers,
>>yet they usually get it donated,
>
>Right, but that has nothing to do with FINDU. AFAIK, you are using the
>MAPBLAST servers without their express permission, i.e. a free lunch. If they
>are donating it, I'd get a short note from them saying so. That is what I did
>when I ran my hamgate at the Farmington MI library.

As I've said in many emails over the years, I've tried on many occasions to
contact them. They have either been grossly negligent not to notice findU's
use, or else do not care about it.

>>If you don't have access to high towers, or big bandwidth, then by
>>all means make use of what you have.
>
>EXACTLY. And that was my point, you need to consider that "use what you have"
>system. Distributed mapping. AFAIK, that does not yet exist.

You make this sound like distributed mapping was your idea, and yet I said
the same thing, only using a "distributed server farm" rather than DSL
based solution, just two days ago. This is the time for someone to take the
lead, are you going to do it?

Steve K4HG

----------------------------------------------------------------------

Subject: Re: maps
From: Vince <heffer@mindspring.com>
Date: Thu, 05 Feb 2004 22:08:45 -0500
X-Message-Number: 50

I understand your pain Steve.  I make my living on knowing M$ systems -
doesn't mean I like the product or support.

My comments were directed toward those who suggested going under the wire.

On the other hand, if you've only sent ten unanswered e-mails in the past
four years then I wonder your patience and knowledge. You are much smarter
than me to put together such a system as findu, but I learned long ago
their 'front' people are not in the know, nor do they necessarily forward
e-mails.

If you make a big enough stink then someone will eventually listen. All I
know is I've tried for some time to create useable maps for APRS.  And
there was a time the Net was a resource NOT controlled by big business.  As
long as we let them control it, they will.

Sure, mapblast is now a resource controlled by M$.  Does that mean
you/we/anyone should give up?  This is America.  Or maybe that doesn't mean
anything anymore.

I don't know, perhaps you have a plan that uses some maps we are not aware
of - but this is beyond my original intent, and what is known to date.  All
I know is it never hurt to ask, and M$ isn't known for their product
support people.

I'll crawl back into my cave now :)

Vince

----------------------------------------------------------------------

Subject: Re: maps
From:     Jeff King <jeff@aerodata.net>
Date: Thu, 5 Feb 2004 22:51:40 -0500
X-Message-Number: 51

And I repeat....

On Thu,  5 Feb 2004 21:48:34 -0500, Steve Dimse wrote:

>>EXACTLY. And that was my point, you need to consider that "use what
>>you have" system. Distributed mapping. AFAIK, that does not yet
>>exist.

>You make this sound like distributed mapping was your idea, and yet
>I said the same thing, only using a "distributed server farm" rather
>than DSL based solution, just two days ago.

The DSL based solution WAS in conjunction with a server farm, just not all
at the same location. But if you want full credit for it go ahead and take
it. I'm not into this for my ego.

>This is the time for someone to take the lead, are you going to do it?

Obviously, that would be impossible for me to do with FINDU, since it is a 
closed source product. Yet, as I have repeatedly stated, I was not
responding to Steve Dimse, FINDU, or the users of FINDU. I went so far as
to change the thread's title and remove any references to FINDU. Yet you
still interject yourself here.

As far as helping out, I am already helping out APRSWORLD every way I can, 
and if you don't believe me, check the contributors page. And I hope to do 
more in the near future.

Does that satisfy you and can we move on?

----------------------------------------------------------------------

Subject: some maps numbers
From: James Jefferson <jj@aprsworld.net>
Date: Thu, 5 Feb 2004 22:09:04 -0600
X-Message-Number: 52

SIG,

I did some experiments a second ago on the map rendering time on
maps.aprsworld.net. Also included are my analysis on what it takes to
supply the maps that findu needs, or at least the US maps and 1:1M maps for
the rest of the world.

I first collected 915 stations of the APRS feed that had position
information. I then asked for a regional scale map of each station.

915 stations
612 seconds to render images and return via http
average image size 17.1 kilo-bytes
612/915 = 0.668 seconds per image rendered

Re-requesting the same images and getting them out of server cache gave me:

915 stations
149 seconds
149 / 915 = 0.163 seconds per image retrieved and returned from cache

Now for street level rendering
45 stations
24 seconds
24 / 45 = 0.53 seconds per render
average image size 6.5 kilo-bytes

From cache
45 stations
4 seconds
4 / 45 = 0.089 seconds per image retrieved and returned from cache

Images were retrieved from remote machine across a 10 megabit connection so
that needs to be taken into account.

Also this is entirely unoptomized code for the wrapper around the map
rendering code. It could easily be rewritten as a C CGI or even an Apache
module and time to return a cached images could be significantly less ...
somewhere on the order of a seek and block transfer from disk. That would
be approximately 10mS. Also, the machine is a Pentium III 600 that was
purchased in early 2000. It's a single disk system. A newer machine with
RAID could probably decrease rendering times somewhat. Oh yeah, these
numbers also include looking the station up in the mysql database each time
it is rendered ... than adds at least a 10 milliseconds onto each query.

So I thought I would throw these numbers out for discussions sake.

Going a step further. Let's average the average file size of the street level
and regional (17.1+6.5)/2.0=11.8 kilobytes per average image.

I think Steve said that findu requires 1.8 million images a month.

1,800,000 maps * 11.8 kilo-bytes per map / 1024 kilobytes in a megaybte /
1024 megabytes in a gigabyte = 20.256 gigabytes per month.

Now if we assume a totally unreasonable $5 per gigabyte of transfer. (I'll
need to look on my company's hosting contract and see what we are actually
paying ... it's far less than this)

21 gigabytes * $5 per gigabyte transfer= $105 dollars per month.

<EDITORIAL>It would be easy to reduce the 1.8 million maps per month quite
significantly. Make the default page have one map that is zoomable instead
of three and now we are talking 600 thousand. Turn off the automatic
refresh and we're probably talking less than 100 thousand maps per month.
An 18 fold decrease.  Now we're talking about something that a single
machine can easily handle and would cost less than $6 a month in
bandwidth.</EDITORIAL>

Jim KB0THN

PS - I'm sure there are some math errors in there. And yes, I know, the n for
the map rendering test is probably not a good statistical sample. This is a
20 minute experiment, not a research project. Send corrections or deal with
it.

---

END OF DIGEST


Read previous mail | Read next mail


 15.10.2026 23:40:34lGo back Go up