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

Captain_Crow

Passuffdu !
:-)
May be my rig isn´t strong enough to handle both, PSX and Wheramium.

Best
Steffen

MalcolmT

Hi all

For Info - works perfect for me out of the box.
My PC is i7-4770K @3.50GHz.  16.0GB Ram
I use Microsoft Edge browser, Windows 10 (64)

Thanks for the app Martin!

Malcolm

Kabbers

Thanks Martin, I'm using Whereamium, it rocks, and want to thank you. I am running it well on Win10/Chrome, I tried setting the .ini variables you document to the more demanding levels and I get a very smooth scrolling map indeed with no frame problems.

I do have a little bit of trouble reading the very small lettering on the place name labels on the MAP+LABEL map option, the letters seem to flee from me and get smaller as I zoom in to try to read them, haha, so it would be ver nice if the place name letters stayed stayed bigger but - hey - it's also totally easy to hit the Disconnect button and zoom in to read the place labels that way. Thanks again Martin - marvellous addon!

Cheers and best wishes,
Kabbers

martin

Hello,

thanks for the kind words!

Quote from: Kabbersa little bit of trouble reading the very small lettering on the place name labels on the MAP+LABEL map

There are two problems with this.

The first (idiotic) one being that I myself currently cannot run Wheramium -- the web page refuses, for unknown reasons, to load an essential script...  :(  So right now I cannot try and  test.
(I suspect it has to do with newer Firefox versions.)

More importantly: The labels are part of the map "style", which means they come with the Bing maps and are not coded or styled directly by Wheramium; the program uses the maps just "as is". It may be possible to change that, but it would at the very least require messing about with the innards of the Bing maps. Perhaps doable but would require an expansion of the existing code (and might thus violate the "keep-it-simple" approach which was the basic idea).

I'd also have to see how the Wheramium-specific zoom slider interacts (or not) with the zoom mechanism built into the maps (e.g. Does the font size of the labels adapt only to the latter?); so it's not trivial.
Luckily you have pointed out yourself the work-around.   ;)
I'll try and have another look when (if) I can get Wheramium to run again even for me...

Cheers,
Martin

Jeroen Hoppenbrouwers

You can always try stupid browser zoom, Ctrl-+.

Will

Update. The issue with the turn radius has resolved itself. I'll report back if I see it again, but as of now it's gone; the PSX position and the Whereamium position are perfectly synched.

But I'm still seeing PSX frame rates in the teens.

Quote¤ When exactly does this slow-down happen?
   ¤ As soon as Wheramium is started (but before the webpage is loaded in the browser)?
   ¤ As soon as the webpage is loaded (but before it is connected to Wheramium/PSX)
   ¤ Only after the connection is made (and the map is now actually being updated constantly)?

It happens when the webpage is loaded.

After Whereamium is started but before the webpage is loaded, the PSX frame rate is 72.
As soon as the webpage is loaded, but before it is connected to Whereamium/PSX, the PSX frame rate drops to 18.
After the connection is made (and the map is being updated constantly), the PSX frame rate stays steady at 18.

My system is this:

i5-9400 @ 4.1GHz, cheap-ass Intel UHD Graphics 630

Which I understand is pretty bad for gaming, but it runs PSX at between 65 and 72 frames/second at all times.

Any thoughts?

Will /Chicago /USA

martin

Hello Will,

Quote from: WillAny thoughts?

