PDA

View Full Version : DeviceLink instability



lindyman
05-23-2004, 02:52 AM
I have discovered two things with DeviceLink that doesn't feel very good. I think they are related, but that a guess.

1. After a large amount of control inputs, the game begins to stutter enormously. I'm talking about sporadic freezes of >1s (sometimes 10-15s.) I had the same problem earlier in some missions in which the flying time was long (> 45mins.) I don't think this is related to DeviceLink per se, but rather the amounts of inputs itself. With DeviceLink, an external program can feel AEP with so much more input than a human player can, which makes the effect show much earlier.

2. A small error in my program made it issue queries via DeviceLink as quickly as it was ever capable of. The result was a complete hangup. I had to reboot vith the reset switch. DeviceLink can be used as a DOS attack. This was an error on my side, but it doesn't feel robust.
_
/Bjorn

lindyman
05-23-2004, 02:52 AM
I have discovered two things with DeviceLink that doesn't feel very good. I think they are related, but that a guess.

1. After a large amount of control inputs, the game begins to stutter enormously. I'm talking about sporadic freezes of >1s (sometimes 10-15s.) I had the same problem earlier in some missions in which the flying time was long (> 45mins.) I don't think this is related to DeviceLink per se, but rather the amounts of inputs itself. With DeviceLink, an external program can feel AEP with so much more input than a human player can, which makes the effect show much earlier.

2. A small error in my program made it issue queries via DeviceLink as quickly as it was ever capable of. The result was a complete hangup. I had to reboot vith the reset switch. DeviceLink can be used as a DOS attack. This was an error on my side, but it doesn't feel robust.
_
/Bjorn

bakubaku
05-23-2004, 07:59 AM
I am just guessing here..
Consider we have a feature to save a .trk(record of user input) file after the end of the mission. Because of that, all the input the player issued have to be stored
in the memory temporarily during the mission.
If the memory allocation is handled by the JVM
and it is not a direct buffer to your RAM. After a large amount of input, it might generate alof of fragmented memory location
and it is highly likely to slow down the game.
Probably when Oleg's staff designed the .trk system, they didn't anticipate this large amount of input by a player.

As I said I am just guessing here...

lindyman
05-23-2004, 08:22 AM
I guessed the same, so I checked. 500Mb of free RAM.

It could be the opposite, though, that raw data for tracks is stored in a temporary file. As long as the amount of data is small enough, it will all reside in the write cache, and no performance hit will be noticed. Once it has to start flushing the cache, it becoes worse.

One reason I don't really think that's it either, though, is that I can't say I notice any disk activity while this happens.

Some resource is exhausted, but it's not available RAM anyway (unless there's some silly limit on max RAM consumption/process.)
_
/Bjorn.

bakubaku
05-23-2004, 10:17 AM
I think it's quite easy to check as you may have already done that.
Try a quick mission with only one plane and no other object. Mark down the memory usage, and then run the mission with your interface to generate huge amount of input and run it for like 30mins. Come back and see what to memory usage are. If indeed increased, then user input must be in memory temporarily.
If that is the case, then even you have 500MB free ram is irrelevant. Because the JVM frequently need to increase the size of the heap, taking care of the memory allocation and the reallocation of the stuff already there.
But again, I don't know this stuff well enough....
Anyway, good luck on your interface program and hope someday we can use it as a flight performance test http://ubbxforums.ubi.com/infopop/emoticons/icon_smile.gif

lindyman
05-23-2004, 12:27 PM
<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Originally posted by bakubaku:
If that is the case, then even you have 500MB free ram is irrelevant. Because the JVM frequently need to increase the size of the heap, taking care of the memory allocation and the reallocation of the stuff already there.
<HR></BLOCKQUOTE>

I have not yet done the test you mentioned, but I think you might have stumbled on to something anyway, that I did not think of at all; the garbage collector. If it is the GC that strikes, chances are it won't be very visible in terms of memory used either.

Is there a way to set policies for the JVM GC?

