News:

Precision Simulator update 10.173 (24 February 2024) is now available.
Navburo update 13 (23 November 2022) is now available.
NG FMC and More is released.

Main Menu

NEW: PSX_Wheramium, a moving map

Started by martin, Sat, 21 Mar 2020 16:32

martin


Quote from: HardyMartin, did you read my reply #76? :-)

Sorry, I had missed that*  :(

Quote from: Hardywhere inside that loop do you process the incoming data?

The PSX data record (line) is not really processed at all; it is forwarded "as is" to the web page (Wheramium now acting as web server), and then parsed there, with Javascript.
But the timing for polling PSX is still in that Java-side loop indeed, and perhaps that should be rectified according to what you suggest.
With Hoppie's and your help I understand now the potential "constipation" problem; and I can see why e.g. "buffer full" might become an issue. But could this also lead to the CPU "overload"?
(Even if it's not quite real overload; perhaps it's just that I am not used to such high loads and temperatures.)

Thanks to all for the comments. The next episode will address  Kabbers's original problem!  :D

Cheers,
Martin


* Too many things going on at once (I don't like, and am no good at, multitasking...). I had tried to run the old Tellurium so as to get a baseline on things, but that threw now even weirder errors never seen before...

Will

I think it's interesting that my CPU and GPU get overloaded when I put the Whereamium URL in the browser, but before Whereamium starts drawing the map. This is when the overload starts:

Quote¤ As soon as the webpage is loaded (but before it is connected to Wheramium/PSX)

Maybe it falls into some loop that's unrelated to actually fetching data from Cesium?

Also, are we thinking that this happens to everyone, but only those of us with low-powered systems can actually see it?

Martin, I think this is probably what led to your overheat situation. The percentage load numbers aren't static, they bounce around, and so there are times my CPU goes to 100% and stays there a while before falling back to 90% or so.
Will /Chicago /USA

martin

..and back to the original question about the font size of the map labels. I have now been able to get Wheramium working again for me, too, and have had a look.

As I suspected, this is a Bing Map thing. But what I see (in Firefox) is a bit different from what Kabbers describes:

If I zoom out (using the slider)  further and further, the font initially becomes smaller indeed.
But at some point it does a little jump and becomes bigger again. If zooming out is continued, the font shrinks again, then does another jump and grows again.  Sometimes even some of the labels are "still" small, while others are "already" bigger again.
So for me at least it never becomes really tiny and thus illegible.

See this picture  and note the name "Lisse" and also the respective zoom factor displayed above the slider (smaller = more zoomed-out). These screenshots are all at the same scale, only the map changed.

(Click on the picture for full-sized version.)

Two conclusions:

There is not much I can do about this (unless I would attempt deep surgery on Bing maps, but I am not sure if that is even possible to that degree).

But what at least I see does not actually need any change.
(Unless it is a browser issue, and Chrome behaves differently from Firefox, in which case I can do even less about it...  :D)

Cheers,
Martin

martin

Quote from: Willmy CPU and GPU get overloaded when I put the Whereamium URL in the browser, but before Whereamium starts drawing the map.

Thanks for the comments, Will. There is definitely something not right (and never was), and now that I can run Wheramium again (sort of), I'll try to have another look. The difficulty is that this requires juggling Java, Javascript, HTML, TCPIP, Bing maps, and especially the rather vast Cesium cosmos, where of course the last two components, being located on the Internet,  can change any time...

Cheers,
Martin

Jeroen Hoppenbrouwers

I would suggest to equip the very first piece of code that catches PSX data with a simple filter, to weed out all the masses of data you are sure you do not need. And only pass what you do need to JavaScript.

JavaScript running in a browser is lots of things, but not a speed monster for data crunching. I am not surprised that you can heat up your CPU by processing a full PSX data feed in a web browser while attempting to also process Bing maps.

If you program a master switch into your PSX data catcher that allows it to either pass filtered data on to the browser, or simply throw all incoming data away, you have a nice test facility to see where the heat comes from.


Hoppie

Hardy Heinlin

#85
Quote from: martin on Mon, 10 Aug 2020 19:43
The PSX data record (line) is not really processed at all; it is forwarded "as is" to the web page ...

It shouldn't be forwarded. There may be a long process in that external web page code. That external process happens within your primary loop thread if your forward command sits within that loop.

The only process within your primary loop should be a string copy from the readLine function. You don't even need a text filter because the boost network sends just one variable anyway (no Q vars like in the main network).

There should be a secondary loop thread. This may run at any frequency you like, e.g. 30 Hz. Inside this secondary loop you copy* the latest received string from the primary loop. Also, inside this secondary loop, you forward that copied string to the external web page. If that web page takes a long time to process the data, it doesn't matter; the next cycle of that secondary loop will just start a bit later -- it won't affect the timing of your primary loop because you now have two independent threads (primary and secondary).

* using a thread safe method


Cheers,

|-|ardy

martin

Thanks to both of you, all good advice!

Quote from: Hoppieequip the very first piece of code that catches PSX data with a simple filter

A filter is not really needed, I think: what comes from the PSX Boost server is just one string anyway. Which is later (currently in Javascript) simply split into pieces, and the coordinates are then picked out.
But that operation should perhaps not happen on the web page / Javascript side indeed, I had already had my suspicions in that direction. The difficulty is that it's not immediately clear if the Javascript-side load comes from my code (which I can change) or from the Cesium stuff. But I'll do more tests to figure that out.

Quote from: HardyIt shouldn't be forwarded.
"Forwarded" was an unfortunate term perhaps. What happens is really just that the string coming from PSX is copied to a variable (recBoost), and that is then sent to the web page where Javascript splits it up and processes the coordinates.
But I'll also follow up your tip about a secondary loop (as soon as I get my head around "thread safe". I know what it means but knowing what it means and actually applying are two different things. At heart I am still a procedural monothread guy with some inkling of object orientation from the happy Algol68/SIMULA days...  :D).

Cheers,
Martin "The Threadunsafe" E.

Hardy Heinlin

#87
Quote from: martin on Tue, 11 Aug 2020 07:35
... and that is then sent to the web page ...

Hehe :-) We're moving the meaning of a word further but the actual problem remains the same. Not "processed" but "forwarded"; not "forwarded" but "sent" ... :-)

Where in the loop does your "send process" start? Is it just this?

recBoost = received;

Is there another thread outside your primary thread that does something like this?

finalCopy = recBoost.toString();


By the way, if you code this recBoost = received; then you just copy the string address but not the content of the string. To copy the content, you need to use the .toString() function or something similar.

"Thread safe" means this: While thread A is reading string X, thread B cannot overwrite string X. Only one thread can read or write string X at a time. Otherwise, if thread B were changing the string content from "hoppie" to "martin" while thread A is reading the string, thread A may get a random result like "marpie", for example.


Cheers,

|-|ardy

martin

Thanks!

Quote from: HardyHehe :-)
Semantics are always fun (as well as an excellent Excuse of Last Resort)! :-)

