Add option to FSUIPC to display largest contiguous VAS block?

[jabloomf1230]

Pete,

A preemptive "welcome back" and I hope that you enjoyed your holiday. Would it be possible to add an option to monitor and display the size of the largest contiguous block of VAS that is available to the sim? I found a snippet of C code online that does just that and I have been playing around with it:

http://blog.kalmbachnet.de/?postid=9

It seems that this value might be a helpful adjunct for monitoring how close the sim is to an OOM. The most recent P3d Hotfix 2 does do a better job of cleaning up VAS than previous versions, but OOMs still a problem. Or we can just wait until P3d 64 bit is released and then no one will worry about VAS anymore.

Jay

[Gypsy Baron]

That value is already available via an offfset, 0x024C, an unsigned word.

I have a small lua script that displays the current VAS when it gets below 500MB.

I also write it to an L:Var for use in another gauge I have in all my aircraft that gives

me a continuos readout of the current VAS.

 

function VAS(control, vas)

    vas_in = ipc.readUD(0x024C)
    ipc.writeLvar("L:VAS", vas_in)

	if
	   vas_in < 500000 then
	   ipc.display("VAS = "..vas_in,2)
	end

end

event.offset(0x024C,"UW","VAS")
event.timer(10000,"VAS")

  Paul

[jabloomf1230]

Thanks, but that's the amount of free VAS available, not the largest contiguous block. The problem with only displaying the total amount  of free VAS is that OOMs are caused by the sim trying to allocate an amount of VAS that exceeds the largest contiguous block of VAS that is available. This (VAS fragmentation) is why OOMs occur at a variable amount of free VAS left. 

[Gypsy Baron]

I have never had an OOM error that wasn't directly indicated by the VAS reported at the 0x24C offset. And the ones

that I have experienced were when my VAS display indicated an extremely low VAS number, well below the 500 MB threshold

I set for my VAS display to change color from white text to red as a warning.

 

 Paul

[Pete Dowson]

On 12/31/2016 at 9:35 PM, jabloomf1230 said:

Would it be possible to add an option to monitor and display the size of the largest contiguous block of VAS that is available to the sim?

Windows is supposed to merge blocks to provide such a block when requested. I'm not sure if that's something which has to be allowed by the request of by some system setting. Don't forget the memory address you see isn't the true one, it all goes via page tables which can change the used addresses without changing the "real" (hardware) ones.

I think you can actually force Windows to do a memory "defrag", but I think that would cause pausing. Maybe that could be done as an add-on control, so you instigate it and hence expect the pause.

The problem with monitoring the sizes of blocks and finding the largest is the processing time involved in doing so. I'd be worried about adversely affecting performance. However, I might look into it, as an option.

Pete

 

 

[Pete Dowson]

I've added another value, in offset 0290, giving the maximum contiguous memory black size, in the same units as the current 024C. I've not tested it enough to know whether it indices any new stutters, so I'd like it tested by anyone interested.

Just download FSUIPC4959bTEST.zip and copy the DLL into your modules folder. Change any logging or plug-in you are using to display VAS to use offset 0290 instead of 024C and see what you think. Any performance issues at all?

Next question then is -- should this value be used for the OOM check (warning beeps) instead of the total? If so should the threshold be reduced or left the same?

Pete

 

 

 

[jabloomf1230]

Thanks. I'll let you know what I find.

[Gypsy Baron]

"I think you can actually force Windows to do a memory "defrag", but I think that would cause pausing. Maybe that could be done as an add-on control, so you instigate it and hence expect the pause"

 

I would be interested in seeing this implemented if it would force a 'recovery' of memory no longer in use by FSX, thus helping to prevent an OOM error from occurring. Currently, when I get the notice of my "LOW VAS" warning which I have arbitrarily set at 500 MB my only recourse is to either 'look up' or somewhere inside the VC until that VAS number increases some or to minimize the FSX window which usuaslly increases VAS somewhat.   After that it is 'Save flight' and 'reload' the flight which induces a very big ;pause'!

 

  Paul

[jabloomf1230]