BTW, on the autopilot: It's not capable of taking off decently, but it often crashes when climbing out. The reason is an unfortunate mode switch from controlling elevator for AoA in the ground effect acceleration, to controlling it for desired vertical airspeed in climbout mode. I'll alter it so that desider vertical airspeed is controlled by desired AoA, which controlls elevator. This makes sense, since the elevator is more or less an AoA control more than anything else. This also makes it easier to automatically find AoA, and through it speed, for stall, best glide, best climb, etc.
_
/Bjorn.

BaldieJr
05-24-2004, 10:28 AM
lindyman: check private topics http://ubbxforums.ubi.com/infopop/emoticons/icon_smile.gif

<pre class="ip-ubbcode-code-pre">
My Specs (read 'em and weep):
* Automatically grinds whole beans before brewing
* Fully programmable 24 hours in advance
* Brew Pause feature lets you enjoy a cup before brewing has finished
* Automatically shuts off when brewing is complete
* Grind-off feature for brewing ground coffee
* 1-4 cup feature to accommodate coffee for one
* 10-cup double-wall insulated thermal carafe to keep your coffee hot long after brewing
* Gold tone commercial-style permanent filter eliminates the need to buy coffee filters
* Charcoal water filter removes impurities from the water
* Separate grinder chamber and filter area allow for easy cleanup
* Limited 3-year warranty
</pre>

lindyman
05-24-2004, 11:06 AM
<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Originally posted by BaldieJr:
lindyman: check private topics http://ubbxforums.ubi.com/infopop/emoticons/icon_smile.gif
<HR></BLOCKQUOTE>

Got it. That's so incredibly much more than I need. Current state is 10853 bytes of source code, which in compiled form becomes 16538 bytes. I expect it to grow, since it's exceptionally crude right now, but 20M! We're talking major growth here. Major indeed.

I'm having a little problem with the transition from controlling desired vertical airspeed with elevator to controlling desired vertical airspeed with desired AoA controlled by elevator. I easily get sloooowwww oscillations with enormous amplitude. I'll get it sorted out... I think it's just not fast enough to find the elevator setting for the desired AoA.
_
/Bjorn.

BaldieJr
05-24-2004, 11:46 AM
You might want to try using trims instead of primary controlls.

I don't mind giving up a load of webspace to someone putting a load of work into an interesting project http://ubbxforums.ubi.com/infopop/emoticons/icon_smile.gif

Consider it a "Thank you".

<pre class="ip-ubbcode-code-pre">
My Specs (read 'em and weep):
* Automatically grinds whole beans before brewing
* Fully programmable 24 hours in advance
* Brew Pause feature lets you enjoy a cup before brewing has finished
* Automatically shuts off when brewing is complete
* Grind-off feature for brewing ground coffee
* 1-4 cup feature to accommodate coffee for one
* 10-cup double-wall insulated thermal carafe to keep your coffee hot long after brewing
* Gold tone commercial-style permanent filter eliminates the need to buy coffee filters
* Charcoal water filter removes impurities from the water
* Separate grinder chamber and filter area allow for easy cleanup
* Limited 3-year warranty
</pre>

[This message was edited by BaldieJr on Mon May 24 2004 at 11:02 AM.]

lindyman
05-24-2004, 02:07 PM
<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Originally posted by BaldieJr:
You might want to try using trims instead of primary controlls.
<HR></BLOCKQUOTE>

I don't think that's enough. A normal real world autopilot uses the trims (which is handy, btw, if you want to achieve neutral trim without reaching for the wheel.) This one, however, isn't normal. I want to be able to increase the AoA all the way up until stall, and there's no way I can do that with the trim with the primary control centered.

Contrary to popular belief, however, it doesn't (shouldn't, I guess is a more proper word) matter for flight charactersistics anything at all if the AoA is achieved with trim or primary control, or a combination there of.

I think I know what I'm doing wrong, though. The elevator is more or less a direct AoA controller. I'm using a classic PID control system to achieve the desired AoA. The problem with a PID system, howeve, is that it works on the difference between what I want and the actual value. This works nicely, but it can take a little time to make that difference zero. If I primarily let the desired AoA control the elevator as is, and use the PID controller for the fine adjustment, I think I'll be much closer in much shorter time.

That, however, will be an excercise for tomorrow, as I'm dead tired right now.
_
/Bjorn.