Quote from: Hardyyou just copy the string address but not the content of the string
readLine() delivers type String, and both received and recBoost are of type String, too*, and I still have to convert?
OK, they may all be swapping the address and not the string literal, but does this make a difference here? What later arrives in Javascript (see below) is still the correct literal, not an address.
       * the difference being that received is local and recBoost is protected, thus accessible by other classes.

What happens is this:
The recBoost variable can be accessed by the Wheramium web server class, and as soon as the latter GETs a request from the web page, it serves this string (after prefixing it with a HTTP header).
The real issue at the background of all this is that I need communication between Java (the PSX client part of Wheramium) and Javascript (web page and scripts), hence the built-in web server; but all that is very unfamiliar territory to me.
That's also the reason why I send the whole PSX "record" to the web page "as is" and do the parsing into coordinates there, in Javascript. As Hoppie says, probably a bad idea with regard to performance, but if I do the parsing on the Java side already, I'd then have to send several pieces of data to Javascript, probably each via its own GET request and HTTP server reply (at least that is the only way I could think of).

But we digress... The non-Update to follow will explain how I got rudely returned back to real problems...

Cheers,
Martin

martin

(Non-)UPDATE

While exploring new ways to mess with the Wheramium code, I have now been hit, again, by a computer crash, as was frequently the case in March already (but never since, after I stopped working on this project!).

In "end-user mode", running just PSX + Wheramium (from JAR file) + web page, all is well, and even the CPU temperature remains within reasonable boundaries (for now -- this may however have to do with the choice of PSX situ to test with, or with the zoom level applied, etc.)

But in "developer mode", which means running PSX + Eclipse* + Wheramium from within Eclipse + web page, all still goes well for a while, but then, after a seemingly random interval of a few to many minutes, the crash hits (not just BSOD or CTD, but machine shutting down, and requiring Power button for restart.)
     * Eclipse being the Java IDE and itself a Java application

So, the same thing as with the earlier Wheramium work.

