Low framerate not solved by more powerful video card

[Fraoch]

Hello:

I've been playing Simutrans using an NVIDIA GeForce GT 520.  I didn't notice any problem when I was using an old CRT at 1024 X 768...

I got a new widescreen monitor and set it at 1920 X 1080 (recommended, optimal setting).  Whoa, big problem.  The game was extremely jerky and framerates were in the yellow (12-14 fps) and red (2-6 fps) range.  Scrolling across the map was impossible.  Even closing windows had a considerable lag.

Well the 520 is no gaming video card, so I upgraded to the most powerful passively-cooled NVIDIA card I could find - a GT 640.  Research indicates it should be much, much more powerful than the 520 - it has 6 times the raw processing power, twice the memory bandwidth, 8 times the CUDA cores, etc.  Sure it's not the fastest card in the world but it should be miles better than the 520, right?

Unfortunately after installing it I notice no difference in the framerates in Simutrans.  Perhaps it's a bit more responsive when it comes to closing windows but there's no way I'm getting twice the performance or more.

Is there something I'm missing?  Do I need a card even more powerful than the 640?  Is Simutrans that intensive?

Simutrans 112.1 - r6212M with pak128 2.2.0 on Ubuntu Linux 12.10 64-bit.  AMD Phenom X3 B73 (2.8 GHz) with 4 GB of DDR3 RAM.  The map is 500 X 500, larger than default but not the largest I've played.  It should be noted that my system isn't using much CPU or memory when Simutrans is running, it seems to have no problems with it.  Interestingly the new video card doesn't seem stressed, when displaying Simutrans, adaptive clocking always clocks it down to 324 MHz from its 901 MHz maximum.

Thanks for any advice.

[ӔO]

In simutrans/config/simutrans.tab check that the frames_per_second is set to a number between 15 and 30. Default should be 25.

From my understanding, simutrans does not rely on the GPU to draw images and instead everything is done by the CPU. However, a phenom should be more than enough for simutrans, so it is puzzling.


Also, check here: http://forum.simutrans.com/index.php?topic=11356.0

[Sarlock]

As AEO said, it's a CPU intensive operation not GPU, so the new graphics card won't make any difference to the frame rate.  The fact that your frame rate is so low is a bit puzzling, however, your system should be flying on a map that small.  I have a similar system and even on a much larger map (2,000x2,000) it still performs quite well.

There must be something else going on, a conflict with another process that is slowing Simutrans down or something like that.

[Ters]

Simutrans is perhaps rather I/O intensive, and more likely to be bound be memory/bus speeds rather than CPU or GPU. I have had more problems with Simutrans performance on Linux than on Windows. Perhaps the graphics isn't ideally set up, such as no DirectFB/DRI.

[Markohs]

Seeing you use Ubuntu, I'll post it here too. I'm sorry, moderators.

Can you please run:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

And post the result here?

If it doesn't output "Performance", do:

echo performance | sudo tee /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

And test the game again to see if we get any difference?

You might need to do this for cpu0, cpu1,... all your cpu's

[Yona-TYT]

Hardware accelerated display, OpenGL back-end & Simutrans 3D
I think this project is taking care of hardware acceleration

[Markohs]

We'll need more time for that one, Yona, I'm still busy learning the inners of simutrans.

[prissi]

Simutrans shows more objects at the same time than many of the 3D games, especially when zoomed out. But in your case, you might easily get better performance by compiling simutrans for your system, using -march i686 respective x86_64 (for 64 bit) and MULTITHREADS=6 The latter will especially increase the redraw speed.

Zooming out on large displays will anyway slow down simutrans a lot. On normal size (no zoom) this screen size should not pose a problem. If you edit your X11 settings, you can start in 16 bit color mode. That could speed also up a lot, because only half of the size has to move.

Btw. with larger screens also scrolling a lot of text in the background may take a lot of CPU, depending on the driver and the window manager.

[Fraoch]

Wow, lots and lots of help and responses here.  I'll address them in order.  Thanks everybody!

In simutrans/config/simutrans.tab check that the frames_per_second is set to a number between 15 and 30. Default should be 25.