Always, but alas! no helpful ones... :(

I am currently completely hobbled to make any progress on this: Not only does Wheramium itself no longer work for me, but I am now finding that I cannot even get Cesium to send me maps directly, quite independent from Wheramium/PSX, but using the same approach (via test scripts). The error message I see comes from very deep inside the Cesium jungle of scripts which are definitely beyond my "expertise" (rudimentary at the best of times); apparently some subsubsubscript is not correctly imported. Or something.

I can only speculate that "something" has changed either in the Cesium API/library/code, or with Firefox, or both. What makes it weird is that apparently others were/are still able to use Wheramium during the last days, and even today (I can see that from the Bing statistics about my access quota). So this seems to be something specific to my own setup.

As to the specific issue of the frame rate going down so much: As I have explained earlier, Wheramium does not talk to PSX (i.e. changing settings or variables, etc.) in any way; the Wheramium  PSX client merely reads the records issued by PSX and processes them without talking back.

So the only cause I can think of for the slow-down is a general load on the system which will of course also put the brakes on PSX. Have you had a look at the system load in general (with Process Explorer, Task Manager, or similar)?

One vague suspicion I have had for a long time is that Windows 10 "somehow does not like" Java, and/or that Java unduly overloads even a strong computer. But I have not been able to nail this down to a solid argument (e.g. it may be Eclipse, my dev environment, rather than Java itself).
Integrated graphics (as opposed to graphics cards) are also often suboptimal for simulations and games, I think; but I don't really believe that this is an explanation for the PSX frame rate going down so much. And as you report, the frame rate is in fact fine for PSX unencumbered by Wheramium...

So, investigations will have to continue, but it may well take some time to figure this one out.

C.....h.....e.....e.....r.....s,
Martin


Will

Well, I went into the task manager and with PSX but without Whereamium running, I get:

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

With Whereamium running, I get:

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

And the computer is universally slow; it's not just the PSX frame rates that are low.
Will /Chicago /USA

Will

Another update: Resizing the Whereamium browser gets the frame rates back into the 40's. I'm talking about shrinking it to about 3 inches across on my monitor. Unfortunately, this means the white triangle is no longer centered. But this is usable for getting around airports.

Thanks for all your work on this, Martin!
Will /Chicago /USA

Jeroen Hoppenbrouwers

Quote from: Will on Sat,  8 Aug 2020 14:54
GPU: 79%, attributed to Google Chrome.

That feels wrong, as if Whereamium directs Chrome to redraw most of the map many times per second.

If PSX does not move over the ground, does this CPU consumption change and drop to near-zero? If not, some mechanism that calculates position changes is broken (or does not exist at all).

How often per second does Whereamium try to update the map when PSX is in flight?


Hoppie

Will

QuoteIf PSX does not move over the ground, does this CPU consumption change and drop to near-zero?

No, for me the GPU consumption is the same, regardless of the state of PSX.

PSX could be in flight, in motion on the ground, on the ground with the park brake set, or even paused, and the Google Chrome GPU consumption is still about 80%.

Will /Chicago /USA

martin

Quote from: HoppieHow often per second does Wheramium try to update the map when PSX is in flight?

It's configurable (up to a point). The INI file has two entries (POLLINTV and REQINTV) which determine how often Wheramium (as a PSX client) reads the PSX data, and how often the web page requests them from Wheramium (as a web server), resp.
See doc.s for details.

Cheers,
Martin



Jeroen Hoppenbrouwers

Quote from: martin on Sat,  8 Aug 2020 18:50
... which determine how often Wheramium (as a PSX client) reads the PSX data

Hmmm. I wonder. PSX does not "answer client requests" -- it just constantly sends data. It depends on how your program has been written, but if you stop reading the pipe then PSX will pile up a lot of data that eventually all must get processed no matter what. It can, in extremis, lock PSX up as it can no longer get rid of its data and blocks on the pipe.

Now, if you always read everything but just throw it away unless your "I want new data" timeout has expired, that would be fine.

If on the other hand you stop reading for, say, 100 ms and then start reading again, you will get all data that has been piling up in those 100 ms, and you may get a large number of updates of the same variable, while you may expect just one.


Hoppie

Hardy Heinlin

As far as I recall from other forum threads, Martin uses the "read" code snippet that my public AddonExampleNetThread.java suggests:

in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
String message;
while (true) {
  if ((message = in.readLine()) != null) {
    // do something with message
  }
}


The Java function "readLine" blocks the loop as long as no data is in the pipe. So there's no overload inside the loop nor outside the loop. This works correctly in PSX and other Java add-ons. This loop must not be stopped by any other function in the add-on.

Maybe there's another while-loop around this loop when Martin's "poll" mode is active?


Cheers,

|-|ardy

Kabbers

Hi Martin, just to quickly add as well, mindful of the error you mentioned you're getting, I also had an error come up today in the Browser (chrome) about Range error - with several lines of detail. A Win10 reboot did the trick though for me, which I'm sure you've tried of course, but mentioning in case this suggests Whereamium doesn't like some other addons?

I have triggered this error twice now, from setting up PSX+NavigraphCharts via a slaved xview/XP11 hidden window, and PSX main+boost server. I figured maybe a process (e.g. simlink, or xview) from that setup, even once dismantled, might still be running in the background somewhere and interfering with Whereamium in a way I didn't understand. Could there be sometimes a conflict between Whereamium and other addons was the small offering here... best, Kabbers

martin

Greetings,

[There's a reason why I have always tried to keep away from network stuff. Breaking that vow, in order to make PSX add-ons, seems now to have come back to haunt me... :o]

Quote from: Hoppie...if you stop reading the pipe then PSX will pile up a lot of data that eventually all must get processed no matter what.

This idea of "clogging the pipe" I don't understand. My perception has always been that PSX broadcasts (in the general, not the network protocol sense) the data without paying the slightest attention if someone is listening or not. ("If a TCPIP packet is sent and no one receives it, is there still a packet?"). After all, I can run the PSX servers without running any client taking them, and even then no pipes or buffers will fill up and eventually choke PSX. Or?  On the other end, as Hardy says, the client will "take" data only when it feels like it, but the ones ignored in between won't accumulate anywhere. Or?

Quote from: HardyMartin uses the "read" code snippet that my public AddonExampleNetThread.java suggests
Correct, that code was lifted from there.
Here is the full run() method code, in case I have somehow ruined the example; but there are at least no surrounding loops:

public void run() {                                                             
   try {                                                                     
     socket = new Socket(hostName, portNumber);                             
     ou = new PrintWriter(socket.getOutputStream(), true);                   
     in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
   } catch (UnknownHostException e) {                                           
      [...]    );                                                             
      return;                                                                 
   } catch (IOException e) {                                                 
      [...]
      return;                                                                 
   }                                                                         
                                                                             
   try {                                                                     
      String received;                                                       
      long lastTime = 0L ; // !!                                             
      while (true) {                                                         
         received = in.readLine() ;                                           
         if (received != null) {                                             
            try {                                                             
               if (received.length()<5) continue ;                           
                                                                             
               if (System.currentTimeMillis() >= (lastTime + POLL_INTERVAL)) {
                  try {                                                       
                     recBoost = received ;                                   
                     lastTime = System.currentTimeMillis() ;                 
                  }                                                           
                  catch (NumberFormatException nfe) {                         
                     [...]                                   
                  }                                                           
               }                                                             
            } catch (StringIndexOutOfBoundsException sioobe) {               
               [...]                                     
            }                                                                 
         } // if received                                                     
      } //try                                                                 
   } catch (IOException e) {                                                 
      //                                                                     
   }                                                                         
   finalJobs();                                                               
                                                                             
} // end run() 



Moreover, I vaguely recall (needs re-verification, but at the moment I can't do that, for the reasons given above) that this CPU overload is not generated by the interaction between PSX and Wheramium anyway; I seem to remember that the load increases so much only when the webpage is connected to Wheramium, and thus the web server function of Wheramium comes into play. Or it could even be the mere Cesium stuff running in that webpage, never mind the connection to Wheramium. This, too, would need further investigation. If I can get the add-on to run for me again...

Quote from: Kabbersthis suggests Whereamium doesn't like some other addons?

I don't see how Wheramium can even be aware of any other add-ons running. The only mechanisms for that I can think of are either a general overload of the system (which will of course affect all add-ons), or perhaps a port conflict (two or more add-ons happening to try and use the same port).

In general, two aspects are bothering me:

For one, some people seem(ed) still to be happily (or at least unhappily) running Wheramium, possibly without issues. It's not clear to me if this "overload" problem affects everyone, and some are simply not disturbed by it, or if it happens only on some systems but not others.

More importantly: The precursor of Wheramium is PSX_Tellurium, which is quite a bit more complex (3D views etc.). But on my previous computer (i7-3700, 4 cores) I could run it under Windows 7 without seeing any of these CPU overload/overheat problems. These occurred only when I tried to run Tellurium on my current box (i7-8700, 6 cores, Windows 10).
(In fact, this was the original motivation to make the simpler Wheramium, see third paragraph of first post in this thread. I was hoping the simplification would alleviate the problem, which apparently it does not, alas.)

Cheers,
Martin

Hardy Heinlin

QuoteMy perception has always been that PSX broadcasts (in the general, not the network protocol sense) the data without paying the slightest attention if someone is listening or not.

No, not when using TCP/IP. There are two phases:

Phase 1: The server has started listening for client connection attempts.
Phase 2: Whenever a client connects, the server starts another multitasking thread just for that new client.

The server only sends data when at least one client is connected.

The client has to read the buffer permanently because, according to the TCP "contract", every data package sent by the server must be received by the client.

I see no problem in your code snippet, but where inside that loop do you process the incoming data? If this process takes longer than a PSX time frame, e.g. longer than 14 ms (at 70 fps), the buffer will accumulate more data than your loop can read. If this problem occurs 70 times per second, the buffer may reach its limit pretty quickly.

I would run two independent loops in two separate threads. One loop reads the buffer without any delay and without any further process. The other loop may run at any frequency and copy the latest data from the buffer loop whenever it wants to, e.g. every second or every Friday.


Regards,

|-|ardy

Jeroen Hoppenbrouwers

Quote from: martin on Mon, 10 Aug 2020 08:40
Quote from: Hoppie...if you stop reading the pipe then PSX will pile up a lot of data that eventually all must get processed no matter what.

This idea of "clogging the pipe" I don't understand. My perception has always been that PSX broadcasts (in the general, not the network protocol sense) the data without paying the slightest attention if someone is listening or not.


I agree with your analysis that this is most likely NOT the reason why Whereamium locks up some machines, but I can explain why it is important to think about this kind of stuff nonetheless.

Slightly simplified, there are two kinds of network links:

1. UDP - truly unreliable data packets, that are fired by the sender and may land somewhere, or not.
2. TCP - reliable byte streams, where both sides can be assured that all bytes sent, were received, in the same order.

The price to pay for the reliability of TCP is performance. Reliability requires a lot of back and forth handshaking and this leads to much more network traffic (overhead) than UDP. If raw performance over the wild internet is important, such as for streaming audio and video, while it is possible to bridge occasional gaps in the stream, UDP is preferred. The same holds for severely underpowered equipment.

However when power is not a problem and the line is by itself reliable, such as in Ethernet linking home computers, TCP will work brilliantly and makes life simpler.

PSX uses only TCP for these reasons.

Now, if PSX would use UDP, your reasoning that a sent packet that was never received would not hurt, would be true. PSX would launch packets all the time and if nobody wants to read them, the packets expire when they reach the end of the network. Like sound waves.

But TCP is reliable. PSX (the operating system on which it runs, actually) is not going to rest until it gets confirmation that the bytes it has sent, have been correctly received. TCP is connection oriented. You open a pipe and from then on, either end of the pipe can rely on it working completely, or not at all (broken pipe). The operating system has buffers to absorb small network irregularities, but  these buffers are not infinite.

So if your client opens a pipe and PSX starts pressurizing the water hose, your client is required to read all bytes that PSX pumps into the hose. Else, eventually, PSX won't be able to pump more bytes and the operating system will block PSX to avoid losing bytes. It is fine if your client reads the bytes and then promptly throws them away. This is how you treat PSX data streams: you read it all, and then ignore what you don't need.

If you run PSX connections over the wild internet, this is occasionally an issue. If the long line snaps, or is stepped upon for a moment, the PSX server may encounter full buffers and literally stop for a while. This problem can be solved by inserting one of the PSX Routers into the stream between the server and the wild internet. The Router will absorb the blockage and keep the server pumping freely.

If somebody really wanted, (s)he could write a PSX Router that connects to PSX over TCP and to another router over the wild internet via UDP. This would allow two PSX instances to sync up when able, and run independently for a while when needed.

Hence ... if you write a TCP socket client, you must assure that you read whatever bytes appear often enough, to avoid the far end buffer running full. Typically this is done by setting your socket as non-blocking, and implementing some kind of interrupt-driven handler that wakes up as soon as there is something to read. Since PSX uses linefeed separated streams, it is totally okay to have your client accumulate one line of bytes before it interrupts your program. This makes for a one-line buffer, which is never going to block the sender as TCP buffers are in the order of dozens of KiB on most systems.

What typically also works, but is not recommended, is to have your client periodically check whether there is something to read. This blocking mode operation works if you poll often enough, but causes a lot of useless looping around if there is no traffic, and causes stop and go processing if there is traffic.


Hoppie

martin

Very good clarifications, thanks!

But (apart from the Wheramium issue; this is now mere curiosity) they don't quite cover (or at least not explicitly) the case where there is no client.
What does the server then do?
My idea (probably wrong, as I now realise) has always been that it is emitting data anyway. In the light of your explanations it is more probably so that if there is no client, there is no connection, and the server serves nothing. Correct?

[EDIT] Actually I should have known that (RTFM), it's in the Java tutorials (I just haven't paid enough attention to the server side. And of course the  moment you "look", you are a client and the server starts serving, so you'll never catch it waiting...  ;D):

Quote from: Oracle...the ServerSocket object is successfully created and the server continues to the next step — accepting a connection from a client [...]:
   clientSocket = serverSocket.accept();
The accept method waits until a client starts up and requests a connection on the host and port of this server. [my bold]

Cheers,
MMMM.... <---->   

Hardy Heinlin

Martin, did you read my reply #76? :-)


|-|ardy