|
|
|
I'm voting for this because I have a very big and frequent problem with freezing viewer, I see dramatic disk activity when it's happening, I see the purging entry in the log Nicolaz mentions, and I hardly ever see such freezes with his client. Lindens please jump on this fix ASAP.
This is definitely the cause of recent viewer freezes I've been having.
I'm closing my last issues with patches here. This one is still valid but in the light of what that it's unassigned for four months and and in regard to what has been said about my patches on Pastrami's resident session, I guess it's a won't finish. Sorry to pull the rug under 13 voters, but I don't want to leave orphans behind. If anyone feels inclined to carry this further, feel free to reopen (and the Lindens have it on the internal tracker anyway). With all respect, Nicholaz, and well understanding your view: I am re-opening this issue nevertheless. This is still a terrible problem on my machine, and on others I have talked to. And it's NOT (usually) a 'crash' that fits into another jira issue; these occasional flurries of disk accesses just bring the SL session to a complete halt (mouse and all), but generally allow it to resume in 30 seconds or so, when the disk access finally abates. I should note that the disk access bursts tend to be come more and more frequent once they begin, and seem closely associated with cam'ing around busy scenes.
The problem is still there, it still needs to be fixed, and even if the Lindens don't care to roll in your patch, despite it apparently working fine – well, they need to find some other solution. Bringing SL to a dead stop like that for internal housekeeping makes a bad joke of the software design, and I'm sure they can do better than the status quo. For the record: CPU: Intel Core 2 Series Processor (1994 MHz) While I'm at it, I'll update the "affects version" to the current release version, as I was suffering through this again just last evening with 1.19.1.4. Updated the title too – it's more than a 'hiccup'.
Coyote ... you are of course welcome to reopen ... it's your thread now Nick One problem with the patch as-is is that it never calls purgeTextureFilesTimeSliced except in the destructor, which I am reasonably sure runs at application exit. The overall effect is that anyone who tested this patch had no cache purging whatsoever!
Obviously all you have to do is to call it at line 1452 after purgeTextures(), but, just FYI. Yup, oversight when making the patch. However, JFI: it's intended to be called outside of if (mDoPurge) { } I shopped this around internally, and learned that there are upcoming plans to rearchitect/refactor the cache system, which would include timeslicing purging over multiple frames. In light of that, I think it's a bad idea to import this patch as-is because a) it will be duplicated work and b) having more code in the cache system would make it more difficult to complete said project. If the timeframe for that project falls by the wayside or it fails for some reason, I'll be sure to revisit applying the patch.
I'll keep this JIRA open because the description of the problem in it is good, so it'll be easy for us to find and resolve once we solve it one way or another. No problem for me (I do want to mention though, that I appreciate the elaborate feedback). I am glad someone mentioned this issue existed as I thought it was related to the major Nvidia problems they have been having with the RCs. Lately (dont exactly know when this had gotten significantly worse - maybe the past week) I have noticed on both the 1.19.4 and the latest RC 1.20.5 viewers that my viewer hangs (not freezes completely - but rather I cannot move and the avitars around me and myself conitnue being animated - ie. dancing - but no more IMs and no more chatting and no moving). This lasts for about 1 to 2 minutes and then just releases. It seems to begin happening after a long session time (ie it does seem to appear within my first couple hours being online). I notice at the time that my disk drive is like solidly active.
I have suspected that it seemed to be a disk clearing activity that suspends the viewer but then I was wrapped up in the NVidia driver crash issues so I have just been suffering with this REALLY ANNOYING RECENT PROBLEM. I hate this long freezing as ppl around me think that I am not talking to them and I cannot send any indicator to them that i am just hung up. Is the work around for this problem that I should just re login? or is this a bug in how the viewers are handling the clearing of the cache in an improper manner? I cant understand why my version 1.19.4 has just recently begun to notice this. Is it this because of possible Server upgrades? Toysoldier @tt: You can try if my viewer fixed that. You'll find the download here: http://nicholaz-beresford.blogspot.com/
 I came here from
I think this was happening to my previous NVIDIA card (a 9600GT), but followed by a driver crash. And may explain why it never happened with my other computer, which is running a 7600GS with only 256 MB over an AGP bus, a far slower card with less memory, as well as slower graphics bus... could it be that the freezing bug is possibly worse with faster graphics cards? as I am not having it anywhere near as bad with the 8600GTS as it was with the 9600GT, and it has a 128 bit bus rather than the 256 bit PCI-E 2.0 bus that the 8800 and higher cards have. In fact I've really not noticed it on the new card, but I did reinstall Vista on my system and cleared out the disk quite a bit, might have had a huge impact now that I read this JIRA. could it be the faster the card, the worse this bug is? dunno. I've also had the same issue, and allthough I didn't check the logs I found it happened more often when I increased my cache-size to 1GB. I've since reduced the cache size to 500MB but I might even bring it down more. I'm glad it's not just my system
 This has sat without attention for quite some time. This would a great candidate for discussion on sldev. Can anyone demonstrate that pausing is actually happening here? Some kind of a metric would be really useful for bumping the priority of this task. Anecdotal tests internally haven't shown that this makes a difference.
Soft, can you (or someone) suggest a way of instrumenting this behavior for demonstration purposes? I suppose I could borrow a video camera and shoot a movie :-P ... the machine itself is pretty much unresponsive during these interludes.
@latransa - we know that pauses exist, but it would be helpful if you could show that they're attributable to this code. Setting up a timer that measures how much time is spent in this function in a frame, then perhaps displaying information in the viewer showing the worst 3 times in the last 100 frames would show that there was definitely a spike attributable to this function.
Soft, did you actually read the description and comments here? As the initial descriptions says, it's a matter of "multiple times a day" not something within a few hundred frames. Also the logging as an indicator that this function is called and how many time spent there is mentioned in the first two comments. Repro: Soft is planning on adding a little more logging code to help isolate the contribution that this particular code might have.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Reopened
Normal
Purging cache textures causes viewer. to pause for many seconds, with heavy disk activity
IE:
// NOTE: This may cause an occasional hiccup,
// but it really needs to be done on the control thread
// (i.e. here)
llinfos << "PURGING TEXTURES!!" << llendl;
purgeTextures(false);
mDoPurge = FALSE;
llinfos << "PURGING TEXTURES DONE." << llendl;
In this way we can verify if it is this culling process that gives the issues. As soon as I can figure out how to compile sucessfully, I will try and give this problem a good whipping. (If it's not already resolved by then!)
Cron