Yes, frames_per_second is set to 25.

Also, check here: http://forum.simutrans.com/index.php?topic=11356.0

That seems to be the exact problem I'm having!  Even though Simutrans is demanding/requesting more CPU and obviously suffering from the lack of it, the CPU isn't working very hard.  There's lots more CPU available but it's not being used.

[Fraoch]

Can you please run:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

And post the result here?

"ondemand" - just like the other discussion thread.

If it doesn't output "Performance", do:

echo performance | sudo tee /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

And test the game again to see if we get any difference?

You might need to do this for cpu0, cpu1,... all your cpu's

After I did this for all CPUs, I do see a difference!  Simutrans seems to strive for 25 fps and the CPUs will ramp up (a bit) to achieve this if framerates get low.  CPU usage isn't all that high overall, maybe 20-25%.  It's definitely improved.

The torture test is to follow a very fast train where it still lags, going down to about 14-15 fps, but things have definitely changed.  Even during this torture test, CPU usage is still low, 25-30%.

[Fraoch]

Hardware accelerated display, OpenGL back-end & Simutrans 3D
I think this project is taking care of hardware acceleration

Eagerly awaiting this as I now have lots of OpenGL processing power to throw at Simutrans.

[Markohs]

Eagerly awaiting this as I now have lots of OpenGL processing power to throw at Simutrans.

Not a easy task, but I think we'll have it working some day.

Do you know C++?

[Fraoch]

Simutrans shows more objects at the same time than many of the 3D games, especially when zoomed out. But in your case, you might easily get better performance by compiling simutrans for your system, using -march i686 respective x86_64 (for 64 bit) and MULTITHREADS=6 The latter will especially increase the redraw speed.

I'm not too familiar with custom compiling but I'll look into it.

Zooming out on large displays will anyway slow down simutrans a lot. On normal size (no zoom) this screen size should not pose a problem.

True, I noticed that earlier but it's quite apparent now.  Yes, at the default zoom the game starts in, framerates seem to hold at 25 fps regardless of what's going on.  Maybe I'll just play zoomed in a little more than I used to. 

If you edit your X11 settings, you can start in 16 bit color mode. That could speed also up a lot, because only half of the size has to move.

Seeing as some of the other optimizations are yielding positive results, I'd rather leave that as a last resort.  I'm afraid it might make Simutrans not quite as pretty.

[Fraoch]

Not a easy task, but I think we'll have it working some day.

Do you know C++?

hehheh I know of it, but I don't really know it.

I did see your response that you're working on it and it's not ready.  Sorry about that.  Thank you for your contribution...wish I could give something back to the project.

[Fraoch]

By the way, what does an asterisk ("*") beside the framerate value mean?

Often when I have issues an asterisk will appear beside the framerate and it will start to drop.

[Markohs]

It means that the system has activated the simple drawing algorithm, that renders some graphic errors (not much), but it's way faster. It's usually activated on big outer zoom levels, where those small graphical errors are so small they are not noticeable.

[An_dz]

Do bigger paksets have better performance in bigger screens? Less tiles to render?

[Markohs]

Yes, An_dz.

[Fraoch]

Simutrans shows more objects at the same time than many of the 3D games, especially when zoomed out. But in your case, you might easily get better performance by compiling simutrans for your system, using -march i686 respective x86_64 (for 64 bit) and MULTITHREADS=6 The latter will especially increase the redraw speed.

