PSX computer / Energy saving

[Hardy Heinlin]

I checked the energy consumption at various frame rates.

Reference: Mac G5, Dual Core 2.2 GHz

PSX running at ...

100 FPS: 270 Watt
71 FPS: 248 Watt
50 FPS: 235 Watt

This was so impressive that I re-checked whether my human eye can really see any differences between the 100 rate and the 71 rate. – Nope. Smooth as honey. (And my CRT runs at 85 Hz).

Good reason to set the standard max lock to 71 FPS. This saves 22 Watt.

Perhaps I'll add an  optional switch to reduce it further to 50 and 32, that may be especially useful for laptops running on battery.

Anyway, everything above ca. 65 to 75 seems to be a waste of energy, and just useless fan noise and heat.

This should not be confused with the refresh rate of CRTs. A TV CRT at 100 Hz is better than one at 50 Hz. But that's because the screen gets dark after each frame and therefore flashes at 100 or 50 Hz. The PSX screen does not flash. Animation frame rates and CRT refresh rates are not the same. Also LCD refresh rates have a different effect than CRT refresh rates.

Cheers,

|-|ardy

[Peter Lang]

Hi Hardy,

my current FS9 setup runs with 30 FPS fixed. With this FPS no flickering or stuttering is noticable (CRT at 75 Hz). A noticable stuttering starts when the FPS drops below  ~ 20 FPS, e.g. in the vicinity of aerosofts EDDF. The problem here is not a stable drop to 20 FPS. The problem is a fluctuation between e.g. 17 and 23 FPS. A stable value for me seems to be smoother than a fluctuation.

As far a I remember the old super 8 and even the cinemascope films ran with 25 pics per second as it was said from this frequency on the human eye cannot realize the single pictures anymore.

I believe that even absolute specialists cannot notice any flickering or  stuttering above 50 FPS. If the monitor runs above 72 Hz (CRT) this should be far enough.

Just my thoughts
Peter

[Hardy Heinlin]

Hi Peter,

I notice the difference between 30 and 60 FPS only on big and very fast moving objects. E.g. when the PFD is zoomed to real size and the roll rate is at maximum, the outer edges of the horizon line make slight jumps by several pixels when at 30 FPS. Above ca. 50 to 60 FPS I see no jumps anymore.