The new option seems to work for me without any ill effect on the sim. Howver I will keep testing as I did not try to coax an OOM. As expected, when P3d loads, the displayed FCB value is identical to the free VAS value, but as the flight progresses the disparity increases. I don't have any thoughts on the FSUIPC warning beep other than making it a user option as to which VAS value to use. Thanks again for adding this option and hoping that its usefulness in P3d is short-lived. ;-)

As to recovering VAS, I think that Process Lasso supposedly attempts to do this, but I could never see any improvement with VAS usage in P3d so I don't use Process Lasso anymore. I'm guessing that especially now with Hotfix 2, P3d 3.4 probably does the best job that it can with squeezing the last drop of juice out of the VAS lemon.

BTW, the new AI traffic limiter and options are great. There's a long thread about it at AVSim, which you probably already saw.

[edpatino]

On 1/1/2017 at 2:08 PM, Gypsy Baron said:

That value is already available via an offfset, 0x024C, an unsigned word.

I have a small lua script that displays the current VAS when it gets below 500MB.

I also write it to an L:Var for use in another gauge I have in all my aircraft that gives

me a continuos readout of the current VAS.

 

function VAS(control, vas)

    vas_in = ipc.readUD(0x024C)
    ipc.writeLvar("L:VAS", vas_in)

	if
	   vas_in < 500000 then
	   ipc.display("VAS = "..vas_in,2)
	end

end

event.offset(0x024C,"UW","VAS")
event.timer(10000,"VAS")

  Paul

Hi Paul. This looks interesting!.

Could you provide a little help on how to write down this script into FSUIPC (I guess), or some sort of guidance?.

Thanks in advance.

Cheers, Ed

 

[Pete Dowson]

5 hours ago, Gypsy Baron said:

I would be interested in seeing this implemented if it would force a 'recovery' of memory no longer in use by FSX

It cannot recover memory which still appears to be allocated. A defrag would only be a joining up of the known free blocks. Allocated memory must be freed so that the system knows the pointer is now unused.

[LATER]

On researching the idea of memory defraging, I find that things have changed a lot since the early days of Windows when I thought I understood it Windows 3, probably! ;-) ).  Since Vista all Windows versions appear to allocate in pages of 16kb anyway, and attempt to do so in a way that had previously to be opted as "Low Fragementation Heap". The only vaguely useful function appears to be 

HeapCompact

Coalesces adjacent free blocks of memory on a heap.

but this assumes the process has only one heap, and wouldn't deal with real fragmentation, only contiguous free backs. I suspect the system would do that automatically when needed in any case.

The code I'm using to determine the largest free block does not check for continuity with other free blaocks, so it may be showing a more pessimistic value that I thought.

Multithreaded programs like P3D are likely to have more than one heap.

Pete

 

 

[jabloomf1230]

33 minutes ago, Pete Dowson said:

The code I'm using to determine the largest free block does not check for continuity with other free blocks, so it may be showing a more pessimistic value that I thought.

 

At least it brackets the range between the total free VAS and largest FCB. 

[jabloomf1230]

1 hour ago, edpatino said:

Hi Paul. This looks interesting!.

Could you provide a little help on how to write down this script into FSUIPC (I guess), or some sort of guidance?.

Thanks in advance.

Cheers, Ed

 

Ed,

FSUIPC already provides an easy way to monitor free VAS. Just use offset 024C. I display the value it in the sim's title bar, which is one of the options.

Jay

[jabloomf1230]

57 minutes ago, Pete Dowson said:

The code I'm using to determine the largest free block does not check for continuity with other free blaocks, so it may be showing a more pessimistic value that I thought.

Pete,

You can check your result versus Mark Russinovich's utility VMap:

https://technet.microsoft.com/en-us/sysinternals/vmmap.aspx

Run VMap and then point to either P3d or FSX then click on "free memory" and it will show all the free blocks for the app. The fragmentation view for each 32 bit app is also instructive.

Jay

[edpatino]

35 minutes ago, jabloomf1230 said:

Ed,

FSUIPC already provides an easy way to monitor free VAS. Just use offset 024C. I display the value it in the sim's title bar, which is one of the options.

Jay