After some trouble compiling (explained here: http://forum.simutrans.com/index.php?topic=11360.0 ) I did finally get a running executable and it is just about perfect.

Framerates stay at a solid 25 and don't budge at all, even following a fast train when zoomed out all the way.  CPU usage is even lower, 15-20% total.  Memory usage seems higher, oddly.

Anyway the last thing is to try compiling with "-march i686 respective x86_64", not sure how to do this.

Thanks everyone!

[prissi]

you can just add this to flags, I think.
CCFLAGS ?= -march i686
or, if you have a 64 bit system, you are fine already, there are not much iptimisations left out.

[Yona-TYT]

he believed that "32bits and 64bits" was automatically

[Markohs]

Fraoch, do you mind trying a fix?

You have to open simintr.cc, and in line 67 change the line:

Code Select Expand


   frame_time = clamp( time, 10, 250)*FRAME_TIME_MULTI;


To:

Code Select Expand


   frame_time = clamp( time, 10, 40)*FRAME_TIME_MULTI;



And recompile.

Test it in ondemand mode, please.

[Fraoch]

you can just add this to flags, I think.
CCFLAGS ?= -march i686
or, if you have a 64 bit system, you are fine already, there are not much iptimisations left out.

Yes, I have a 64-bit system so I'll skip this step.  Thanks.

[Fraoch]

Fraoch, do you mind trying a fix?

You have to open simintr.cc, and in line 67 change the line:

Code Select Expand


   frame_time = clamp( time, 10, 250)*FRAME_TIME_MULTI;


To:

Code Select Expand


   frame_time = clamp( time, 10, 40)*FRAME_TIME_MULTI;



And recompile.

Test it in ondemand mode, please.

Unfortunately this didn't work very well.

My CPU usage jumped up to 35-40% and framerates dropped to 9 fps when I was following a fast train.  Windows were almost unresponsive.

I did turn all 4 CPUs back to ondemand mode first.

Sorry this didn't help Markohs, but if you have anything else you'd like me to try I'll do what I can.

[Markohs]

but did you get better performance than before the change? This is a test, about the events and the problem of simutrans getting iirresponsive there is a fix for that too.

Try decreasing the 40 to a 35, and on simword.cc, line 6164, substitute:

NOTE: don't change to 35.

Code Select Expand


      // get an event
      DBG_DEBUG4("karte_t::interactive", "calling win_poll_event");
      win_poll_event(&ev);

      if(ev.ev_class==EVENT_SYSTEM  &&  ev.ev_code==SYSTEM_QUIT) {
         // quit the program if this windows is closed
         destroy_all_win(true);
         umgebung_t::quit_simutrans = true;
         break;
      }

      if(ev.ev_class!=EVENT_NONE &&  ev.ev_class!=IGNORE_EVENT) {

         if(  umgebung_t::networkmode  ) {
            set_random_mode( INTERACTIVE_RANDOM );
         }

         DBG_DEBUG4("karte_t::interactive", "calling check_pos_win");
         swallowed = check_pos_win(&ev);

         if(  !swallowed  ) {
            if(IS_RIGHTCLICK(&ev)) {
               display_show_pointer(false);
               cursor_hidden = true;
            } else if(IS_RIGHTRELEASE(&ev)) {
               display_show_pointer(true);
               cursor_hidden = false;
            } else if(IS_RIGHTDRAG(&ev)) {
               // unset following
               follow_convoi = convoihandle_t();
               blick_aendern(&ev);
            }
            else {
               if(cursor_hidden) {
                  display_show_pointer(true);
                  cursor_hidden = false;
               }
            }
         }

         DBG_DEBUG4("karte_t::interactive", "after check_pos_win");
         if((!swallowed  &&  (ev.ev_class==EVENT_DRAG  &&  ev.ev_code==MOUSE_LEFTBUTTON))  ||  (ev.button_state==0  &&  ev.ev_class==EVENT_MOVE)  ||  ev.ev_class==EVENT_RELEASE) {
            bewege_zeiger(&ev);
         }

         if(  umgebung_t::networkmode  ) {
            clear_random_mode( INTERACTIVE_RANDOM );
         }
         DBG_DEBUG4("karte_t::interactive", "end of event handling");
      }


Code Select Expand


      do {
         // get an event
         DBG_DEBUG4("karte_t::interactive", "calling win_poll_event");
         win_poll_event(&ev);


         if(ev.ev_class==EVENT_SYSTEM  &&  ev.ev_code==SYSTEM_QUIT) {
            // quit the program if this windows is closed
            destroy_all_win(true);
            umgebung_t::quit_simutrans = true;
            break;
         }

         if(ev.ev_class!=EVENT_NONE &&  ev.ev_class!=IGNORE_EVENT) {

            if(  umgebung_t::networkmode  ) {
               set_random_mode( INTERACTIVE_RANDOM );
            }

            DBG_DEBUG4("karte_t::interactive", "calling check_pos_win");
            swallowed = check_pos_win(&ev);

            if(  !swallowed  ) {
               if(IS_RIGHTCLICK(&ev)) {
                  display_show_pointer(false);
                  cursor_hidden = true;
               } else if(IS_RIGHTRELEASE(&ev)) {
                  display_show_pointer(true);
                  cursor_hidden = false;
               } else if(IS_RIGHTDRAG(&ev)) {
                  // unset following
                  follow_convoi = convoihandle_t();
                  blick_aendern(&ev);
               }
               else {
                  if(cursor_hidden) {
                     display_show_pointer(true);
                     cursor_hidden = false;
                  }
               }
            }

            DBG_DEBUG4("karte_t::interactive", "after check_pos_win");
            if((!swallowed  &&  (ev.ev_class==EVENT_DRAG  &&  ev.ev_code==MOUSE_LEFTBUTTON))  ||  (ev.button_state==0  &&  ev.ev_class==EVENT_MOVE)  ||  ev.ev_class==EVENT_RELEASE) {
               bewege_zeiger(&ev);
            }

            if(  umgebung_t::networkmode  ) {
               clear_random_mode( INTERACTIVE_RANDOM );
            }

            if (!swallowed) {
               DBG_DEBUG4("karte_t::interactive", "calling interactive_event");
               interactive_event(ev);
            }
         }
      } while (ev.ev_class!=EVENT_NONE);


And remove 6435:

Code Select Expand


        }

        if (!swallowed) {
            DBG_DEBUG4("karte_t::interactive", "calling interactive_event");
            interactive_event(ev);


Thanks for your help, I'd do myself but can't test it here because I miss a machine with that CPU.

[Markohs]

mmm.. forget it for the time. There is more things to change, I think, I'll contact you when I have a fix.

[Fraoch]

but did you get better performance than before the change? This is a test, about the events and the problem of simutrans getting iirresponsive there is a fix for that too.

Yes, with MULTITHREADS=6 and CPUs set to "performance", framerates stay at 25 no matter what is going on.

Interestingly when I switched the CPUs back to "ondemand", performance suffered again.

Thanks for your help, I'd do myself but can't test it here because I miss a machine with that CPU.

Well no problem, thanks for addressing it!  I'll let you know how this latest modification goes.

[Markohs]

Fraoch, wit the changes I told you, with 40 as a value, if you open the menu->display, how much do you have in "frame time", fps and simloops? wich is CPU usage?

[Fraoch]

Fraoch, wit the changes I told you, with 40 as a value, if you open the menu->display, how much do you have in "frame time", fps and simloops? wich is CPU usage?

Frame time: 40 ms
FPS: 8-9
Simloops: 0.2-0.4
CPU usage: 35-40%

[Markohs]

Sorry to ask again, was idle 0?

[Fraoch]

Yes, when I'm experiencing problems, idle drops to 0.  When the framerate recovers it rises.

[prissi]

Are the AI on? It might be that the AI tries to connect two islands on long maps. During this time nothing can be done. Same can be happen for a complex ship connection around some islands. Idle 0 is usually a sign that simutrans works and does not call the OS to indicate it can reduce CPU. This is a very strange behaviour of the scheduler.

[Markohs]

it's hard to reproduce and diagnostic this when my computer has no problem.  I'll try to install Ubuntu tomorrow, I just used vmware virtual machines on windows.  yea, the change i suggested was a dirty hack to force 25 fps and see if it made a difference.

[Fraoch]

Are the AI on? It might be that the AI tries to connect two islands on long maps. During this time nothing can be done. Same can be happen for a complex ship connection around some islands. Idle 0 is usually a sign that simutrans works and does not call the OS to indicate it can reduce CPU. This is a very strange behaviour of the scheduler.

The AI isn't on - I am the only player.

I also have no ships.