(25 FPS cinema has a significant strobe effect. Video at 50 FPS doesn't have it. Ironically, there are video effects that simulate the 25 FPS cinema strobe effect. This effect is more and more used in TV and music productions; it genereates that certain "action" feeling. But since the video 50 FPS frames are interlaced, every frame in that 25 FPS simulation has just the half resolution in height. The result is that this effect also makes the image unsharp and "pixelated".)

Cheers,

|-|ardy

[Peter Lang]

I notice the difference between 30 and 60 FPS only on big and very fast moving objects. E.g. when the PFD is zoomed to real size and the roll rate is at maximum, the outer edges of the horizon line make slight jumps by several pixels when at 30 FPS. Above ca. 50 to 60 FPS I see no jumps anymore.

Hi Hardy,

as the roll rate of a 747 usually is much slower as e.g. for an Extra 300 this should not be a factor.

By searching the standard 747 roll rates in the web I just found another link, which may be interesting.

http://www.mathworks.com/access/helpdesk/help/toolbox/control/index.html?/access/helpdesk/help/toolbox/control/casestudies/f0-999787.html

For me this is to complicated. Even with Opera  :lol:
Peter

[Hardy Heinlin]

Thanks to the inertia of the 747, some features are indeed easier to model than when modelling an aerobatic aircraft.

I don't know what instrument sizes are available in MSFS, but when the PFD is scaled up to real-world size, like in PSX, and when rolling at max roll rate (747 barrel roll in less than half a minute), I do see the pixel jumps at the outer endings of the horizon when the frame rate is at 32. When the frame rate increases above 32, it really gets smoother. This is just an example.

|-|

[Christian Adrigan]

Hi Hardy,

as long as PSX is able to deliver a _steady_ frame rate (fps) AT or ABOVE Display Hz rate, absolutely smooth visuals would be the result, wouldn't they?

On a side note: will PSX support Vsync in order to avoid "tearing" effects?

I remember PS1/1.2 and PS1.3 had flickering areas.

Best regards,
Christian

[Hardy Heinlin]

Hi Christian,

PSX uses double buffering and a sync method that ensures that the display is "up-to-date". There are no tearing effects, even if the sync method is not invoked.

And no flicker, of course. Those days are gone.


Cheers,

|-|ardy

[Zinger]

I see from the data posted a roll time constant of around 1 second. This means in simple words that following an aileron input, about 1 second passes until the aircraft roll rate accelerates through roughly 2 thirds of the steady state roll rate to be achieved. This control sensitivity value is suitable for agile aircraft,  while stable transport category aircraft can use it or slightly lower value.
From past experience and common sense, transport category aircraft normally use a value of up to 5 degrees per second roll rate.

[Hardy Heinlin]

Hi Opher,

the data posted ("half a minute") is just a rough value without taking roll inertia into account. Indeed it varies by 1 or 2 seconds depending on whether I start the clock before or after max roll rate is achieved.

5 deg per second seems to be very slow, that would mean a full barrel roll should take 1 minute and 12 sec.? – PS1 has around 14 deg per sec., i.e. 25 sec for a full 360. This value is derived from observations in Lufthansa simulators. If I remember correctly, the barrel rolls we made took way less than 1 minute.

Edit: At max aileron deflection, of course. Did you mean those 5 deg/s for normal ops only (slight autopilot inputs etc.)?

Cheers,

|-|ardy

[Will]

Hardy, nice choice to help save the environment and increase battery life.  By fixing the frame rate at 71, can you use free up CPU cycles for other things?  (There is always talk on another sim's message boards about the importance of limiting frame rates to something smaller than "max," with the idea being that the computer can use the time between updates to do other math.)

[Zinger]

GruesGott Hardi,
I referred to normal roll rate in manual and autoflight modes during commercial maneuvering, for passenger comfort and cargo stability. For B747-400, full control deflection roll rate as you suggested is substantially higher, and is maintained for the airspeed range relatively even due to the aileron control logic (flaps up- only inboard aileron moving). The reason for such design is to allow for lateral loading imbalance such as during improper fuel drainage or engine separation, for crosswind runway operations, and for control system failure states, such as single aileron failure, for approach and landing. I watched aileron movement from passenger seats quite a bit, took me 20 years as passenger to learn to sleep through long flights. Its trailing edge hardly moves more than an inch in cruise during lateral corrections and about 5-8 inches during turns.

BTW high performance aircraft using full control deflection can roll up to 720 degrees per second. This requires outer helmet padding to avoid unpleasant head impact and canopy scratches.  The Bo 105 could be rolled at around 50 degrees per second IIRC. It has full aerobatic ability with unique rigid rotor design. I looped it many times for demo purposes. The only other helicopter I ever looped was the Sikorsky S-67 Blackhawk prorotype, with Curt Cannon, my friend and chief S-67 test pilot who soon thereafter died during his last scheduled Farnborough appearance (1974?). The S-67 prototype was to be delivered after the show to my unit, we also held a purchase option for quite a few. The US Army was involved at the time with the exotic Lockheed AH-56 Cheyenne development program, and didn't place orders for the S-67. 20 years later they switched a tribe to Apache, and later befriended Kiowa Warriors.
Sikorsky also made a marketing movie showing CH-53A loops and rolls (USMC  Lt Col Bob Gay and the chief pilot flying). What the movie didn't show is that due to the airframe and component overrstress in that flight, aircraft No. 714 was thereafter used for crash testing, during which it was released for freefall from 10 meters.

Hi Opher,

the data posted ("half a minute") is just a rough value without taking roll inertia into account. Indeed it varies by 1 or 2 seconds depending on whether I start the clock before or after max roll rate is achieved.

5 deg per second seems to be very slow, that would mean a full barrel roll should take 1 minute and 12 sec.? – PS1 has around 14 deg per sec., i.e. 25 sec for a full 360. This value is derived from observations in Lufthansa simulators. If I remember correctly, the barrel rolls we made took way less than 1 minute.

Edit: At max aileron deflection, of course. Did you mean those 5 deg/s for normal ops only (slight autopilot inputs etc.)?

Cheers,

|-|ardy

[Hardy Heinlin]

Ahoj Opher,

whenever I see a helicopter doing aerobatics I think I'm dreaming. It looks so surreal ... such a huge gyro force wanting to keep its attitude and momentum ... and then there's still enough counter-force on the controls to get that huge thing quickly out of its attitude.

(By the way, PS1 also models the 744 aileron lock-out system.)

...

Will, re multi-tasking with other programs doing their "math": I think it depends on the type of program – text editor, animation etc. If another program has to do something, the OS just gives it a few nanoseconds while stopping PSX during that time, no matter what frame rate PSX wants to achieve. But if that other program is, for example, an animation which, like PS, wants as much frame rates as possible, but with a lower  priority set, then that other program may get more FPS. But all in all, it's more an energy saving thing as the OS usually controls the multitask schedule anyway.


Cheers,

|-|ardy

[Jeroen Hoppenbrouwers]

In most cases you want some CPU cycles to be idle, all the time, to keep headroom. As soon as all CPU capacity is used up (100% load), a good OS will keep things running smoothly, but inevitably something has to give. For time-critical programs, such as an aerodynamics simulation, priority should be higher than for less critical tasks, such as network handling. A good OS will not starve any task. Graphics usually are in between: they can skip a few frames if necessary without ruining the simulation. Keeping this graceful degradation smooth is the big trick. Small granularity (many tasks to do, but all tasks small in time) is much easier to properly schedule.

As far as I understand, the PSX graphics loop isn't monopolising the system as much as other sims anyway. Although it will start stuttering if you overload your machine, the machine won't stop dead waiting for an unseen event to happen, like in MSFS during taxi out etc.

Maxing out any task on a reasonable frequency (72Hz looks okay for graphics) is always a very good idea.

[Hardy Heinlin]

I checked the energy consumption at various frame rates.

Reference: Mac G5, Dual Core 2.2 GHz

PSX running at ...

100 FPS: 270 Watt
71 FPS: 248 Watt
50 FPS: 235 Watt

The above is actually 2.0 GHz only, not 2.2.

...

I got a new iMac with Snow Leopard, Core Duo 2.9 GHz at 1920 x 1200:

PSX running at ...

71 FPS: 130 Watt with max monitor brightness
71 FPS: 100 Watt with reduced monitor brightness

A lot faster and bigger, and a lot less energy.

And quieter, too.


Cheers,

|-|ardy

[Richard McDonald Woods]

Surely, Hardy, you have only a portion of the driver code loaded as yet, so the performance figure may flatter to deceive? Or perhaps you already have much more of the code written than you have led us to believe?
Cheers, Richard