I am sharing all this only by way of a warning to everyone concerned with Wheramium and potential updates:
Do not cease respiration!
(Don't hold your breath...)

I'll keep trying for a while longer, but it's possible I have to give up; I can currently not afford to embark (again) on a meta-project to identify (let alone fix) whatever may cause these crashes. Nor do I wish to "experience" another 24 crashes or so over the next four weeks...

So don't be surprised if/when further updates are not forthcoming.
Sorry!

Cheers,
Martin "The previous system shutdown was unexpected." E.
(the only "error message" the Win10 Event Log is offering to help with crash diagnosis...)

Hardy Heinlin

Quote from: martin on Tue, 11 Aug 2020 11:20
OK, they may all be swapping the address and not the string literal, but does this make a difference here?

I wouldn't rely on that either; it doesn't look thread safe to me. I'm not sure if the address change runs so fast that  the address data can never be garbled at the receiver's side. When it runs for, say, two hours at 70 fps, the address will change half a million times. There's a real chance that you get garbled address bytes, I think.


Best wishes,

|-|ardy

martin

Greetings!

Following the discussion above, and crashes notwithstanding, I have managed to produce a Wheramium "version 02" which may or (more probably) may not make a difference. See the first post in this thread.

I am not at all sure that this really improves the performance, but did find that I can run Wheramium with REQINTV=50 (= 20 Hz; noticeably smoother than the value of 100 I used previously), with CPU load and temperature staying within reasonable limits. The question is however if this is really due to the changes made, or just plain good luck e.g. with the selection of the situ for the (one!) test I did ("Basic 020 - Descending to 10000 ft").
So you'll have to try it yourself and form your own opinion. :-)

The plan is that no further development or updates will be inflicted on Wheramium (the crashing thing is just too inconvenient).
But if you run into any serious new problems, let me know anyway, and we'll see what can be done.

Have fun!

Cheers,
Martin "Hertzliche Grüße" E.
Wheramist (ret.)

Will

Thanks for your efforts, Martin. I'll give it a try tonight and report back.
Will /Chicago /USA

vnangli

#93
Just checked "Where am I umm"...Works perfectly...Thank you.

I am glad I spent the time this morning to explore this addon..

Thank you again

Just editing my previous comment. The .ini file was having 10749 as the port and the Preference in my PSX instructor shows 10747, but the html page was capturing the position well...Am I missing anything here??

Now can I use my iPad safari page to use "whereamium" ??
747 is not an airplane, it is a symbol of inspiration....

Hardy Heinlin

Main server: 10747
Boost server: 10749

Whereamium uses the boost server.

vnangli

747 is not an airplane, it is a symbol of inspiration....

Will

#96
Hi martin, thanks for this update! I see an improvement.

Before Whereamium:

CPU: 22%
Memory: 36%
GPU: 11%

With Whereamium v.1 running, I get:

CPU: 92%
Memory: 44%
GPU: 79%, attributed to Google Chrome.

With Whereamium v.2 running, I get:

CPU: 59%
Memory: 39%
GPU: 78%, attributed to Google Chrome.

As you can see, GPU is about the same, but CPU is significantly lower. This translates into frame rates on PSX of about 42, which is acceptable for taxying around the airport.

Will /Chicago /USA

martin

Quote from: vnangliNow can I use my iPad safari page to use "whereamium" ??
It "should" work as long as the Safari browser can access the Wheramium URL / web page and Bing (for the maps), i.e. no firewall etc. in the way. That web page includes a lot of Javascript, though, partly my scripts, and much more from Cesium. It still "should" work, but as we know, Apple is often a law unto itself, so they may have different ideas.
In any case, it's worth a try.

Good Luck!
Martin

martin

Quote from: WillI see an improvement.
Good news, thanks for the feedback, Will.

Quote from: WillGPU is about the same
Probably to be expected as that will be the rendering of the maps (Bing via Cesium), which has of course not changed at all in v.02. [emphasis added]

Quote from: Willframe rates on PSX of about 42, which is acceptable for taxying around the airport. (emphasis added)
As we know, 42 is the answer all right, but that statement can only come from someone who has not received his flightsim education starting with SubLogic FS1 ...  ;D

Cheers,
Martin

vnangli

#99
Quote from: martin on Fri, 14 Aug 2020 08:16

In any case, it's worth a try.

Good Luck!
Martin

I can be your "TEST PILOT"  :D.

I used the URL "http://localhost:10314/PSX_Wheramium.html". And in the place of "localhost" in the URL I instead used my IP address of the machine running the PSX. Worked like a magic on my iPad. And I used SAFARI

BTW, I also have a Google Chrome browser on my iPad. It works seamlessly there as well....

Martin, this is very exciting...Thank you
747 is not an airplane, it is a symbol of inspiration....