Hi Jay, thanks, but that's the setting I'm currently using with FSUIPC.

Looks interesting to me the LUA script that Paul (Gipsy Baron) wrote to have a warning message when this total VAS remaining goes down from a certain value (500 MB in his case), but don't know the way to incorporate it into FSUIPC, never had done this before myself, so I'm lost, that's why I need some help or guidance.

Thanks in advance if you can guide me too!.

Ed

[jabloomf1230]

FSUIPC beeps twice when free VAS reaches 300 MB. You could alter Gypsy Baron's LUA script above to add a beep pattern . Maybe he'll repost with revised code, but you could also do it yourself. 

[jabloomf1230]

Pete,

I did a bunch of testing and I never saw any discrepancy between your largest FCB value and what VMap displayed for P3d. It was also unusual to see any free VAS fragments adjacent in the VAS address map to the largest FCB.

The difference between free VAS and largest FCB only seems to be numerically important when the free VAS goes under 400-500 MB. In that range, the sum of the remaining VAS fragments tends to be in the hundreds of MB range. Of course this is with P3d 3.4 and my addon mix. Your mileage will vary.

Jay

[Gypsy Baron]

6 hours ago, edpatino said:

Hi Paul. This looks interesting!.

Could you provide a little help on how to write down this script into FSUIPC (I guess), or some sort of guidance?.

Thanks in advance.

Cheers, Ed

 

Hello Ed,

To use the script simply copy and paste it into a text document using notepad or any other text editor.

Then SAVE the file to the FSX Modules folder with the extension '.lua'. You can name it whatever you wish but for an example let's call it VAS.lua. Once saved then open the FSUIPC INI file and add the following lines:

 

[Auto]
1=Lua VAS          or whatever you named the file

This will cause the script to run when FSUIPC loads.

I use the Windows title bar to display the contents of offset 0x66C0, which is the location that holds my 'mode' number. I have multiple assignments for each of my Controller switches. Anywhere from 8 to 13 or 14 for each switch. Typically over 100 for each aircraft. I have dual Saitek throttle quads and I can take a complex aircraft like any of the A2A Accu-sim birds from cold and dark to getting airborne without having to use the mouse or the keyboard. All done via the conditional assignments made possible by FSUIPC and 10 switches plus 2 to INC and DEC the mode. I also use the pinky switch on my X-45 stick as a further conditional modifier, effectively doubling the number of assignments for each mode.

This script only displays the VAS when the low limit is reached. It pops up in a small Lua window and remains for 2 seconds. I would never hear the FSUIPC OOM warning dings over the engine sounds of the four radials of my A2A B-17 or the L049 Connie along with the TeamSpeak chatter, since I fly almost exclusively on line. I also have another XML gauge that is always open on my display and a small section of that gauge displays either the current VAS or the wind speed and direction. I make use of Lua scripts to display my current controller assignments when I switch 'modes' or on demand by hitting F10. That way I do not need a 'cheat sheet' to remind me what the current 10 or 20 assignments are for my switches. One other thing, you can define the size and location of the Lua window by adding this line just after the "Function" statement in the script:

  ipc.setdisplay(770, 50, 500, 100)

Those are the X and Y offsets followed by the X and Y size. I didn't include that in my listing as I actually define this in other scripts that I have for each of my aircraft that always runs.

Just PM me if you have any more questions or issues.

 Paul

[Pete Dowson]

3 hours ago, jabloomf1230 said:

I did a bunch of testing and I never saw any discrepancy between your largest FCB value and what VMap displayed for P3d. It was also unusual to see any free VAS fragments adjacent in the VAS address map to the largest FCB.

The difference between free VAS and largest FCB only seems to be numerically important when the free VAS goes under 400-500 MB. In that range, the sum of the remaining VAS fragments tends to be in the hundreds of MB range.

Interesting findings. Thanks.

Pete

 

[edpatino]

11 hours ago, Gypsy Baron said:

Just PM me if you have any more questions or issues.

Thanks Paul for your help. A very good explanation. I'll try the script today as per your indications and will be back to you in case of trouble.

Thanks again!.

Cheers, Ed