Uploaded image for project: 'Firestorm'
  1. Firestorm
  2. FIRE-4972

CPU usage is 50-100%, fluctuating rapidly, tried all the fixes from group, set affinty to one core each of them ran 55-80 but less fluctuation and not reaching 100 with only one going

    Details

    • Type: Bug
    • Status: Passed QA
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Phoenix Firestorm 3.3.0, Phoenix Firestorm 4.0.1
    • Fix Version/s: Phoenix Firestorm 4.3.1
    • Component/s: None
    • Labels:
    • Environment:
    • SL Avatar Name:
      Bay Addens
    • Reported In:
      Firestorm 3.3.0.24880 Maintenance Release

      Description

      CPU usage is 50-100%, fluctuating rapidly, tried all the fixes from group, set affinty to one core each of them ran 55-80 but less fluctuation and not reaching 100 with only one going

      EDIT (Whirly): LL issue https://jira.secondlife.com/browse/VWR-28388
      Can those having this issue try this please:
      Go to Preferences -> Advanced -> Tick show developer menu
      Then Develop -> Untick HTTP inventory & relog
      Please report in comments if this helps.

        Issue Links

          Activity

          Hide
          svenni mcmillan Svenni McMillan added a comment - - edited

          I have the same Problem too with Firestorm 3.3.0 (24880).
          After login the CPU Usage is around 30 %. But after some Minutes the CPU Usage is rapidly at 80 %.
          Tried all fixes too. But dont help.

          CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (2605.43 MHz)
          Speicher: 3070 MB
          Betriebssystem, Version: Microsoft Windows Vista 32-bit Service Pack 2 (Build 6002)
          Grafikkarten-Hersteller: ATI Technologies Inc.
          Grafikkarten: ATI Radeon HD 4300/4500 Series

          Show
          svenni mcmillan Svenni McMillan added a comment - - edited I have the same Problem too with Firestorm 3.3.0 (24880). After login the CPU Usage is around 30 %. But after some Minutes the CPU Usage is rapidly at 80 %. Tried all fixes too. But dont help. CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (2605.43 MHz) Speicher: 3070 MB Betriebssystem, Version: Microsoft Windows Vista 32-bit Service Pack 2 (Build 6002) Grafikkarten-Hersteller: ATI Technologies Inc. Grafikkarten: ATI Radeon HD 4300/4500 Series
          Hide
          ry-jefferson Ryzor Jefferson added a comment - - edited

          Same this here too, support was being quite ignorant.

          my CPU usage sticks constantly at 30% and sometimes shoots up to 80.

          this was not happening in previous releases.

          CPU: AMD Phenom(tm) II X4 980 Processor (3725 MHz)
          Memory: 6142 MB
          OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
          Graphics Card Vendor: ATI Technologies Inc.
          Graphics Card: ATI Radeon HD 4800 Series

          Show
          ry-jefferson Ryzor Jefferson added a comment - - edited Same this here too, support was being quite ignorant. my CPU usage sticks constantly at 30% and sometimes shoots up to 80. this was not happening in previous releases. CPU: AMD Phenom(tm) II X4 980 Processor (3725 MHz) Memory: 6142 MB OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601) Graphics Card Vendor: ATI Technologies Inc. Graphics Card: ATI Radeon HD 4800 Series
          Hide
          virtualban Virtualban Alex added a comment -

          Core 2 duo 3 GHz, Ati 5670, same problem. Normal CPU usage when first starting, just like the very previous version, and high cpu usage after a few minutes. There are some occasions when the cpu gets back as it should, and after that it does not go up anymore, but I have not been able to replicate the solution. Instead of staying as in the previous version, cpu usage stays over 60% when the firestorm window is not in focus, and 90 to 100% when in focus. It is a bug, because if I assign only one core to firestorm, the framerate does not drop, at all. But it is serious, though, as cpu goes very hot.

          Show
          virtualban Virtualban Alex added a comment - Core 2 duo 3 GHz, Ati 5670, same problem. Normal CPU usage when first starting, just like the very previous version, and high cpu usage after a few minutes. There are some occasions when the cpu gets back as it should, and after that it does not go up anymore, but I have not been able to replicate the solution. Instead of staying as in the previous version, cpu usage stays over 60% when the firestorm window is not in focus, and 90 to 100% when in focus. It is a bug, because if I assign only one core to firestorm, the framerate does not drop, at all. But it is serious, though, as cpu goes very hot.
          Hide
          ansariel.hiller Ansariel Hiller added a comment -

          Does this also happen on the latest official Viewer 3?

          Show
          ansariel.hiller Ansariel Hiller added a comment - Does this also happen on the latest official Viewer 3?
          Hide
          svenni mcmillan Svenni McMillan added a comment -

          I tested it with the Official Viewer 3. Same Problem. After some Minutes CPU Usage is at 80 %. If i minimize the Window, the Usage is high too.
          In Firestorm Version 3.2.2.24336 was not this Problem. The Version works good. There the Usage is at 30 %. At minimized Window at 10-15 %.

          Show
          svenni mcmillan Svenni McMillan added a comment - I tested it with the Official Viewer 3. Same Problem. After some Minutes CPU Usage is at 80 %. If i minimize the Window, the Usage is high too. In Firestorm Version 3.2.2.24336 was not this Problem. The Version works good. There the Usage is at 30 %. At minimized Window at 10-15 %.
          Hide
          virtualban Virtualban Alex added a comment -

          Tested it on the latest firestorm, v3.3.0.24882, and still the same issue.

          Show
          virtualban Virtualban Alex added a comment - Tested it on the latest firestorm, v3.3.0.24882, and still the same issue.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -
          • Can everyone getting this issue please try the workarounds here first http://wiki.phoenixviewer.com/fs_100_cpu & let us know if any were helpful
          • Can you test on Viewer 3 & see if you have the same problem.
          • Please also paste in all your system information from help -> about Firestorm.
          Show
          whirly.fizzle Whirly Fizzle added a comment - Can everyone getting this issue please try the workarounds here first http://wiki.phoenixviewer.com/fs_100_cpu & let us know if any were helpful Can you test on Viewer 3 & see if you have the same problem. Please also paste in all your system information from help -> about Firestorm.
          Hide
          ry-jefferson Ryzor Jefferson added a comment -

          Whirly, that fix has been offered by many people, but proven to be ineffective, this is a client side error unfortuantly.

          but here is the system information:

          Firestorm 3.3.0 (24880) Feb 6 2012 20:10:16 (Firestorm-Release)
          Release Notes

          You are at 233,241.0, 257,310.0, 3,524.0 in Ryder Park located at sim9532.agni.lindenlab.com (216.82.43.235:13000)
          Second Life Server 12.02.24.250006
          Release Notes

          CPU: AMD Phenom(tm) II X4 980 Processor (3724.97 MHz)
          Memory: 6142 MB
          OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
          Graphics Card Vendor: ATI Technologies Inc.
          Graphics Card: ATI Radeon HD 4800 Series

          Windows Graphics Driver Version: 8.17.0010.1114
          OpenGL Version: 3.3.11399 Compatibility Profile Context
          RestrainedLove API: RLV v2.7.0 / RLVa v1.4.3a
          libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1
          J2C Decoder Version: KDU
          Audio Driver Version: FMOD version 3.750000
          Qt Webkit Version: 4.7.1 (version number hard-coded)
          Voice Server Version: Vivox 2.1.3010.6270

          Settings mode: Phoenix
          Viewer Skin: vintage (classic)
          Font Used: Deja Vu (96)
          Draw distance : 1024
          Bandwidth : 2000
          LOD factor : 4
          Built with MSVC version 1600
          Packets Lost: 0/1,233 (0.0%)

          Show
          ry-jefferson Ryzor Jefferson added a comment - Whirly, that fix has been offered by many people, but proven to be ineffective, this is a client side error unfortuantly. but here is the system information: Firestorm 3.3.0 (24880) Feb 6 2012 20:10:16 (Firestorm-Release) Release Notes You are at 233,241.0, 257,310.0, 3,524.0 in Ryder Park located at sim9532.agni.lindenlab.com (216.82.43.235:13000) Second Life Server 12.02.24.250006 Release Notes CPU: AMD Phenom(tm) II X4 980 Processor (3724.97 MHz) Memory: 6142 MB OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601) Graphics Card Vendor: ATI Technologies Inc. Graphics Card: ATI Radeon HD 4800 Series Windows Graphics Driver Version: 8.17.0010.1114 OpenGL Version: 3.3.11399 Compatibility Profile Context RestrainedLove API: RLV v2.7.0 / RLVa v1.4.3a libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1 J2C Decoder Version: KDU Audio Driver Version: FMOD version 3.750000 Qt Webkit Version: 4.7.1 (version number hard-coded) Voice Server Version: Vivox 2.1.3010.6270 Settings mode: Phoenix Viewer Skin: vintage (classic) Font Used: Deja Vu (96) Draw distance : 1024 Bandwidth : 2000 LOD factor : 4 Built with MSVC version 1600 Packets Lost: 0/1,233 (0.0%)
          Hide
          fizz.savira Fizz Savira added a comment -

          I have an iMac with the same problem, so the fix doesn't even apply

          Show
          fizz.savira Fizz Savira added a comment - I have an iMac with the same problem, so the fix doesn't even apply
          Hide
          virtualban Virtualban Alex added a comment -

          From my new experiences, it is a bad combination of region and viewer. Changed home due to evolution in character storyline, and on the new home it is not happening anymore.
          If I hang around the new home for the time where the problem arose in the old home, then the problem does no longer appear even if I go to the old home and stay there.
          From what I was exploring in task manager, the resource usage went straight from 10-15% in window out of focus, to 60%, not gradually but all of a sudden. Since restricting the viewer to one core did not affect framerate, my guess is that the viewer problem is related to some background thread in synchronization with the region or something like that. Some infinite loop that starts, and stays active till relog.
          p.s. on my new home I don't have edit terrain rights or other moderator rights, so maybe this is what keeps me safe and why it is not such a widespread problem.

          Show
          virtualban Virtualban Alex added a comment - From my new experiences, it is a bad combination of region and viewer. Changed home due to evolution in character storyline, and on the new home it is not happening anymore. If I hang around the new home for the time where the problem arose in the old home, then the problem does no longer appear even if I go to the old home and stay there. From what I was exploring in task manager, the resource usage went straight from 10-15% in window out of focus, to 60%, not gradually but all of a sudden. Since restricting the viewer to one core did not affect framerate, my guess is that the viewer problem is related to some background thread in synchronization with the region or something like that. Some infinite loop that starts, and stays active till relog. p.s. on my new home I don't have edit terrain rights or other moderator rights, so maybe this is what keeps me safe and why it is not such a widespread problem.
          Hide
          virtualban Virtualban Alex added a comment -

          Unlucky...
          What did not happen for a whole week, happened all of a sudden at my new home. High CPU usage. Same region and neighbours, and nothing else has changed.
          Too bad. Back to having no clue what causes or prevents it. Waiting for a new version to maybe fix it.

          Show
          virtualban Virtualban Alex added a comment - Unlucky... What did not happen for a whole week, happened all of a sudden at my new home. High CPU usage. Same region and neighbours, and nothing else has changed. Too bad. Back to having no clue what causes or prevents it. Waiting for a new version to maybe fix it.
          Hide
          virtualban Virtualban Alex added a comment -

          Version 4.0.1.27000, same problem.
          For example, 29 FPS on startup. After a while, sometimes just few minutes, sometimes one hour or more, cpu usage jumps to 100% on focused window, 65% to 85% out of focus and the framerate drops to 24 FPS on the exact same scene/quality/direction of cam. This remains 24 FPS even if I set affinity to jut one core.

          Show
          virtualban Virtualban Alex added a comment - Version 4.0.1.27000, same problem. For example, 29 FPS on startup. After a while, sometimes just few minutes, sometimes one hour or more, cpu usage jumps to 100% on focused window, 65% to 85% out of focus and the framerate drops to 24 FPS on the exact same scene/quality/direction of cam. This remains 24 FPS even if I set affinity to jut one core.
          Hide
          aphroditeatlas Aphrodite Atlas added a comment -

          Same problem for me, FS is using 75-90% of both CPUs. I have latest OS patches, latest video drivers, latest chipset updates from Asus and from AMD for board and processor.

          My FPS on this version is a whopping 10-11; previous FS release my FPS was close to zero. If the trade-off for that improvement is system lag such that even switching between active apps is a 5-10 second proposition I'll roll back to Phoenix.

          CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (2304.8 MHz)
          Memory: 3327 MB
          OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
          Graphics Card Vendor: ATI Technologies Inc.
          Graphics Card: AMD Radeon HD 6700 Series

          Show
          aphroditeatlas Aphrodite Atlas added a comment - Same problem for me, FS is using 75-90% of both CPUs. I have latest OS patches, latest video drivers, latest chipset updates from Asus and from AMD for board and processor. My FPS on this version is a whopping 10-11; previous FS release my FPS was close to zero. If the trade-off for that improvement is system lag such that even switching between active apps is a 5-10 second proposition I'll roll back to Phoenix. CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (2304.8 MHz) Memory: 3327 MB OS Version: Microsoft Windows XP Service Pack 3 (Build 2600) Graphics Card Vendor: ATI Technologies Inc. Graphics Card: AMD Radeon HD 6700 Series
          Hide
          maverick offcourse maverick offcourse added a comment - - edited

          I can confirm it happens after some minutes of viewer usage, in 5 different computers (with very different videocards, also new ATI). One core goes stuck to 100% and stay so also in minimized mode.
          -I noticed it happens on Firestorm 3.3.0 and 4.0.1 and i went back to 3.2.2
          -I noticed it happens also with official viewer 3.2.8 and 3.3.0, I had to go back to official sl viewer version 3.2.5(the version 3.2.6 has strange black screens with ati videocards)
          Look at: https://jira.secondlife.com/browse/VWR-28388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#issue-tabs
          Please fix it asap as it is very harmful for notebook systems.

          Show
          maverick offcourse maverick offcourse added a comment - - edited I can confirm it happens after some minutes of viewer usage, in 5 different computers (with very different videocards, also new ATI). One core goes stuck to 100% and stay so also in minimized mode. -I noticed it happens on Firestorm 3.3.0 and 4.0.1 and i went back to 3.2.2 -I noticed it happens also with official viewer 3.2.8 and 3.3.0, I had to go back to official sl viewer version 3.2.5(the version 3.2.6 has strange black screens with ati videocards) Look at: https://jira.secondlife.com/browse/VWR-28388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#issue-tabs Please fix it asap as it is very harmful for notebook systems.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Interesting comment on https://jira.secondlife.com/browse/MAINT-374 :

          Sahkolihaa Contepomi added a comment - 27/Mar/12 3:26 PM

          I did some further testing and found MSVCR100.DLL eats a whole core after some time when HTTP Textures are disabled under the 'Advanced' menu (so the older UDP method is used instead).

          Do those of you getting this problem have HTTP Textures disabled?
          Do you notices any changes if you enable/disable HTTP Textures from Develop -> HTTP Textures & relog?

          Show
          whirly.fizzle Whirly Fizzle added a comment - Interesting comment on https://jira.secondlife.com/browse/MAINT-374 : Sahkolihaa Contepomi added a comment - 27/Mar/12 3:26 PM I did some further testing and found MSVCR100.DLL eats a whole core after some time when HTTP Textures are disabled under the 'Advanced' menu (so the older UDP method is used instead). Do those of you getting this problem have HTTP Textures disabled? Do you notices any changes if you enable/disable HTTP Textures from Develop -> HTTP Textures & relog?
          Hide
          svenni mcmillan Svenni McMillan added a comment -

          I tested it with enabled and disabled HTTP Textures. But i can't notice any changes.
          Have seen too, that MSVCR100.DLL eats a whole core after some time.

          So i went back to 3.2.2 until the Bug is fixed.

          Show
          svenni mcmillan Svenni McMillan added a comment - I tested it with enabled and disabled HTTP Textures. But i can't notice any changes. Have seen too, that MSVCR100.DLL eats a whole core after some time. So i went back to 3.2.2 until the Bug is fixed.
          Hide
          maverick offcourse maverick offcourse added a comment - - edited

          new informations about that on https://jira.secondlife.com/browse/VWR-28388?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel

          It's a serious problem: I use to minimize the window to save cpu. But with new viewer versions the cpu stay al 100% and my notebook become HOT. Sometimes it shut down after 1-2 hours for overheating. It's impossible to use the viewer like that: i would set the issue to "critical".

          Show
          maverick offcourse maverick offcourse added a comment - - edited new informations about that on https://jira.secondlife.com/browse/VWR-28388?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel It's a serious problem: I use to minimize the window to save cpu. But with new viewer versions the cpu stay al 100% and my notebook become HOT. Sometimes it shut down after 1-2 hours for overheating. It's impossible to use the viewer like that: i would set the issue to "critical".
          Hide
          virtualban Virtualban Alex added a comment -

          I have found a workaround for the problem: when high cpu usage hits, just close firestorm, and open it again; repeat till you happen to not hit the problem. If you get to that, just make sure to never log off anymore, ever!

          On a serious note, though, I think I found a correlation between the problem and the land I am in. Happens more than half of the times like this:
          When on the land where the home is set, the problem shows up.
          When on any other land, the problem does not show up, and does not show up even when returning back.
          It fits my previous observations too. The problem started appearing regularly on my new land once I set home to the docks there.

          Feel free test to see if you have a lower occurrence of the problem when logging in a land far away from where home is set. Share the test results here please.

          Show
          virtualban Virtualban Alex added a comment - I have found a workaround for the problem: when high cpu usage hits, just close firestorm, and open it again; repeat till you happen to not hit the problem. If you get to that, just make sure to never log off anymore, ever! On a serious note, though, I think I found a correlation between the problem and the land I am in. Happens more than half of the times like this: When on the land where the home is set, the problem shows up. When on any other land, the problem does not show up, and does not show up even when returning back. It fits my previous observations too. The problem started appearing regularly on my new land once I set home to the docks there. Feel free test to see if you have a lower occurrence of the problem when logging in a land far away from where home is set. Share the test results here please.
          Hide
          maverick offcourse maverick offcourse added a comment -

          It happens everywhere to me

          Show
          maverick offcourse maverick offcourse added a comment - It happens everywhere to me
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Another thing to test please:
          Comment by Pixel on VWR-28388

          PixelProphet Lane added a comment - 06/Apr/12 2:27 PM

          I think I've found the solution.

          I already had Nvidia threaded optimization disabled for months, and this should be disabled at least in a driver profile you've created for the viewer.
          I have had HTTP Textures disabled for a long time as well, but I'm not sure if that matters (Probably it does).
          Today I decided to disable HTTP Inventory as well, and voila ... even after hours of being online, and having the viewer minimized for 10 to 20 minutes several times, my CPU load happily stays in ranges of 25 % to 36%. An exception of course is when you need to rez a lot, like after a teleport.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Another thing to test please: Comment by Pixel on VWR-28388 PixelProphet Lane added a comment - 06/Apr/12 2:27 PM I think I've found the solution. I already had Nvidia threaded optimization disabled for months, and this should be disabled at least in a driver profile you've created for the viewer. I have had HTTP Textures disabled for a long time as well, but I'm not sure if that matters (Probably it does). Today I decided to disable HTTP Inventory as well, and voila ... even after hours of being online, and having the viewer minimized for 10 to 20 minutes several times, my CPU load happily stays in ranges of 25 % to 36%. An exception of course is when you need to rez a lot, like after a teleport.
          Hide
          maverick offcourse maverick offcourse added a comment -

          It works. He found the problem! there must be a bug in the HTTP inventory feature of new versions!!
          In official viewer 3.2.5 you can keep it enabled without problems, in latest versions instead it's necessary to disable it or the cpu would have a core stuck to 100%.
          The HTTP texture doesnt affect the experience instead.

          Show
          maverick offcourse maverick offcourse added a comment - It works. He found the problem! there must be a bug in the HTTP inventory feature of new versions!! In official viewer 3.2.5 you can keep it enabled without problems, in latest versions instead it's necessary to disable it or the cpu would have a core stuck to 100%. The HTTP texture doesnt affect the experience instead.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Thanks for the feedback Maverick!
          Can other people test this please?

          Go to Preferences -> Advanced -> Tick show developer menu
          Then Develop -> Untick HTTP inventory & relog

          Show
          whirly.fizzle Whirly Fizzle added a comment - Thanks for the feedback Maverick! Can other people test this please? Go to Preferences -> Advanced -> Tick show developer menu Then Develop -> Untick HTTP inventory & relog
          Hide
          maverick offcourse maverick offcourse added a comment -

          Someone in the official jira ticket is telling that it is not a durable solution. Anyway i'm using it with HTTP inventory disabled, and it's still ok

          Show
          maverick offcourse maverick offcourse added a comment - Someone in the official jira ticket is telling that it is not a durable solution. Anyway i'm using it with HTTP inventory disabled, and it's still ok
          Hide
          fizz.savira Fizz Savira added a comment -

          I tried it with HTTP inventory disabled, and saw no real improvement. CPU Usage stays at 100% or more, though when minimized FOR AWHILE ONLY it dropped down to something reasonable. After my inventory finished loading, it climbed back up to 200% and stayed stuck there.

          Avatar was just standing still, AO moving it around, but that was it.

          Show
          fizz.savira Fizz Savira added a comment - I tried it with HTTP inventory disabled, and saw no real improvement. CPU Usage stays at 100% or more, though when minimized FOR AWHILE ONLY it dropped down to something reasonable. After my inventory finished loading, it climbed back up to 200% and stayed stuck there. Avatar was just standing still, AO moving it around, but that was it.
          Hide
          fizz.savira Fizz Savira added a comment -

          I tried this workaround in the latest official SL viewer, and noticed that it worked... For awhile. Eventually, the viewer regressed to using a great deal of CPU. When it worked, and the window was minimized I was seeing about 8% cpu usage. Eventually, it stopped working and the minimized window was showing around 115% or more cpu. When the window was active, the cpu usage was over 200%. I'm putting this comment into the LL bug data as well.

          Show
          fizz.savira Fizz Savira added a comment - I tried this workaround in the latest official SL viewer, and noticed that it worked... For awhile. Eventually, the viewer regressed to using a great deal of CPU. When it worked, and the window was minimized I was seeing about 8% cpu usage. Eventually, it stopped working and the minimized window was showing around 115% or more cpu. When the window was active, the cpu usage was over 200%. I'm putting this comment into the LL bug data as well.
          Hide
          vicky_aura Vicky Aura added a comment - - edited

          Something repeatable I´ve noticed:

          Wait until everything is rezzed and the texture console is "empty".
          Open the conversation floater.
          Move the mouse pointer over that conversation float. no need to click on it. just move it over the floater.
          Wait a few seconds and check the fps.
          Then, without moving the camera of course, move the mouse pointer over something "inworld". an object of your choice. Doesn´t matter if that object causes a tooltip to be drawn or not.
          Wait a few seconds and check the fps again.

          I´ve noticed a drop from 30 fps to 24 fps when the mouse pointer is over something inworld.
          So I´ve a 25% fps increase when I keep the mouse pointer over the conversation floater. (it seems to work with every UI element)

          Seems a bit "strange" for me.
          I hope that observation helps you a bit.

          Show
          vicky_aura Vicky Aura added a comment - - edited Something repeatable I´ve noticed: Wait until everything is rezzed and the texture console is "empty". Open the conversation floater. Move the mouse pointer over that conversation float. no need to click on it. just move it over the floater. Wait a few seconds and check the fps. Then, without moving the camera of course, move the mouse pointer over something "inworld". an object of your choice. Doesn´t matter if that object causes a tooltip to be drawn or not. Wait a few seconds and check the fps again. I´ve noticed a drop from 30 fps to 24 fps when the mouse pointer is over something inworld. So I´ve a 25% fps increase when I keep the mouse pointer over the conversation floater. (it seems to work with every UI element) Seems a bit "strange" for me. I hope that observation helps you a bit.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Hiya Vicky,

          That makes sense, others are seeing the same. See issue FIRE-5657.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Hiya Vicky, That makes sense, others are seeing the same. See issue FIRE-5657 .
          Hide
          vicky_aura Vicky Aura added a comment -

          Thanks Whirly,
          sorry didn´t saw FIRE-5657

          Show
          vicky_aura Vicky Aura added a comment - Thanks Whirly, sorry didn´t saw FIRE-5657
          Hide
          virtualban Virtualban Alex added a comment -

          Came here to give feedback on the http inventory: not working at all for me;
          Neither http textures or any combination between http inventory and http textures.

          I did that what I suggested, once getting a good login I did not log off for most of the weekend, till a crash forced me out.
          Need to control addiction

          Since here, feedback on the mouse in world: yes, it is like described. And not a small issue either, so, hope it gets fixed.

          Show
          virtualban Virtualban Alex added a comment - Came here to give feedback on the http inventory: not working at all for me; Neither http textures or any combination between http inventory and http textures. I did that what I suggested, once getting a good login I did not log off for most of the weekend, till a crash forced me out. Need to control addiction Since here, feedback on the mouse in world: yes, it is like described. And not a small issue either, so, hope it gets fixed.
          Hide
          argus John Trebel added a comment - - edited

          i tested http inventory: on/off: same thing. It doesn't help. "Nvidia threaded optimization" is useless too.

          Here my experiences briefly:

          1. The problem happens everywhere (no matter whether sim is home or not)
          2. The Original-LL-Viewer is much worse: CPU-Usage up to 65 %.

          Here again an information, that is maybe important for the developers:

          In opensim (OSgrid) Firestorm works much better. CPU-Usage stays at 30-35 % !
          (Except the issue, that i reported here: Selecting a Linkset increases one CPU-Core to 100%)

          In Osgrid the original-LL-Viewer behaves like in second-life.

          Maybe this gives one of the Developers an hint, where the issue is located.

          But this is for sure: The technic in Firestorm is better than the LL-technic.

          Show
          argus John Trebel added a comment - - edited i tested http inventory: on/off: same thing. It doesn't help. "Nvidia threaded optimization" is useless too. Here my experiences briefly: 1. The problem happens everywhere (no matter whether sim is home or not) 2. The Original-LL-Viewer is much worse: CPU-Usage up to 65 %. Here again an information, that is maybe important for the developers: In opensim (OSgrid) Firestorm works much better. CPU-Usage stays at 30-35 % ! (Except the issue, that i reported here: Selecting a Linkset increases one CPU-Core to 100%) In Osgrid the original-LL-Viewer behaves like in second-life. Maybe this gives one of the Developers an hint, where the issue is located. But this is for sure: The technic in Firestorm is better than the LL-technic.
          Hide
          gwylym William Wilson added a comment - - edited

          On os x lion with firestorm 4.0.1 (27000). Cpu hangs around 140%. Have two cpu's in my mac. Any way to get this down?

          addition: I made the change to the developer menu as noted above. Before running firestorm my cpu usage is about 4-7% user and 4-5% system. I had a few spikes to over 140 and now it is hovering around 60-70%. At least for now.

          Show
          gwylym William Wilson added a comment - - edited On os x lion with firestorm 4.0.1 (27000). Cpu hangs around 140%. Have two cpu's in my mac. Any way to get this down? addition: I made the change to the developer menu as noted above. Before running firestorm my cpu usage is about 4-7% user and 4-5% system. I had a few spikes to over 140 and now it is hovering around 60-70%. At least for now.
          Hide
          fizz.savira Fizz Savira added a comment -

          I just posted this info on the SL Jira for this issue. I'm posting it here because maybe a firestorm dev can go "aha" and fix the problem Or use my workaround. Who knows!

          Sooooo, I dusted off my programming skills and took a look at this, using the excellent info from Zi Ree above.

          The problem is that in the llcurl code, one of the calls to addEasy is failing. It generates this message in the log file:

          check_curl_multi_code: curl multi error detected

          Because the call is failing in addEasy, the curl library is never doing anything with the requested post of the viewer statistics. Because that isn't going anywhere, the texture fetch code that is triggering a TFReqSendMetrics thinks that it's thread needs to run all the time because the state variable mCurlPOSTRequestCount is incremented and then never decremented.

          A workaround is to comment out in the lcl_responder constructor and destructor methods the calls to incrCurlPOSTCount and decrCurlPOSTCount, respectively.

          I have no idea what the consequence is of commenting those lines out. But with a viewer I built with just that change, it works fine. I can minimize my viewer window and it quietly sits there without chewing up resources.

          Before that change, after the 600 second timer fires in the viewer that triggers the TFReqSendMetrics, the viewer will suddenly go busy because the texture fetch thread is spinning for the reasons I described above.

          Of course my workaround is just that, not a real fix. The real question is why is the call in addEasy failing? I did notice that the code to check for such an error and return the status is commented out! So there are probably some bigger issues here than just enabling that code again. Tracing the code paths that I looked at, it seems that even if the error status is returned, in many cases most of the callers are ignoring it anyways.

          Show
          fizz.savira Fizz Savira added a comment - I just posted this info on the SL Jira for this issue. I'm posting it here because maybe a firestorm dev can go "aha" and fix the problem Or use my workaround. Who knows! Sooooo, I dusted off my programming skills and took a look at this, using the excellent info from Zi Ree above. The problem is that in the llcurl code, one of the calls to addEasy is failing. It generates this message in the log file: check_curl_multi_code: curl multi error detected Because the call is failing in addEasy, the curl library is never doing anything with the requested post of the viewer statistics. Because that isn't going anywhere, the texture fetch code that is triggering a TFReqSendMetrics thinks that it's thread needs to run all the time because the state variable mCurlPOSTRequestCount is incremented and then never decremented. A workaround is to comment out in the lcl_responder constructor and destructor methods the calls to incrCurlPOSTCount and decrCurlPOSTCount, respectively. I have no idea what the consequence is of commenting those lines out. But with a viewer I built with just that change, it works fine. I can minimize my viewer window and it quietly sits there without chewing up resources. Before that change, after the 600 second timer fires in the viewer that triggers the TFReqSendMetrics, the viewer will suddenly go busy because the texture fetch thread is spinning for the reasons I described above. Of course my workaround is just that, not a real fix. The real question is why is the call in addEasy failing? I did notice that the code to check for such an error and return the status is commented out! So there are probably some bigger issues here than just enabling that code again. Tracing the code paths that I looked at, it seems that even if the error status is returned, in many cases most of the callers are ignoring it anyways.
          Hide
          virtualban Virtualban Alex added a comment -

          Firestorm 4.1.1.28744
          Core 2 Duo @ 3 GHz, Windows XP SP3, 3 GB RAM as recognized by 32 bit OS.

          Firestorm window out of focus. GPU load ~ 25%, Framerate ~ 12 FPS. During all the test scenarios, GPU load and framerate remain the same.

          When the problem of this thread appears, I got these situations:

          1) Firestorm affinity to both cores: CPU usage 65% to 75% of total CPU power of both cores;
          2) Firestorm affinity to one single core: CPU usage 50%, or 100% of that single core.
          3) Firestorm affinity to both cores, but with KMPlayer high priority playback getting about 25% of the total CPU power: Firestorm gets about 60% CPU usage; System Idle Process at about 15%;
          4) Firestorm affinity to one core, and KMPlayer with both cores available again at 25%: Firestorm gets 35% to 40% of the CPU for both cores, or 70-80% of that single core it is being forced to. System Idle Process at about 35%.

          The bug is still there, just masked better.
          The previous version of Firestorm would take any available CPU given to it, and the high temperatures that come with it.

          Show
          virtualban Virtualban Alex added a comment - Firestorm 4.1.1.28744 Core 2 Duo @ 3 GHz, Windows XP SP3, 3 GB RAM as recognized by 32 bit OS. Firestorm window out of focus. GPU load ~ 25%, Framerate ~ 12 FPS. During all the test scenarios, GPU load and framerate remain the same. When the problem of this thread appears, I got these situations: 1) Firestorm affinity to both cores: CPU usage 65% to 75% of total CPU power of both cores; 2) Firestorm affinity to one single core: CPU usage 50%, or 100% of that single core. 3) Firestorm affinity to both cores, but with KMPlayer high priority playback getting about 25% of the total CPU power: Firestorm gets about 60% CPU usage; System Idle Process at about 15%; 4) Firestorm affinity to one core, and KMPlayer with both cores available again at 25%: Firestorm gets 35% to 40% of the CPU for both cores, or 70-80% of that single core it is being forced to. System Idle Process at about 35%. The bug is still there, just masked better. The previous version of Firestorm would take any available CPU given to it, and the high temperatures that come with it.
          Hide
          tzolkat Alex Carpenter added a comment -

          @Fizz Savira: That is some very useful information, and it corresponds exactly with the type of error I've been catching in the log file. I have a question though..

          Why does the Metrics Collector (the thing that sends stats to LL's servers) need to trigger the texture fetch thread to begin with? From what I can tell from the logs (I haven't had time to look at the code yet), the viewer is sending textual data, which shouldn't have anything to do with fetching textures. It could be that someone at LL made a mistake when writing that portion of the code. But I don't know for sure.

          Why libCurl is choking on the metrics data exactly the second time it needs to send it, and only on some hardware, is another question entirely. Forcing the viewer to send metrics at a faster rate seems to prevent libCurl from failing in this way (can be done by setting QAModeMetrics to TRUE in debug settings), but at the moment I'm not sure exactly why.

          The error in the logs mentions an invalid multi handle. I've been reading the documentation for libCurl at http://curl.haxx.se/libcurl/c/libcurl-multi.html and http://curl.haxx.se/libcurl/c/libcurl-errors.html to try and figure out what that might mean and how it figures into the issues described here and elsewhere.

          Show
          tzolkat Alex Carpenter added a comment - @Fizz Savira: That is some very useful information, and it corresponds exactly with the type of error I've been catching in the log file. I have a question though.. Why does the Metrics Collector (the thing that sends stats to LL's servers) need to trigger the texture fetch thread to begin with? From what I can tell from the logs (I haven't had time to look at the code yet), the viewer is sending textual data, which shouldn't have anything to do with fetching textures. It could be that someone at LL made a mistake when writing that portion of the code. But I don't know for sure. Why libCurl is choking on the metrics data exactly the second time it needs to send it, and only on some hardware, is another question entirely. Forcing the viewer to send metrics at a faster rate seems to prevent libCurl from failing in this way (can be done by setting QAModeMetrics to TRUE in debug settings), but at the moment I'm not sure exactly why. The error in the logs mentions an invalid multi handle. I've been reading the documentation for libCurl at http://curl.haxx.se/libcurl/c/libcurl-multi.html and http://curl.haxx.se/libcurl/c/libcurl-errors.html to try and figure out what that might mean and how it figures into the issues described here and elsewhere.
          Hide
          fizz.savira Fizz Savira added a comment -

          As best I can tell, it's using the texture fetch thread to send the metrics so it doesn't happen on some other thread. I think they are just reusing that thread because it does networky things?

          As for why libCurl is having issues, no clue. I think that is one of the pre-built libraries that the viewer uses, and it's possible that the version the viewer is using has a bug in it (likely) and nobody wants to update libCurl and cope with any new bugs. Just guessing!

          One thing I did notice is that (again, not 100% certain here) is that it seems that the usage of libCurl to "post" data is different than the vast majority of other usages of libCurl in the viewer (they all seem to be "gets"). Maybe that has something to do with the bug...

          I'm still building viewers with my two lines of changes in them until this gets fixed SIGH

          Show
          fizz.savira Fizz Savira added a comment - As best I can tell, it's using the texture fetch thread to send the metrics so it doesn't happen on some other thread. I think they are just reusing that thread because it does networky things? As for why libCurl is having issues, no clue. I think that is one of the pre-built libraries that the viewer uses, and it's possible that the version the viewer is using has a bug in it (likely) and nobody wants to update libCurl and cope with any new bugs. Just guessing! One thing I did notice is that (again, not 100% certain here) is that it seems that the usage of libCurl to "post" data is different than the vast majority of other usages of libCurl in the viewer (they all seem to be "gets"). Maybe that has something to do with the bug... I'm still building viewers with my two lines of changes in them until this gets fixed SIGH
          Hide
          tzolkat Alex Carpenter added a comment - - edited

          That would make sense, as I've not seen anyone document the problem in Linux, where I think libCurl is a separate package rather than being tied to the viewer version. I'm not 100% on that though.

          [Edit] Re-reading the LL JIRA, there are some reports of the issue appearing on Linux.

          Show
          tzolkat Alex Carpenter added a comment - - edited That would make sense, as I've not seen anyone document the problem in Linux , where I think libCurl is a separate package rather than being tied to the viewer version. I'm not 100% on that though. [Edit] Re-reading the LL JIRA, there are some reports of the issue appearing on Linux.
          Hide
          tzolkat Alex Carpenter added a comment -

          @Fizz Savira: This may be a silly question, but does the metrics data still get sent with your two lines of changes in place?

          Show
          tzolkat Alex Carpenter added a comment - @Fizz Savira: This may be a silly question, but does the metrics data still get sent with your two lines of changes in place?
          Hide
          fizz.savira Fizz Savira added a comment -

          No idea if it gets sent. I'm pretty sure the first one fails because of the error, but I have no idea of subsequent attempts work or not.

          Sorry, but my primary concern was to stop my computer from overheating, and my quick "not really a fix" does the trick.

          Show
          fizz.savira Fizz Savira added a comment - No idea if it gets sent. I'm pretty sure the first one fails because of the error, but I have no idea of subsequent attempts work or not. Sorry, but my primary concern was to stop my computer from overheating, and my quick "not really a fix" does the trick.
          Show
          liny_odell Liny Odell added a comment - Fixed in http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/509430c049a1

            People

            • Assignee:
              liny_odell Liny Odell
              Reporter:
              bay addens Bay Addens
            • Votes:
              13 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: