ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

Here some new (quite confusing) results (still on laptop, hope to do some desktop tests tomorow):

  • After it looked like a good step forward yesterday, today I was back at 0.03 - without changing any configuration file. After quite a while of search I found out I can reproduce the following (after 3 tests each sequence, I don't think thats by accident): it makes a big difference if I start roscore and cob_bringup sim.launch (nothing else) before or after firefox !?????. With firefox first I get 0.03 otherwise almost 0.2. If firefox is already running gazebo also starts with 0.2 but then goes down to 0.03 in the first 2-3 seconds.

  • Some oprofile results for both states (I tried to go more deeply into python and kernel but did'n manage for now):

    almost 0.2xrealtime (startet before firefox)
  samples|      %|
------------------
   145994 66.5676 python2.6
    51055 23.2791 vmlinux-2.6.32-33-generic-pae
     6636  3.0258 oprofiled
     4748  2.1649 aes_i586
     3148  1.4354 Xorg
     1950  0.8891 oprofile
     1260  0.5745 gazebo
     1129  0.5148 joint_trajectory_action
      499  0.2275 compiz
      461  0.2102 cob_base_drive_chain_sim_node
      419  0.1910 xts
      391  0.1783 bash
      379  0.1728 state_publisher
      255  0.1163 cob_undercarriage_ctrl_node
      210  0.0958 cob_scan_filter
      128  0.0584 gf128mul
      118  0.0538 dm_crypt
      117  0.0533 fix_gazebo_pointcloud
      111  0.0506 pr2_mechanism_diagnostics
      108  0.0492 point_cloud_converter
       45  0.0205 i915
      ...

ca 0.04xrealtime (startet after firefox)
CPU_CLK_UNHALT...|
  samples|      %|
------------------
   151393 43.6056 python2.6
   140351 40.4252 vmlinux-2.6.32-33-generic-pae
    17351  4.9976 oprofiled
    11419  3.2890 Xorg
     9592  2.7628 aes_i586
     4739  1.3650 oprofile
     2276  0.6556 gazebo
     2239  0.6449 compiz
     1975  0.5689 joint_trajectory_action
     1311  0.3776 bash
      824  0.2373 xts
      673  0.1938 opreport
      478  0.1377 cob_base_drive_chain_sim_node
      348  0.1002 state_publisher
      306  0.0881 gf128mul
      256  0.0737 cob_scan_filter
      255  0.0734 cob_undercarriage_ctrl_node
      227  0.0654 i915
      219  0.0631 dm_crypt
      152  0.0438 fix_gazebo_pointcloud
      140  0.0403 pr2_mechanism_diagnostics
      136  0.0392 point_cloud_converter
      ...
       25  0.0072 firefox-bin

Note that firefox-bin does not eat up the time, but somehow influences and brings up the kernel percentage.

To see python and kernel to use almost all the time is also something I didn't expect at all. Is this something cob specific? Is anybody of the cob people following this thread?

strange!

Here some new (quite confusing) results (still on laptop, hope to do some desktop tests tomorow):

  • After it looked like a good step forward yesterday, today I was back at 0.03 - without changing any configuration file. After quite a while of search I found out I can reproduce the following (after 3 tests each sequence, I don't think thats by accident): it makes a big difference if I start roscore and cob_bringup sim.launch (nothing else) before or after firefox !?????. With firefox first I get 0.03 otherwise almost 0.2. If firefox is already running gazebo also starts with 0.2 but then goes down to 0.03 in the first 2-3 seconds.

  • Some oprofile results for both states (I tried to go more deeply into python and kernel but did'n manage for now):

    almost 0.2xrealtime (startet before firefox)
  samples|      %|
------------------
   145994 66.5676 python2.6
    51055 23.2791 vmlinux-2.6.32-33-generic-pae
     6636  3.0258 oprofiled
     4748  2.1649 aes_i586
     3148  1.4354 Xorg
     1950  0.8891 oprofile
     1260  0.5745 gazebo
     1129  0.5148 joint_trajectory_action
      499  0.2275 compiz
      461  0.2102 cob_base_drive_chain_sim_node
      419  0.1910 xts
      391  0.1783 bash
      379  0.1728 state_publisher
      255  0.1163 cob_undercarriage_ctrl_node
      210  0.0958 cob_scan_filter
      128  0.0584 gf128mul
      118  0.0538 dm_crypt
      117  0.0533 fix_gazebo_pointcloud
      111  0.0506 pr2_mechanism_diagnostics
      108  0.0492 point_cloud_converter
       45  0.0205 i915
      ...

ca 0.04xrealtime (startet after firefox)
CPU_CLK_UNHALT...|
  samples|      %|
------------------
   151393 43.6056 python2.6
   140351 40.4252 vmlinux-2.6.32-33-generic-pae
    17351  4.9976 oprofiled
    11419  3.2890 Xorg
     9592  2.7628 aes_i586
     4739  1.3650 oprofile
     2276  0.6556 gazebo
     2239  0.6449 compiz
     1975  0.5689 joint_trajectory_action
     1311  0.3776 bash
      824  0.2373 xts
      673  0.1938 opreport
      478  0.1377 cob_base_drive_chain_sim_node
      348  0.1002 state_publisher
      306  0.0881 gf128mul
      256  0.0737 cob_scan_filter
      255  0.0734 cob_undercarriage_ctrl_node
      227  0.0654 i915
      219  0.0631 dm_crypt
      152  0.0438 fix_gazebo_pointcloud
      140  0.0403 pr2_mechanism_diagnostics
      136  0.0392 point_cloud_converter
      ...
       25  0.0072 firefox-bin

Note that firefox-bin does not eat up the time, but somehow influences and brings up the kernel percentage.

To see python and kernel to use almost all the time is also something I didn't expect at all. Is this something cob specific? Is anybody of the cob people following this thread?

strange!

@PaulOnc: how is your realtime factor (shown at bottom line of gazebo)? Can you reproduce the influence of firefox?

Here some new (quite confusing) results (still on laptop, hope to do some desktop tests tomorow):

  • After it looked like a good step forward yesterday, today I was back at 0.03 - without changing any configuration file. After quite a while of search I found out I can reproduce the following (after 3 tests each sequence, I don't think thats by accident): it makes a big difference if I start roscore and cob_bringup sim.launch (nothing else) before or after firefox !?????. With firefox first I get 0.03 otherwise almost 0.2. If firefox is already running gazebo also starts with 0.2 but then goes down to 0.03 in the first 2-3 seconds.

  • Some oprofile results for both states (I tried to go more deeply into python and kernel but did'n manage for now):

    almost 0.2xrealtime (startet before firefox)
  samples|      %|
------------------
   145994 66.5676 python2.6
    51055 23.2791 vmlinux-2.6.32-33-generic-pae
     6636  3.0258 oprofiled
     4748  2.1649 aes_i586
     3148  1.4354 Xorg
     1950  0.8891 oprofile
     1260  0.5745 gazebo
     1129  0.5148 joint_trajectory_action
      499  0.2275 compiz
      461  0.2102 cob_base_drive_chain_sim_node
      419  0.1910 xts
      391  0.1783 bash
      379  0.1728 state_publisher
      255  0.1163 cob_undercarriage_ctrl_node
      210  0.0958 cob_scan_filter
      128  0.0584 gf128mul
      118  0.0538 dm_crypt
      117  0.0533 fix_gazebo_pointcloud
      111  0.0506 pr2_mechanism_diagnostics
      108  0.0492 point_cloud_converter
       45  0.0205 i915
      ...

ca 0.04xrealtime (startet after firefox)
CPU_CLK_UNHALT...|
  samples|      %|
------------------
   151393 43.6056 python2.6
   140351 40.4252 vmlinux-2.6.32-33-generic-pae
    17351  4.9976 oprofiled
    11419  3.2890 Xorg
     9592  2.7628 aes_i586
     4739  1.3650 oprofile
     2276  0.6556 gazebo
     2239  0.6449 compiz
     1975  0.5689 joint_trajectory_action
     1311  0.3776 bash
      824  0.2373 xts
      673  0.1938 opreport
      478  0.1377 cob_base_drive_chain_sim_node
      348  0.1002 state_publisher
      306  0.0881 gf128mul
      256  0.0737 cob_scan_filter
      255  0.0734 cob_undercarriage_ctrl_node
      227  0.0654 i915
      219  0.0631 dm_crypt
      152  0.0438 fix_gazebo_pointcloud
      140  0.0403 pr2_mechanism_diagnostics
      136  0.0392 point_cloud_converter
      ...
       25  0.0072 firefox-bin

Note that firefox-bin does not eat up the time, but somehow influences and brings up the kernel percentage.

To see python and kernel to use almost all the time is also something I didn't expect at all. Is this something cob specific? Is anybody of the cob people following this thread?

strange!

@PaulOnc: how is your realtime factor (shown at bottom line of gazebo)? Can you reproduce the influence of firefox?

Result after some more experiments:

  • The difference is made on startup of gazebo GUI. Speed depends on weather firefox is running at that point in time. It keeps slow even after closing firefox! It keeps fast when firefox is opened after gazeboo start.
  • For a headless gazebo there is no influence from firefox
  • The effect is deterministic and reproducable every time.