|
|
|
It is not linked to the operating system, I get very degraded performence with 1.21 under Linux as well, while 1.20 was okay (both maingrid viewer, and mono beta viewer).
I see this as a showstopper. There are so many similar jira reports about 1.21 RC, I did not even know into which one I would say "me too" Under linux, both CPU usage and memory usage are bad with 1.21. Here are some random stats, while avatar and region are more or less idle: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 66% CPU usage under Linux is catastrophical, most programs run usually under 1%. 1.20 was much lower. Second Life 1.21.0 (95157) Aug 26 2008 16:37:31 (Second Life Release Candidate) Context; CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3.3 c-ares/1.4.0 Another repro here on texture problems. I have several textures that load fine under 1.20 but will not load after 6+ hours logged into 1.21.
Second Life 1.21.0 (95368) Aug 28 2008 18:27:35 (Second Life Public Nightly) CPU: AMD (Unknown model) (1995 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 Thanks for reporting this. Although in a similar report,
It is possible that extremely slow texture loading could have been due to the rolling restarts of the server upgrade across the Second Life Grid. Has this bug continued over the past few days (Aug 31-Sept 2)? (See related VWR-8503)
OK, I now have been testing this release and the news is dire. I can crash this viewer in 5 minutes flat just by either flying through or sailing through several SIMs. Just before it crashes, there is strong evidence of buffer overruns: textures are rendered incorrectly, the Menus disappear, total stalls occur, water reverts to blue. A buffer overrun is a vulnerability wiating for an exploit. So, I am rasing this bug to showstopper. At the very least you ought to pull this release. I have been able to reproduce the same thing. 1.21 takes forever (or not at all) to rez objects, mostly textures. Going back to 1.19, everything rezzes within a couple of seconds.
CPU: AMD (Unknown model) (2412 MHz) OMG, like night and day! I reverted to: http://download-secondlife-com.s3.amazonaws.com/Second_Life_1-19-1-4_Setup.exe
 .They difference is astounding. Textures load within seconds. I can TP to different regions and I don't get the minutes long grey effects. I can fly or sail between regions without crashing, exiting a SIM then returning doesn't dump all my textures, and it's soo much faster. I'm done testing, back to 1.19 where I can enjoy SL again. I just tried running 1.19.0.5. It takes conseriable time to do these setups since I uninstall the previous viewer to prevent cross contamination issues. 1.19.0.5 is vastly better WRT memory leaks than 1.19.1.4, at it in turn is vastly better than the 1.20 or 1.21 releases. Nonetheless, 1.19.0.5 exhibits a slow memory leak. Texture loading is about the same as in 1.19.1.4.
I had to find a group of SIMs that were not affected by today's borked networking problem, but riding through those (texture rich) I could do so for two hours with no major loss of performance. There was some FPS loss at the end of the test and the working set of the viewer process show s indications of a slow but general rise in virtual memory. When I tried, earlier, the same on 1.19.1.4, the lag effects (and memory leak) appear after an hour or so but they seem to get better if I stay in the same SIM for a while (as in 5-10 minutes). With 1.20 & 1.21 the lag happens in minutes and the viewer crashes with an out of memory message (depends o nthe 1.20.x release, or just a crash dump with the 1.21 release. Going back to 19.0.5 was a bit of nostalgia where distant land looks like land and not shiny false ocean (see http://jira.secondlife.com/browse/VWR-4714 So, this texture loading bug looks to me to be a result of many mitigation attempts that have missed finding and fixing the root cause of a major memory leak. I was just working on a repro for this, using RFrye as my shopping control and orientation island public as an average garden.
My first load of RFrye was 15 minutes for 2900 textures, after a little jumping around between these two sites I thought (don't know why) to turn off multiple threads and the textures snapped into place fast and quick, RFrye dropped from 15 minutes to 2. For me, turning this advanced option off made all the difference. Second Life 1.21.2 (95596) Sep 2 2008 21:14:44 (Second Life Public Nightly) You are at 201081.4, 236945.4, 4061.6 in XXXX located at simXXXX.agni.lindenlab.com (216.82.17.190:13002) CPU: Dual i386 (Unknown) (2160 MHz) libcurl Version: libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 My experience is more like Balpien's. I tried Shibari's workaround but still found performance unacceptable. Many days after the SIM upgrades, I continue to see the problem. Thanks! -DK
I've tried the latest release, 1.21.RC2, and it looks like almost all of thememoty leak problems have been addressed (see VWR-8503). Texture loads remain much too long but at least the viewer no longer crashes on heavy texture churning.
Same issue here, watching at FPS, i have these results:
1.20 latest version : 11 fps to 13 fps the two tests are done in the same place, underwater, relogging from one version to the other, drammaticaly slow and unusable with my hardware (asus laptop) CPU: Intel Core 2 Series Processor (2194 MHz) Cia, please see if there is an update to your graphics drivers. Please note the issues raised here
You can check you have the latest graphics drivers by either going to your manufacturer's site or by checking here Thank you Great, thank you Ella, i downloaded the new nvidia drivers from asus for the laptop and now the difference is only 1FPS:
1.20 : about 12 fps so it was mainly a driver related issue, Well, now i can test the new 1.21 RC too. CPU: Intel Core 2 Series Processor (2194 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 New drivers is not the panacea, BTW. The problem still exists on 1st tier drivers. I am curious though whether this problem is getting LL developer attention.
I have the texture haIting/time out issue as well.
I stood around in my store today and after 3 hours I could count 4 textures loaded. I've read about what the others have written in the comments here and at the VWR-8503 and I would have felt lucky if my textures took 3-4 seconds a piece to load. I from time to time I don't see textures.. at all. I decided to try what Shibari suggested and I did manage to also see a slight difference in speed when I turned off multiple threads. I could see a raise in bandwidth use for texture loading from about 20kbps to about 350 kbps after turning it off, restarting client and tping to a sim. However... The texture loading still stalls or time out after a while and the bandwidth usage goes down to a halt (total bandwidth usage 0-10kbps... textures loading at 0kbps) while textures are still qued up for download (about 50% of the world still grey). I might be imagining but I got the feeling this problem was a tad better in the 1.21.3 version... and got worse in the 1.21.4. I'm aware that my gfx card is old... but that should not explain the fact that SL utilize 15% (at peak) down to 0.05% of my existing bandwidth for texture download while the world is grey. That's just scandalous resource utilization.I recently upgraded my internet connection from 256kbps to 2mbps and can't really see a difference in texture loading. DATA: Resolution: 1280x1024 I have 0.0% packet loss according to the SL viewer statistics and a ping time of aout 350ms. I'm on 2mbps down / 0.5 mbps upstream direct internet connection. I'm in Europe. Second Life 1.21.4 (98167) Sep 30 2008 15:28:25 (Second Life Release Candidate) You are at 251982.9, 246911.4, 27.2 in Roosa located at sim5420.agni.lindenlab.com (8.2.33.167:13001) CPU: Intel Pentium 4 (Unknown model) (3056 MHz) Cur, please check you have the latest graphics drivers by either going to your manufacturer's site or by checking here
Knowledge Base > Second Life Info > Solution Finder > Technical Issue > How do I get the latest drivers for my graphics card? Topic #: 4051-3884 http://secondlife.com/support/?questionID=3884
You might also consider updating your XP OS to SP3 as Nvidia recommends. Thank you I've been investigating some more...
With the texture console opened I can see that most of the textures (about 90%) get stucked in "DEC" mode. The http://wiki.secondlife.com/wiki/Texture_Console I can see textures loading in the texture console.. .but no textures appearing on my screen. That would comply with the fact that bandwidth utilization is so low (Images not downloading because the que/pipe doesnt empty itself when textures get stuck in decoding mode.) It would also comply with that the texture prioritation system doesnt seem to respond when zooming in on objects (I can see texture prio change but it doesnt change the speed of wich textures appear on the screen). It would also comply with the fact that this problem seem to differ somewhat between different versions of the client since it would suggest a client side bug. Ella,
I'm on a laptop so I do not use the common gfx card drivers. I have the latest gfx drivers that has been released for my card. Poor bandwidth utilization and bottleneck client code and/or system design has little to do with graphics drivers. I do however appreciate you trying to help out. Outdated Gfx drivers can sometimes bring strange problems. The only way I can see my graphics driver having anything to do with the problem is if they suddenly would be unable to decode the jpg2000 images. Has there been any changes to the jpg2000 standard lately? Ok... another update with some beta testing for you to help you pin point this. This testing ws done at the exact same spot with the camera pointed exactly the same way.
Scenario 1 (run 1) Scenario 1 (run 2) Scenario 1 (run 3) Scenario 2 (run 1) I no longer have the texture console showing me a lot of textures in "DEC" (decoding) status. Bandwidth for textures doesnt seem to drop below 100kbps while still having textures to download. Texture que seem to empty itself after a while. Textures are showing. Scenario 2 (run 2) Scenario 1 (run 3) Draw your own conclusions... but I get the feeling something is different in the RC code branch. Scenario 1 run 3 was actually different in the way the bandwidth usage not dropping as much as the others when the DEC stated textures filled the que up. But that might just have been a coincidence. I have some screenshots showing scenario 1 and 2. With the texture que and statistics window up if needed. Here some version specifics: RC Stable And just as a paranthesis... Ella, though graphics driver problem can affect this problem, it is turning out to be nearly insignificant as the root cause to this bug. We all know that now, as several of us have tested this on fully supported machines. I test this on NVidia and ATI chipsets from laptops (my usual entry portal inworld) to some high end ATI based machines. Advising people to go upgrade their graphics drivers, though a fine general suggest, does disservice to remedying this bug.
This bug relates to the use of UDP datagrams as the transport layer and insufficient methods to restart stalled downloads because of a packet drop. Texture downloads are extremely fragile and the loss of just one packet requires active management in the viewer to restart the stalled download. Since the root cause has not been addressed (switch to a reliable transport protocol), I assume the efforts to date have been to attempt mitigations: shorter timeouts, download watchdogs, etc. These mitigations probably lead to higher bandwidth usage, since restarts are data-losing (meaning some of what wasdownloaded has to be download again). Thus, it seems to me, that recent efforts to curtail that consequential problem have damaged the efficacy and timeliness of texture downloads. That said, this release seems to be worse about texture downloads in that textures sometimes just never load if one does not move to areas that contain new textures. It is as if various downloads have timed out and whatever mechanism used to be in place to restart them is now missing. Worse, when a texture download storm begins, the abiity to move around is seriously degraded with precipitous drops in viewer frame rates. The sense of lag is extreme. I verified this is a viewer problem by having two avatars be with me in the same spot as I experienced glacial movement. One person was running in the same subnet as I and the other was running in a different network path to the LL servers. Both of them were running 1.19 and in a second run both were running 1.21.RTM. The results were: Have you folks raised the priority of the texture loading threads in this latest viewer? That's not a great idea. I tried Zak's suggestion and I find toggling the Palletized texture option does restart the stalled downloads. Moving to a spot that introduces new textures for dowloading also restarts the stalled ones, though there is no guarantee that those textures do not subsequently stall. Dumping the texture cache restarts stalled downloads. I urge the developers to run a diff on the this release and the previous and find what was broken. We're piling errors upon errors, and black box testing begins to lose utility with too many compound or cascading bugs. Well! This RC is toast for me. I have now crashed over 50 times in three days. DUmps have been sent. The symptoms are:
log in - great great frame rates 20+, everyting is grey about a minute later some of the grey disappears, movements starts gettng a teensy bit laggy, frame rate 11. about 5 minutes later everythign has resolved, movement starts getting very laggy, frame rate drops to 6. as I move around, especially in a vehicle, lag gets extreme, frame rate 2. get on solid ground all movements laggy, UI laggy, frame rate 1.2 crash log in - great great frame rates 20+, everyting is grey (repeat) Lovely. Second Life 1.21.5 (98701) Oct 6 2008 10:27:21 (Second Life Release Candidate) happens anyplace, anytime. Tried the standard 1.20. It has that severe memory leak problem. I can no longer run events. I can no longer sail, ride a floater, ride a car. I can no longer walk around too much. I can no longer dance for more than a few minutes. I can;t take snapshots because that often crashes things. I can't go back to 1.19 which worked just fine. Am now finding buyer for my SIM. 1.21 is an absolute performance desaster.
If LL is not recognising this (everyone else does), so be it. There are a lot more virtual worlds out there with far less hardware demanding software. I finally have some videos that kind of demonstrate the differances. I hope to be able to post links to them later tonight (I dont have software to compress them to a differant codec)
I am able to run 1.19.1.4 but without the security patches that's an iffy route. Stil, I am at least able to perform comparisons which I reported in VWR-8503. I also tried out the 'cool' releases, but I am not seeing any substantive differences between them and the equivalent LL releases.
I have observed an interesting disconnect between the actual sze of the cache and the maximum setting. Running with the default cache size setting of 500MB, I found the cache would not rise about 300MB, and that's visitng texture rich areas. Furthermore, revisits to previous spots only 5-10 minutes later in the same SIM caused texture downloads to recur. Something is not right with 1.21.6. I would expect the cache to fill up before evictions take place. Can a Linden give us the nickel tour of the texture caching design? People, compare your current cache size with your cache settings. The Vista path is (using my name as an example): C:\Users\Balpien\AppData\Roaming\SecondLife\cache. First heres when images start to rez on the 1.20 viewer after clearing the cache and logging into the sn@tch store at the Pulse sim...
The 1.20 and the first 1.21 vid were started aproximately 30 seconds after being fully logged in (once xfire registered i was logged in and would respond for me). 1.20 http://www.fileden.com/files/2006/10/1/252408/loading%20on%201.20.avi now then on the 1.21 as you can see the really basic textures and objects loaded quickly on both but then everything else loaded much slower on the 1.21. in fact it wasn't till vid 3 that things that were loaded on 1.20 were loaded in 1.21. its kinda ridiculous. I'm sorry about the size but i dont ahve software to convert the codecs to anything smaller. Now admittedly the pulse store is kinda texture heavy but within 3 minutes after the end of the video here everything was loaded. It AlmostNEVER fully loads on the 1.21... Dan linden asked for logs of times the 1.21 viewer unsuccessfully loaded all textures and times of when it did and some 1.20 logs to compare.
heres one from the 1.21 it eventually laoded between 95 and 98% of textues but again not all of them... And heres another. this time it only laoded about 60% on 1.21.
and 1.20 where it loads jsut fine (though slightly slow today)
Please read my comments in http://jira.secondlife.com/browse/VWR-8503
where it looks like the cache scrubbing in 1.21.6 (and possibly several 1.20 RCs) cause continual download requests when asset servers get overloaded. People are reporting general confirmation of continual texture loading (see VWR-8503). I'm sure there are other problems with texture loading but if the viewers are taxing the asset servers, it affects all aspects of asset maangement - this needs to be fixed soonest. Lindens, any estimate of a fix? Hopefully before January???
Same experienc here.
Texture rendering is a total show stopper for me. I have spoken to many inworld. Mac, XP, Vista, Quad core, Duo core, clearing cache, cleaning HD, all graphics setting set to slow, avatar imposters on, multiple threads on and off, fast Alpha on and off, 512 video memory, 256.... it all makes no difference at all. this is totally rediculous and unplayable !!! WHEN IS IT SOLVED? WHEN ? WHEN ? WHEN ? Just to let ya know.. It is still suckin' and it is suckin' hard tooooo baby.. New or Nightly, the clients totally blow.
Same here - totally disasterous FPS drops, long texture load times, long prim rez times - I have NEVER known it this bad.
Second Life 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release) CPU: Intel Core 2 Series Processor (2050 MHz) Still happens in 1.22.RC2, just newer and different random effects: invisible objects during initial loading phase, changed priority/ordering of textures causing avies to be disrobed for lengthy intervals (making them non-PG). I still see the hack in which texture loading seems to run at higher priority than general rendering, causing frame rates to plummet in heavy texture loading situations. I see the problem of continual reloads are still there; all it takes is for any object within the view distance sphere to change its texture (common with fancier vendor objects) to cause a complete reload ofnearby trextures.
After a few weeks of testing and comparing 2.20, 1.21 and 1.22 RC made sure that circumstances were as much the same as possible.
My conculsion is final that 1.21 is way slower than 1.20 concering rendering. LL's Customer Services pointed out to me that my video card may not be supported. Nope ! ATI X cards are on LL's requirements. Or that i have not made sure that other circumstances had effect such as a slower internet connection. Nope ! Stronger, my little X600 renders like a flash in 1.20. When i arrive somewhere, all is rezzed and rendered in a few seconds, really ! Also avies render quick. but... not with 1.21, tested at around the same time and same sims ( both 1.20 and 1.21 cleared cache first before comparing ). 1.21 is sluggish as hell. Avie and tree rendering takes minutes ( was a few seconds ). I've been able to work around the problem a little with 1.21. All in all. 1.21 really isn't playable. And i just don't believe that a better graphics card solves the problem. No, the problem layes in the code of 1.21. This is almost no other possible conclusion. Good new? Try 1.22 RC.... and shiver.... Even worse ! If this is the path of SL and they don't improve it... i just can't play SL anymore after 1.20 is not supported anymore. Then it's Bye bye babies !! Just tried 1.22.RC3. Old bugs still there. New bugs appear, crash rate is higher. Love the pretty yellow (freinds) dots versus the green (not-friends dots).Nice eyecandy. On the other hand, the problem with high probability of a crash when taking a PNG snapshot is back again. FPS plummet to less than 2 when the neverending texture relaod cascade takes hold. And that really weird load textures without regard to distance or focus is a new thing.
And now, for the final insult, I noticed that my 8600M GT 256MB graphics adapter is now rated as unable to support the basic shaders. So, the LIndens bloated rendering and "solved" it by declaring the hardware as not capable? Sorry folks, I am not ditching a computer that is only one year old. So, I measured FPS with the latest release, horrid, and then went back to 1.21.6 (better), 1.19.1.4 (much better). For the first time using this latest viewer, I could not walk around smoothly. Flexis now deeply slow down rendering. I could not enjoy racing on a snow sled. The rendering was so choppy EVEN AT VIEW DISTANCE OF 64 that I could not participate. Went back to 1.21.6 and it was better albeit the damnable texture reloading problem. So, since once again the developers are marching lemming-like to make this code base the standard release, I now know when I leave SL. I am so happy outside developers are working on viewers for the other grids. I knew about those grids but thought to really work at characterizing problems here in SL because I liked environment. But now with insane price rises and 100 monkey style code development, I can no longer function here. It is not that I am leaving, it is that you folks are pushing me out. You still have time to remedy the exodus of goodbyes, but folks, the time limit is now only a few months. That's it! Is LL working on this issue or are they not ?? I have the feeling that the Lindens aren't taking this serious.
With new hardware, even the newest with all supported graphics 1.21 sucks big time. I keep loosing friends, because they say they can't play the game anymore since the update; they keep see everything grey over minutes and minutes, before anything starts to render/. Many ppl i speak inworld experience the same problem. Read my former remark Lindens.... WORK ON IT BECAUSE IT IS REALLY A HUGE PROBLEM The viewer is going totally the wrong way !! FIX IT !!!! PLEASE !!!!!! SHOW STOPPER ! Thanks for the comments and environments here. This report makes it clear that texture loading appears very worse in the 1.21 and 1.22 viewers, compared to 1.20.
This is nearly the exact same report also being tracked at VWR-8503. However to assist with clear tracking, I am closing this issue IN FAVOR of that report VWR-8503 – simply because that issue has more votes and watchers concerned about the same bug! Note, we are investigating this issue, and by closing this report as a duplicate is not to dismiss that the problem is occurring, and that it is frustrating. Please do continue to look for updates on VWR-8503. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Critical
Performance of 1.21.0 (95157) is abysmal (slow object rendering & textures loading)
.
CPU: Dual i386 (Unknown) (2400 MHz)
Memory: 2048 MB
OS Version: Darwin 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8600M GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28
libcurl Version: libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
J2C Decoder Version: KDU
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.17717 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 1/1742 (0.1%)