|
|
|
Maurice, I have to be honest: when a Linden tells me they "cannot duplicate" an issue that is experienced by users all over Second Life and has had mulitple JIRA postings... I tend to believe someone somewhere is not doing his/her job.
With all respect, this problem is so easy to duplicate a child could do it. Visit ANY region, ANY time of the day. Visit ANY market and try to click through vending items. I think I provided enough information above to easily trace and duplicate this issue. I have a Quad-core, 4gig RAM, 1 Terrabyte hard drive, Nvidia 512 meg 8800 graphics card and high-speed direct-cable access running at 6.5 mbps. So I don't think it's my computer, nor my internet feed... especially since this problem is experienced by users all over Second Life. Surely you're not telling me you haven't heard people all over the grid complain about textures loading so slowly. > In my profile it states that my home sim is ElvenMyst. Visit that sim and stand around inside the Castle (where supposedly object occlusion would limit texture loading). See how long it takes for the textures inside the castle to load. Try flipping through a vendor there and see how long it takes them to load. Visit Galifrey sim, the high-sky Novatech market display. Choose any vendor and click on a right arrow. Time how long it takes for the textures to show up clearly. Not enough information to duplicate? You have GOT to be kidding. ; ) Improper and incomplete examination by Linden Lab.
Just thought of another way for you to duplicate this issue:
Have someone send you a texture or photograph, and see how long it takes to rez on your screen. Last one someone sent me took 20 seconds to fully rez. Sometimes they have taken a minute or longer. That's not good. A minute to rez a simple photo? I know SL has a lot going on, but under no circumstances should it take that long for a texture to rez. System is borked, that's a fact. Another way to duplicate this issue:
Go to your own personal photo or textures folder. Pick any photo. Time how long it takes to fully rez on your screen. That's a direct load of one of your own photos from your own inventory. I've seen those take up to 2 minutes to rez fully. Others comment on the same. Whenever I send someone a photo, a common return comment is, "Still rezzing..." This problem is all over SL... and very easy to duplicate. wayfinder: I know this is frustrating but the Linden's are trying to rule out problems with the network between you and them, then they have more information to try and understand/fix the problem! Questions were:
What kind of internet connection do you have? Please post a copy of your traceroute between your system and data.agni.lindenlab.com in Windows: Start>Run - type cmd in the box and hit enter. A black terminal will open, type "tracert data.agni.lindenlab.com > trace.txt" without quotes Then open trace.txt and paste it here. Drew, I understand this fully... and that would be a valid response.. IF I were the only person having this problem... and IF I am experiencing severe connectivity problems. Neither of those is the case.
If you'll thoroughly read my response, I already answered the two questions you listed above. It's NOT internet connectivity problems; LL doesn't need to waste time barking up that tree. The issue is with the way they are handling texture loading; it's coding, pure and simple. 1) I am a systems analyst and I know the difference between connectivity / internet problems and bottleneck coding These things are not the case. This problem is experienced grid wide, by pretty much everyone. I mean, do they load properly for you, Drew? Do your textures and photos pop right up, no delay? If you want to test this Drew... examine your own experience with texture loading. Call up a photo from your inventory and time how long it takes for it to rez. Have someone hand you a photo and time how long it takes to rez. Wear a sculpty-based avatar and time how long it takes to rez. Drew, the issue itself is frustrating yes... because this has been going on for quite some time and only gets worse with every release. But what is REALLY frustrating is people continuing to mark this issue RESOLVED when it is not. A request for more information does not "resolve" an issue and only forces the item to be reopened time and time again. And what is frustrating as well is that LL seems to keep ignoring this problem or shuffling it off as a "user computer problem". This is not a user computer problem; it is internal coding and data management. The proper resolution for this issue: It's time for Linden Lab to realize this has been a problem for a very long time, is getting worse, and send in a system analyst to locate the problem and fix it. From what I've seen so far, that will probably entail completely re-working the way SL handles textures, because the way it's doing so now simply does not work properly. (PS. IF LL had an email address where private connectivity info could be sent, I'd be happy to comply with their traceroute request. However... 1) Many systems have security software in place specifically designed to stop traceroutes because they are used by hackers) and... If the Lindens want more info... an email address would be the solution. Second Life 1.20.15 (92456) Jul 18 2008 10:58:42 (Second Life Release)
You are at 289927.3, 267654.9, 295.7 in Croix located at sim3192.agni.lindenlab.com (216.82.20.181:13000) CPU: AMD (Unknown model) (1794 MHz) I realise my graphics card is sub-standard now for SL, but still the frame rate at my store in Croix is awful, and others who have visited my store have reported the same thing. A friend tolld me to check the lag meter and when I did, the meter told me that my client frame rate was under 10 fps, and that the possible cause was too many textures loading. It also sometimes says too many complex objects. My friend also had this reading and has a much better graphics card than I do. I think that Wayfinder's issue is very similar to mine and I wish this issue would please be addressed! As for replicating the issue, all you have to do is go to any sim where there is a store with many items for sale (I checked 4 different texture stores on different sims with the same frame rate of below 10). It does not take me 10 minutes to load textures, but the FPS is very low and I'm sure it is affecting business for many people trying to do business. Second Life 1.20.15 (92456) Jul 18 2008 10:58:42 (Second Life Release)
You are at 289905.6, 267644.1, 274.0 in Croix located at sim3192.agni.lindenlab.com (216.82.20.181:13000) CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (3005 MHz) View Statistics: Time Dilation 0.24 From SL lag meter: To many textures to load. Here what I notice in Croix, this bug start with the new update. The new client viewer also have the old zoming bugs of the cam when we teleport. How to duplicate, 1.- Find a textures seller store. More it have avatars in the same space, more it send warrning. Second Life 1.20.15 (92456) Jul 18 2008 10:58:42 (Second Life Release)
You are at 303117.2, 279744.5, 1111.2 in Kuyto located at sim7356.agni.lindenlab.com (8.10.146.104:13002) CPU: Intel Core 2 Series Processor (2400 MHz) Sorry for reporting in so late, this is bugging me since the new viewer was released already. Just I was busy and alot on the same locations so the effects are bearable. Because of that same reason I'm not sure if it was already so in the RC versions I used. Indeed opening any picture or texture NOT present in the cache takes at least 20 seconds to load, I can reproduce that at a 100% rate, no matter where or when. My connection is ADSL and certainly should be fast enough to download textures in less than a second. Any additional info required let me know I'll gladly provide. 25-30 seconds to fully rez a 512x512snapshot or texture from inventory
comments on slow loading of texturesreported several times on the sl blog since the new viewer update texture intensive sims take minutes to appear causing visitors to complain of "lag" and leave you get my vote wayfinder First: If you haven't already, hit CTRL-P or OPT-P then go to Network, set bandwidth for 1500, see if that helps.
Second: I've noticed myself that textures seem to be loading more slowly with newer versions of the client. Now 1.7 was a showshopper, where everyone and everything was gray for weeks on end, but slow texture loads are annoying. I have no 'proof' to offer, other than the experience is different, and my connection, bandwidth or network have not changed through time. Unable to duplicate? Wow, I think we need to get the Lindens to try this from home instead of their company local network. This is not, Maurice Linden, a network problem. But just to be sure, I am going to fly down to San Francisco this weekend and take measurements from the Microsoft lab right near your colo facility to clearly set aside the incorrect network connection problem assertion.
Regions: I test this problem in 90 regions and the results were the same, textures take 10 seconds some sometimes minutes to load. The problem is worse with a smaller cache because the cache is being churned. The problem has gotten much worse recently because the latest viewers seem to toss textures when you leave a region (and also manage to memory leak them, but that another showstopper bug). Here's a partial list: Balance, Oak Grove, Bethel, Fortuna, Gibson, Morris, Onnuri, Gilbert, Kkotsam, various Help Islands, Here (wild colors) time of day: Various - 19:00 - 23:00 0:00-03:00 09:00 - 11:00, 15:00 - 19:00 Connections: Connection 2: Maurice, when you run the SL viewer, are you accessing the system within the Linden Labs firewall? That is, are you bypassing the perimeter servers that everyone else goes through.
This is the results of loading one texture in a spot that has few other textures. The download hang for many seconds. The texture console indicates "SIM" status.
In the previous observation, is the "SIM" status indicative of an asset server stall? Or, a network packet loss and subsequent timeout. I do see "NET" status appear though rarely and for only a brief moment if it does.
Odd, I was starting to run a few tracert from different lcoations but it looks like LL has blocked that capability, that after Maurice asked us to try that. So, I performed a few reverse tracert from gateways in the general vicinity, and they all show decent latencies. Here's one:
Executing 'traceroute traceroute to 24.41.39.22 (24.41.39.22), 30 hops max, 40 byte packets I conclude there is no major neterok problem here. Furthermore, having asked several people across the U.S. and Eruope to give me their texture loading problems, I know they have the same experience as reported by people who have resonded to this bug report. I conclude this is systemic and not just something one or teo people experience. OK, now with the silliness dispensed, let's attend to this bug, Lindens. There seems to be a long stall, often 10-15 seconds in the middle of a download. Would you folks at least look into that and respond with your initial assessment as to the nature of this stall. I am sending a copy of the texture viewer to Maurice and Workingonit. Here's some help with reading the texture console: https://wiki.secondlife.com/wiki/Texture_Console
 First, I assume "Textures loading worse than ever since new upgrade" means
"Textures loading is slower in the 1.20.15 (92456) viewer than in the 1.19.1.4 and older viewers". If that's wrong please correct me so I may redirect my testing. wayfinder wishbringer, I have a couple questions about your particular setup: What resolution do your run SL at? SL run at higher resolutions > downloads larger, higher detailed textures > greater time for texture download completion. How much Bandwidth is your avatar + attachments using? You can find this by going to an empty region or face the ocean at the edge of a region, turn on View menu > Statistics Bar. Watch the Bandwidth meter, just below the FPS meter and see what your average Bandwidth is. The Bandwidth your avatar uses contends with the Bandwidth for downloading textures. Balpien Hammerer, I see the stall in the middle of texture downloading. I'll look into whether that stall is new or has always been there. So far, my texture download testing indicates textures are downloading at the same speed they did back in 1.12 and 1.13. I'll keep investigating. Dan thanks for responding, much appreciated.
My typical resolution: 1680 x 1000 Also, I had looked at that wiki page though I think it is out of date. It does not describe the 'NET' state. Dan, with all respect (and I mean that... so please don't take offense, but)... this is the kind of corporate BS that so regularly exasperates people with Linden Lab.
I'll tell you why I say that: Because I use SL every day, 6 hours and more a day and I know how it runs from a user standpoint. I know when it's running well and I know when it's not running well and four times in the past I predicted with almost pinpoint accuracy a major, grid-wide systems crash. I'm no newbie and I'm no gullible idiot. Because I spent most of my career working as a systems analyst, professional programmer and corporate consultant / watchdog and while I don't know everything (in fact less every day as technology progresses at such a fast rate)... I do know the difference between avatar bandwidth needs and system asset server malfunctions, My avatar is about as close as you'd want to come to zero-resource. No flexis, no sculpties, near zero lag factors. Because no matter what my avatar and no matter what my bandwidth, when I am zoomed in on a merchant vendor to the point it takes up my entire screen (thus according to LL claims, supposedly occluding all other prims and graphics-influencing factors), and the texture on that item still takes up to 2 minutes to load, when I've been in that area for half an hour already (which is far enough time for every texture in my view to load), when I reduce my view to 64 m and textures STILL take that long to load, and when I pull a photo from my own inventory and it takes 10, 20, 30 seconds or more to rez... that points to two possible things: either a severe asset server bottleneck or even worse, intentional corporate policy to make other areas work better due to excessive corner cutting. (And frankly, I think either or both of those issues could be the case here). Which is why we have pointed out over and over that the whole texture system needs to be re-thought, re-designed, and gone over with a fine-tooth comb. On Second Life, any texture that takes more than one second to load is going to seriously bog down and hamper user experience. I don't remember if I've said this already or not, but think about it: curently individual textures are taking 10, 20, 30 seconds or more to load. Yet, when we enter a sim, textures are obviously loading like wildfire, because if they didn't, the entire sim at 20 seconds a texture would take HOURS to load. (1000 textures x 20 seconds each = 20,000 seconds = 333 minutes = 5.5 hours.) So obviously, those textures are loading pretty fast. So why is it, when we have been standing in a sim for quite some time, either shopping to talking to our friends, when the basic existing textures have had plenty of time to load.... why is it that clicking on a merchant vendor turns the screen gray... gray... gray... fuzzy gray... fuzzy gray... blotchy fuzzy gray... blotchy gray... blotchy colors... blotchy colors... unfocused colors.... and finally after 20-30 seconds, that picture appears. And it's not even a hi-rez picture Dan... it's a simple 512x512. Why should an individual texture ever take that long to load. Bottom line: considering texture request time, system load time, internet transfer rate... about one second flat... or faster. 20 seconds? Totally unacceptable. Users all over the grid have been harping on this one for as long as I can remember, but instead of improving it's just getting worse. Dan, I have a quad-core computer with 4 gigs of RAM, an Nvidia 8800 512meg graphics card and a direct-cable connect (not wireless, direct cable) of 6.5 mbps. As one Linden told me once in person, "That's not only fast, it's faster than 98% of the user systems on SL". So bottom line--again – it's not the customers. It's the system. And anything that you can do to ferret out this problem and put an end to it will be not only greatly appreciated by your customers, it just might help SL survive the virtual food fight that's about to hit the Internet like the World Wide Web did back in '95. Thanks for the post Maggie. My only question here is: since that post exists (and so obviously LL is well aware of the problem) why do we have Lindens continuing to tell us things to the contrary? I have literally had Lindens tell me everything under the sun and ask me all sorts of questions that indicate they don't believe there is an issue. I had one Linden in particular tell me she "could not duplicate the issue".
That kind of thing is what makes us customers wanna kickalinden. My recommendation to Linden Lab at this point: there is very little that is more detrimental to the everyday experience of Second Life than slow-loading textures. So fix it. Instead of making excuses and putting it on the back burner... just fix it. Slow texture loading involves everything from lag to avatar rezzing (why does it take 2-3 minutes just to load a new skin?), to sculpty appearance... to the very important customer shopping experience. I just hate trying to shop when I can't get a silly merchant vendor texture to load for 2 minutes. I give up... and so do others. I'd say there is no one thing on SL that loses more potential L$ sales than slow texture rezzing. I'd estimated it loses hundreds of thousands of sales a day... possibly millions. Who knows for certain, but I know there have been many, many times that I've gone shopping and just finally left in frustration... sometimes even logging off SL. So Linden Lab, please fix this. Not next year, not 2 years from now. Fix it now, please. It needs fixed. Frustrated customers do not invest in Second Life. The wiki teaches us that textures are sent across as UDP datagrams, so all it takes is one dropped packet and downloading stalls until either some other event convoys it through or a timeout expires?
I tried a controlled experiment in which I downloaded various 512x512 textures one at a time and carefully watched the download state (I might get motivated to install a network packet timer, but stopwatch works well enough for now). The total time of any of the downloads was primarily dependent on the number of stalls I observed. When a stall occurs download usually resumes approximately 10 seconds later. So, my downloads are quantized to roughly 10 second boundaries. In one (rare) case when the download did not appear to stall, the texture loaded and fully rendered in 3 seconds. Next I tried multiple texture downloads using multiple copies of the texture viewer. With two simultaneous downloads, a stall of one stalled both. Then about 10 seconds later, they both resumed, and so the time for both downloads to complete together was approximately 10 seconds times the number of stalls. Since this is looking like a fragile packet loss timeout restart problem, was the timeout increased somewhere along the 1.20 development cycle? Also, as I mentioned earlier, in the middle of the 1.20 RC cycle, people were bitterly complaining of bloated caches (including me), and I saw a change to cache management that aggressively dumped textures of exited regions. I can see how a combination of agrressive cache scrubbing plus an increased packet loss timeout could exacerbate the texture download stall. It is extremely bad for people who live in multi-region communities. The act of wandering between regions keeps blowing textures that will be revisited soon and the long stalls makes the world a grey and cardboard looking place. Looks like you've hit on it Balpien... and your findings agree with the above listed LL post. Linden Lab has stated the problem is with the UDP method (which is what I and others have been saying all along... it's internal systems process)... you have verified that problem with (I must say) some pretty ingenious tracing, so what is left now is FOR LINDEN LAB TO FIX IT. ; )
Hey guys, seriously, I'm not trying to climb your case here, but do you see from these posts how upset customers are with this problem? Slow texture loading greatly hampers the entire SL experience and may be a major reason you are losing paying customers. If not for our sake, then for your corporate bottom line... PLEASE FIX THIS. This should be a top-priority, black and white matter. (Sorry, a bit off topic, but...)
Thank you Maurice Linden to immediately reply to this bug report. Now there are about 10000 other bug reports or feature requests in this JIRA... Someone removed my comments in which I reported this problem exists in the 1.21.RC release. They also removed the addition of 1.21 as part of this bug.
OK, I now have been testing this release and the news is dire. I ncan crash this viewer in 5 minutes flat just but either flying through or sailing through several SIMs. Just before it crashes, the 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. Sounds great Balpien. I wanted to list it as "showstopper" to start with, but often receive a lot of flack for doing so. But I agree. This texture render problem has gone from bad to really bad. I've always considered slow texture loading to be one of the main serious problems on SL, but never could get LL to listen. You'd think that losing millions of potential customers would have woke someone up to the problem... but still it exists. Like someone said (I forget who), 'doesn't really matter if you can log on if you can't see what's going on around you.'
Anyone who has ever tried to do some serious shopping knows what a problem slow texture loading is. A shopping trip that should take 15 minutes takes 2 hours because we can't get the textures to load... and apparently now the texture system is so borked it's overflowing memory and crashing the viewer on a regular basis (and to be honest, has probably been doing so since SL was first implemented. People have been regularly crashing for years... they just didn't know why). So you're absolutely right... that's showstopper. (three related bugs and I'm not certain which one the Lindens are paying attention)
OMG, like night and day! I reverted to: http://download-secondlife-com.s3.amazonaws.com/Second_Life_1-19-1-4_Setup.exe Thx alot both Balpien and Wayfinder for all the research and info, if only your lastnames were 'Linden'.. To bad I'm building above the 768m limit all the time, or I'd be back to 1.19 right away. I do know it saves me time and agony installing 1.19 temporarily just for the purpose of shopping and exploring at least.
Hi Balpien. I downloaded and tested v 1-19-1-4 to try to verify your findings. Unfortunately, could not do so. I couldn't give it a thorough testing, but here were my findings:
Oh, one thing I did notice hower... without being exactly able to put my finger on a "why"... 1-19 did seem more "responsive" overall. Things just seemed to work faster, better, more smoothly. Like simqt, I can't go back to 1-19 because I build above 768m on a regular basis now, but it's for sure than whatever they did in 1-20... it seems to have caused more problems than it solved.
One MAJOR difference of 1-19 is what Balpien noted above: it does not dump textures ever time one turns around. One of the major problems with 1-20 is that it doesn't retain textures properly. Shoot off a poofer now... and then do it again 5 minutes later and 1-20 has to load the texture all over again. 1-19 retained the texture and had no such problems. So 1-20 constant reloading of textures is a real problem. Wayfinder, 1.191.4 is not perfect by any means. I am overjoyed to find that the sullenness of my inworld experience is a direct consequence of suffering through most all of the 1.20 (and now 1.21) viewers. For a brief moment (around 1.20 RC12) there seemed to be forward progress, but that improvement was totally destroyed in subsequent releases. This memory leak problem is in 1.19.1.4, it takes much longer to exhibit, and I begin to wonder whether the windlight development introduced it. I will try 1.19.0.5 (pre WL I recall) and see how that goes. Also, in 1.19.1.4, texture loading still jams up, as you described, but it happens much less so. For most purposes, the initial preloads are tolerable when cruising through the world. I agree that for detail work such as shopping, being in a presentation where virtual slides are being displayed, or building, the datagram approach to texture loading is entirely inadequate.
Several mitigations have been applied to the 1.20 and 1.21 releases (texture dumping, heavy post-distance view trimming, heavy object occlusion, possible increase in the datagram timeout) but no one at LL has fixed the root causes, that a memory leak somewhere in the system, probably in the texture caching, along with an unreliable texture loading transport protocol is causing almost all of the reports of lag. Those two critical problems have been there since at least 1.19.1.4. I really love the new features and the true bug fixes the post date 1.19, but these deep bugs need to be fixed first. And now that 1.21 seems to be exhibiting buffer overruns (a third showstopper bug), it is critical to get this fixed as top priority. I know debugging and maintenance work is not fun, and not as glamorous as developing new features, but it is part of the job description (at least I hope so in LL). I will be happy to test fixes to any and all of these three showstopper problems. In the meantime, I recommend most people revert to 1.19.1.4. Builders above 768 and mono script workers will have to use 1.20 and 1.21 respectively, but they will have to save their work and relog periodically. What a horrid mitigation that is. 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've tried to repro these issues on my home system. I'm on AT&T 1.5Mbit, and not behind the Linden firewall. Here's what I've found so far.
Hi Dan. With all respect... I think the above reply is all completely moot except for one thing: "We want HTTP textures implemented soon".
Consider please: how long exactly would it take to do this? How long to switch the coding from UPD to HTTP? A day? Two days? I'm not on the inside so I have no way of knowing, but most coders in most such situations (unless it's hopeless spaghetti code instead of called functions) would consider this a one hour job, maybe two hours tops. Find the routine, rewrite routine, compile... I'm not trying to over-simplify. I am pointing out that this problem has gone on for YEARS.. .ever since the inception of Second Life... ever since Linden Lab chose to use UDP. How much eye-candy stuff has Linden Lab incorporated since then, spending thousands of man hours... instead of the ONE thing that would have improved Second Life 10,000%.... that of fast loading textures? Nothing else could have compared. Not flexis, not sculpties, not Windlight, not Dazzle, not movies or sound. None of those things could have possibly been as beneficial to Second Life, its users (and thus ultimately Linden Lab) as fixing the texture problem. FIVE YEARS (at least). That's how long this problem has existed. So how much longer are we supposed to wait? I'm not going to volunteer to do a test between 1.19.1 and 1.20.15... because that is an absolute waste of time. Answer to that quandry: FIX THE TEXTURE TRANSFERS. Difference between the two versions instantly becomes ignorable. I'm not going to volunteer to test texture unloading. That is a waste of time. Solution: FIX THE TEXTURE TRANSFER. Textures on selected objects already get higher priority? Not in my experience. I can be standing at a market and EDIT a vendor... and still wait 30, 40, 50 seconds for the textures to load. Solution: FIX THE TEXTURE TRANSFER. Want people to stop leaving Second Life, to start enjoying Second Life, to stop being bored to tears while shopping or rezzing or teleporting? FIX THE TEXTURE TRANSFER. I mean, what kinda 2x4 does Linden Lab need whopped with before the company realizes that textures area one of the top priority issues right now? I went shopping with a friend last night, and what should have been a 20 minute trip turned into 2 hours as we waited and waited and waited and waited for hundreds of textures to load. I can't sort and group the textures in my inventory because of the excessively ridiculous time they take to appear on my screen. 30 seconds + per texture? I have THOUSANDS of textures to sort. Even if they take one second apiece it will take me hours to sort them all. I wouldn't really mind it at 1 second apiece. At 30 seconds apiece I'm not even going to start tackling such a project. If I were to make a somewhat-educated guess as to the #1 things that have caused people to shut down Second Life and find something else to do, they would be this:
... in reverse order. Crashing happens. One or two crashes a day are irritating, but not system-threatening (it should be fixed, but we can relog). Lag is a royal pain and needs to be addressed (I could go on all day about that one... but it's pretty obvious fixing lag is not on LL's high priority list. If it was you folks wouldn't have brought in all the high-lag stuff you've been incorporating lately). But texture loading... now there is THE issue. It doesn't do any good to log into Second Life, if we can't see what's around us. If textures are visible we can even handle lag. We'll just stand in one place and camera shop (which is why distance occlusion was such a very, very bad idea on LL's part. Can't camera shop past 20m if we can't see the objects due to distance occlusion). Dan, it all comes down to textures. You're a friendly Linden and I have no doubt you're trying to solve this problem, but I've always felt LL goes about solving problems such as this the wrong way. The company seems to stew and fret and him-haw and then when a decision finally is made... often months or even YEARS later... half-baked solutions implemented (I mean.. 25 groups? Ugh). The right way to fix these problems is simple: kick the bureaucracy in the butt, kick the coder-egos out of the way, and get things fixed OR ELSE. In short: someone just needs to take the horse by the reigns and kick it in the slats. That this and similar problems have gone on for so long is (I'm sorry for being so blunt) just plain inexcusable system management. Changing from UDP to HTTP should be a relatively simple process (at least when compared to implementing Windlight and Havok 4 all within the same week... ). So my personal recommendation to Linden Lab: drop your other, far-less-important projects, stop the eye candy and the piddly little this and thats and FIX THE TEXTURE TRANSFERS. Then watch how much the Second Life experience improves... instantly... overnight. "Consider please: how long exactly would it take to do this? How long to switch the coding from UPD to HTTP? A day? Two days? I'm not on the inside so I have no way of knowing, but most coders in most such situations (unless it's hopeless spaghetti code instead of called functions) would consider this a one hour job, maybe two hours tops. Find the routine, rewrite routine, compile..."
Reading the above part of Wayfinder's comment makes me wonder: Why we are spending so much time because of this problem? Why didn't LL switch to HTTP coding long ago (obviously it could be done in a week time easily)? Why trying to fix all the problems it causes, instead of fixing the root of this problem? Dan, is there a specific reason it cannot be done so easily as described? HTTP Textures (now HTTP assets) is something we are working on. Scaling issues are a major consideration so we do not have a specific date yet, although we would like to ship it by Christmas.
Dan, again with respect (and if you ever see my blog, you'll know I mean that)...
It seems to me that "scaling issues" has become the current corporate line buzz term these days. Scaling issues this. Scaling issues that. Y'know what? I don't buy scaling issues... at least not in this matter. So if I may request... what there is about changing protocol codes from UDP methodology to HTTP methodology that has anything to do with scalability? You change the code, you compile the code, you release the code... problem fixed. Unless there's something else down deep Linden Lab isn't sharing with us that affects texture transfer far more than the UDP situation. Scaling issues? I'm sorry, that just doesn't ring true. I have a feeling there are a lot of techs out here that will echo my disbelief on that one. Again, I don't know how LL is set up internally and equipment-wise... and I'm sure it's a real technical monster... but Linden Lab telling us you're hoping to ship by Christmas... 3 1/2 months away... tips the scale to the ludicrous setting. What could there possibly be in such an issue that would take any company 3 1/2 more months to correct. And forgive me for saying this... how long have we been hearing such stories from LL? "A few more months". "We're working on it." "We feel as badly about this as you do?" To be honest, it makes me wonder just what IS going on at Linden Lab that makes it impossible to transfer a simple texture at lightning speed... that makes it impossible to handle simple group chat... that makes it impossible to deliver a simple group notice to all memebers in the group. That kind of just doesn't set right, y'know? I don't mean to bust Linden Lab's chops on this, but frankly, maybe it's time for some chop busting. It seems to me (and a lot of others) that the company isn't delivering the service we're paying for... and paying through the nose. I mean, when someone pays $295+ a month to rent a piece of virtual land, they have the right to expect it to work, yes? So again, I ask... what is it in transferring a texture to your clients that has anything to do with scalability issues? I don't see that UDP to HTTP has anything to do with scalability. Or is the real issue that you folks are transferring so incredibly many concurrent textures that the existing asset server system isn't up to the task? If that is the case, just tell us. All we want is a bit of honesty. Well, that and what we're paying for. Again, not being disrepectful. Being the customer. (edit: and if it IS the asset server system... don't you think that switching from UDP to HTTP would signficantly reduce the stress on the asset servers? And to be honest, I'm not even sure HTTP is the best solution. Strikes me that the best solution overall would be proprietary code specially designed to transfer textures as fast as conceivably possible. But if as everyone believes, HTTP is superior to UDP in this case... then by all means install the HTTP now and reduce the asset server re-send issue. That alone should reduce asset server issue by a great deal. Or... is there something else that's not been discussed yet? If there is, LL might find it's user base one of its best assets in figuring out such a problem. But right now, I and others find ourselves in the unenviable position of being forced to once again stand and point the finger and say "That is just wrong." We don't like being put in that position, but we're responsible for the investments of a lot of people, you know?) Any new system we introduce needs to scale for a million users, so any time we introduce a new system that touches one of our central systems like the asset server, it needs to scale well. When HTTP assets is ready to test on the preview grid, we will invite you to test it.
Well, I understand that anything added to SL has to work for a million users (or more accurately, around 65,000 users concurrently). However, there is a difference between scalability and functionality. If you introduce a new chat system... that's interactive. Yes, that is going to involve scalability issues. But simply sending a piece of data across a line... that's not really scalability is it? Yes, I agree that LL always needs to be concerned about scalability. In this particular instance for example... will HTTP protocol stand up under massive requests? But the entire internet is based on HTTP protocol; I think that question is already answered. I would have to believe Google and Yahoo receive far more requests via HTTP than SL. The method is proven in over a decade of use.
Now, if you had told me that "we have programmed the HTTP system and it's ready to be added to the preview grid"... that would have been good news (and I would hope, considering the urgency of this issue, that preview testing would last a couple weeks instead of 3 months). But instead we hear: "When HTTP assets are ready to test on the preview grid"-- and the first question that comes to mind is "WHEN they're ready? Why aren't they ALREADY ready?" How long have people been reporting this problem and how long has LL known the cause of the problem? And a fix isn't ready yet? That's what folks are up-in-arms about. How long does Linden Lab knowingly tolerate a major, SHOWSTOPPER issue before they do something about it Dan? I know you're not to blame for this. You're one of the few Lindens with the courage and courtesy to wade in here and discuss this with us (and believe me, I do give you a BIG nod of approval for that. You're putting yourself on the line over a company issue. That's the way people should do business. : ) ). But since this is a showstopper issue and since LL has known for quite some time what the problem is and since people have been screaming about this for so very long... it really then comes down to an issue of company attitude, policy and PRIORITIZATION. It doesn't do any good to spend thousands of man hours on Windlight if the textures that Windlight highlights load at a snail's pace. Likening this to a RL situation: if the toilet bowls started overflowing, how long should the homeowner wait before fixing it or calling in the plumber? Second Life 1.20.15 (92456) Jul 18 2008 10:58:42 (Second Life Release)
You are at 233293.3, 218286.8, 23.9 in FairChang Shores located at sim2183.agni.lindenlab.com (216.82.16.188:12035) CPU: Intel Core 2 Series Processor (1998 MHz) I did a test. I turned off all rendering, save for the UI. Rendering absolutely nothing in world. FPS was in the mid eighties. Bandwidth around 40-50 kbps. No packet loss. Ping sim, arround 110 msec. I opened a 512x512 snapshot. It took 39.28 seconds to completely load. The image window was in focus the entire time. This issue is very much a concern for myself and most everyone that is trying to grow their business in SL - things are rezzing way grey, they are taking much much longer then in previous viewers, Avatars are grey, textures are SLOWER then before to display on prims and from viewing from inventory, loggin in takes way longer then prior and the crashes are more and more every day. I am considered a power user and I have spent everyday in SL for the past few years on a full time basis. Everyday I try different preference settings to combat these problems. NO LUCK....even loading scripts is the long dreadful WAIT now.
I'm lowerering priority of this bug. "Showstopper" mean that you many others are unable to login or use the world.
I reproed the case that Balpien Hammerer pointed out earlier. I uploaded a 512x512 image several times, then cleared my cache, relogged into a different region (so I don't hit the sim's cache) and timed the image download. Unfortunately, I have no data about how long these texture downloads took in the past and I know of no way to compare current download times with past download times. Ideally, of course, all the images should download in ~4 seconds. I entered a bug to investigate where the timeouts are coming from. I still see no evidence that a newer viewer - 1.20.15(92456) - is worse than an older viewer - 1.19.0(5). A specific repro case for this would be much appreciated! Something like, "Go to islandA/x/y/z, facing east, and wait for all the textures to load (or wait X minutes), then teleport to storeB/x/y/z and look at the vendor north of you, then note how much time passes before the vendor is legible. Log out, clear the cache and repeat for viewer version X. Compare the results." A couple of points Dan:
1) "Showstopper mean that you many others are unable to login or use the world" 2) I really appreciate you going to all the trouble of performing that test. Good job. (I'm sure others feel the same). 3) While I believe there may be some benefit in comparing older versions of SL to 1.20.15... isn't that really Linden Lab's job? We're not being paid for this. We're paying you folks. You folks should have a copy somewhere of ever version of SL you've ever released. So load a version of 1.13.. 1.15... 1.17... 1.18.. and test the puppy. I don't mean at all to be snide, but i'm running a group and a business. I don't have time to do Linden Lab's bug testing for it. 4) You mentioned "Ideally, of course, all the images should download in ~4 seconds". I must very much disagree and object. Ideally, textures should load in less than ONE second. Why? Because a sim full of textures (say 1000 textures... which is fairly on the low side)... loading at ONE SECOND EACH would take a total of almost 17 minutes to load the entire sim. Obviously even one second is going to be slow. But also consider: IF in addition to speeding up loading times to 1 second or less per texture, Linden Lab also installs a properly-conceived and implemented PRIORITIZATION system (which btw, was recommended by some serious pros in a recent magazine)... then textures immediately surrounding the avatar will load first. IF in addition to speedup and prioritizing textures, Linden Lab sets up a priority load on any touched object, even at 1 second apiece I doubt anyone would seriously complain. So 4 secones apiece? No. Not nearly good enough for the reality of Second Life. Why? Because if SL loads textures at 4 seconds apiece... it is going to take between one and three hours for a full sim of textures to load. That's why I encourage LL to think these things through and perceive them from a customer's standpoint. Four seconds per texture is far, far too long. 5) If Linden Lab would just FIX the problem, again... all of this would pretty much be moot. You folks know what is wrong. You know what is required to fix it. So just FIX it. (Please pass that on as a thought from a "concerned customer"... and thanks. ; ) Maybe some simple math would help in respect to textures having to refresh. The max size of the cache is too small to accomodate what is a normal texture load now. Perhaps the max cache size could be increased by a factor of 10. This doesn't help with the texture stalling which is very real. But it might help with the constant reloading of textures that eats bandwidth. ISPs are moving to cap bandwidth so for SL to survive requires more textures cached once downloaded.
(Again, I'm not a texture tech so there is a lot I don't know. But we do know quite a bit of what is wrong on SL and how to fix it. I'm sure the texture techs can fine tune these notes even more.).
That's a good point Ann... and it also applies to other areas of SL. The general rule of thumb should be: if an object hasn't changed, don't update it. That applies to textures, objects and avatars all three. The more textures that can be stored on the user's local hard drive... the faster those textures will load. On the average, a JPG texture takes 200-300kb... probably far less the way LL stores them. Obviously at that size... a 512mb card is enough to store rougly 1700 textures. However, only a small percentage of those textures are visible at any one time (due to object occlusion). Still, there is nothing wrong at all with storing those textures on the hard drive or in system RAM (if present... myself, I have 4 gigs)... and call them locally when required (which would take a split second instead of the current 20-40 seconds it takes currently). So you're right... the bigger our cache size, the better. : ) Dan, I'll run the numbers on 1.19.0.5 (1.19.1.4), probably this weekend. I do not have any 1.18 builds and I am not certain they will work with the latest server builds anyway. If you can provide me with a link to a 1.18 build I'll be happy to test it.
I perform three kinds of tests. First is a unit test to time a single texture load. That gives me one dimension of the problem, which is to observe specific latencies and or stalls. You have my observstions on that one: it appear just one packet loss stops the download until a timeout occurs to restart it. Next I run controlled multi-texture loads to look for interactions under a little dynamic load. I reported on that one: downloads do seem to perform in parallel (good news), but just one packet drop seems to stop all of them until a timeouot occurs to restart them. Finally I run a full system load test to see how a real world interaction occurs. That last test is the most difficult to assess because it can get subjective, but with careful observation I can see characteristics in 1.20.x that were not in the 1.19.x (or the 1.18.x) viewers. My observation in this one (and no, I dono;t have the specific numbers yet), is that it appears the datagram timeout appears to have been increased in 1.20 vs 1.19. Dan, can you look at the code base and see if this is so? The other observation (and easy to repro), is that 1.20 aggressively dumps textures from regions exited. In 1.19, I can leave and return quickly to a region and not suffer the excrutiating downloads that occur in 1.20. 1.19 appears much faster to me, and as I stated at the top of this comment, I will get some numbers. But, I ask that you trust me in this observation. You asked where this problem occurs and I did answer that August 19th (see above). I tested this in myriad regions, almost 100. Here's the short list (a combination of openspace SIMs, full SIMs, some islands, some mainland): Alda Laer, Aear Iant, Betwixt, Wildefleur, The Faery Crossing, Madrigal, Wildewood, ElvenGlen, ElvenVale,ElvenMoor, Oak Grove, Balance, Here (that's Torley's SIM), Onnuri. I also throw out several test attempts when I determine other problems are occuring. Asset servers borked, inter-SIM networking issues, that bizarre time dilation cycling bug (yet to be fixed) makes it quite difficult to pull a signal from all that noise. When I report something, it has been scrubbed of that noise, but it takes time. Now I have spent a huge amount of time characterizing this problem (at this point is it upward of 40 hours), so I get a bit frustrated when no movement takes place. This is a serious problem. I now have heard several professional builders finding they cannot meet their business obligations because of this problem. It is now taking them too long to do their work, and they are considering just dropping out altogether from SL. They all say that working on things used to take seconds to reolve textures. Now they have to wait a full minute (more or less) before they can continue. This is intolerable to them. And they are not tech savvy, they do not know how to navigate the jira web sites. They do talk to their tech savvy friends and colleages. And we are urging you to raise this problem to a very high priority within LL. Hi Balpien. I've been running my own tests as well, but they're of a different nature:
Measurement of the proportional loss of Second Life customers while this problem remains unfixed. LOL. Seriously, I've been watching the stats... and it's not good. The tests you're running are great Balpien. I hope Linden Lab reads your final paragraph especially, because you summed up the situation very well. But I'm going to go out on a limb here and try to figure something out based on nothing but the visible evidence. 1. Linden Lab claims to know what is causing the texture delay problem (namely, UDP instead of HTML) What is that something else? My wild guess would be that the architecture and asset servers are not designed to keep up with the texture demand that comes out of SL on a daily basis. My guess is that at this point, even if Linden Lab changed to http overnight... their hardware wouldn't stand up to the strain because they've cut too many corners (among other system management issues). Bottom line: their system isn't set up to serve their customer base. How close am I here Dan? Am I totally off base or right on the money? What I know is this: ignoring the measurements, ignoring the tests and going strictly from USER EXPERIENCE (which in my opinion is the very best guage of SL performance):
So Balpien, I am going to second your bid and take it up a notch: at this point texture loading needs to become THE priority project at Linden Lab. Because every day they fail to fix this problem is another day that several hundred people leave Second Life because of it. And BTW, to respectfully question Linden Lab's attitude toward this issue... I still question Dan why you don't believe this is a showstopper issue. What do you call an issue that costs Linden Lab customers on a daily basis.. and that negatively affects EVERY SINGLE USER on Second Life every single day? If that's not a showstopper... what IS a showstopper exactly? The entire grid crashing due to California sinking into the ocean? The U.S. government taking over Second Life and turning it over to Congress? A hurricane in San Francisco? How serious does something have to be before LL considers it showtopper status? ; )
Fact: slow texture loading (and "slow" is an understatement) on Second Life negatively impacts every customer on the grid on a daily basis and regularly causes people to leave Second Life in frustration. So how is this issue not a showstopper? Just two points, Wayfinder:
'4) You mentioned "Ideally, of course, all the images should download in ~4 seconds". I must very much disagree and object. Ideally, textures should load in less than ONE second. Why? Because a sim full of textures (say 1000 textures... which is fairly on the low side)... loading at ONE SECOND EACH would take a total of almost 17 minutes to load the entire sim.' This is presuming that only one texture loads at each time, and other textures won't even be touched until the previous is completely finished. Which isn't the case. Now if you take 20 textures loading at 4 seconds each, you get about 3 minutes to load the entire sim. Doesn't sound that bad anymore , does it? 'So you're right... the bigger our cache size, the better. : ) ' Agreed, but one of the main client memory issues currently comes from the fact, that the more hdd cache you set, the more and faster memory the client eats up. So in order to give us hyoog cache, LL needs to fix the memory hunger of the viewer Likewise, memory use needs to be considered when massively loading textures in parallel. Those need to be either effectively streamed onto the hdd Actually, you will find that, additionally to the just mentioned cache setting, the Now, if you use 500mb of cache and a 64mb texture mem setting...you top out at around 1.2-1.5GB So, I personally see one of the main priorities to also fix the client memory first, so you can actually tune it to make best use of cache and texture memory. Good points Chalice. Glad you added that here. You're completely right... texture loading, presentation, cache and memory use are all tied in together and all must be working properly. It's quite likely that even if they did increase the HD storage levels, unless the memory leak is fixed it will just go nuts. So it's all hand in hand. Just as Linden Lab has failed to fix a simple texture protocol issue, it's failed to fix the memory leak. Ideally both should be addressed simultaneously.
As for memory though, the trend today is for users of SL (a memory hog if ever there was one) to have at least 2 gigs of RAM online. With the amazingly low cost of RAM these days, 3 and 4 gigs is not unusual. I know I could easily dedicate 2 gigs of that to SL and still be able to run my email, Photoshop and my WinTV PVR application all at the same time (although I have to admit SL hogs so much in system resources the WinTV sometimes conflicts. Usually it works though). So that's some pretty high-level stuff. If people's systems can't handle all that, then the answer of course is to not run anything else while running SL. They might wish to... but if their system has limitations, they have to live with those limitations. Can't take a Volkwagen Bug on the Nascar circuit (at least, not without considerably souping it up). Still, indications are that SL can run well in one gig or less of RAM. If the textures were transferred properly and their client-side presentation worked properly, it would present no strain on the system. But as you pointed out, since the system is memory borked as well as texture borked... both definitely need to be addressed. Thanks for the reminder. I did some testing regarding this bug/issue here:
http://jira.secondlife.com/browse/VWR-8824 I am using latest RC at a moment and I have to say that it is almost totally unusable due to texture loading bug. When I log in, it loads basic structures, most persons and then suddenly almost stops loading leaving like 70-80% of character textures unloaded. Almost all persons around me are either totally or partially grey. This is with 8M adsl line. You can get textures to load one by one moving mouse over grey parts, but even then loading those takes ages per texture (15-30 secs).
Latest release version loads all textures fine, so it is broken only in release candidate series at least in my case. Second Life 1.21.4 (98167) Sep 30 2008 15:28:25 (Second Life Release Candidate) You are at 255711.1, 256654.5, 59.8 in Lusk located at sim2358.agni.lindenlab.com (216.82.17.109:13002) CPU: Intel Core 2 Series Processor (2520 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 I have noticed that toggling Palletized Textures (Advanced -> Rendering -> Features -> Palletized Textures) off or off/on/off seems to begin loading textures in areas where I am having this problem.
Second Life 1.21.4 (98167) Sep 30 2008 15:28:25 (Second Life Release Candidate) You are at 241578.0, 255874.5, 38.2 in Shiny Falls located at sim185.agni.lindenlab.com (8.4.128.61:13000) CPU: Intel Core 2 Series Processor (2393 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 This latest RC has taken a U-turn in reliability. Attempting to open the snapshot window almost always leads to a 30-60 second hang or app crash (many dumps sent to LL). It happens when the image size is over 512x512. Example: I usually snashot to my hard drive and the resolution I use is 1680 x 1000. To verify this was not a file save problem, I tried a snapshot destined for a direct upload. Hangs and crashes occured above 512x512 image sizes, PNG.
I was attempting to document how this texture loading bug damages what the world looks like upon entering a SIM I recently visited or even after having logged off then back on, but this hang/crash pretty much makes documentation impossible. Anyway to get on topic, 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. 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. I just found this issue, and wish I did before. Now the problem has escalated to GRAY for me.
I'm seeing everything gray since the beginning of the Burning Life. The only thing I've learned is that if I want a texture to rezz, I have to put my mouse pointer over it and wait. Or right clicking also helps. If I just stay put, textures just dont rezz... even if they are in cache. This happens at my home! I have to rub my mouse all over the ladies in order to actually see them! haha I want my vision back! Help me obi-one! I don't think it's a network problem, since this happens with everything in cache, anyway, but here it goes: traceroute to data.agni.lindenlab.com (64.154.223.192), 30 hops max, 40 byte packets Did a lot of tests... It seems a bit random. The only conclusions I got:
-clearing cache doesn't help, and having the textures in cache doesn't help either. -starting from a fresh install helps sometimes, but then I can go back to the old install and it works as well. -not video card, not internet link, not windows/linux. All tests using the LOW graphics settings (64 meters distance): Luxor (155, 80, 135) The Central (114, 132, 24) (cont)
royer4.jpg (Windows) - Walked a little and waited another 4 minutes, and nothing. The viewer is barelly using my internet link. (cont)
royer8.jpg (Linux64) - Deleted the .secondlife directory (configs and cache), logged in and it worked fine. I changed all my configs and cleared cache and rellogged. Working good. Most textures loaded up within 10 seconds.. the posters and boards at the far end walls took up to 1 min to load. By the end of the day I will probably have to start fresh again... Hope this helps out! If you need ANY more information let me know! This is the look one minute after TPing into a region. Almost all textures are not loaded. Network bandwith ranges fro 48Kb to 120Kb (that K bits)..... This is on a 7000Kb connection.
This is a little over 3 minutes after the 60 sec photo was taken. At this point almost all of the textures are load.
I have found that this problem has reached a personal extreme. I do know people not experiencing this problem, and wonder if it specific or more pronounced on the Mac platform. I find that 1.21.6 is virtually unusable. However if I right click select objects, the textures will load much more quickly. Nonetheless, this was not necessary in even the last release version.
Object occlusion? This doesn't seem to exist, since I consistently see the interior of a building before I ever see the walls. If this problem is more specific to Mac (I doubt exclusive) why hasn't a truly native version of the viewer been developed for OSX? This would almost certainly resolve a lot of headaches for Mac users. PS. I tried to downgrade my viewer, but am being required to upgrade again. I don't appreciate this.
Abhishekam Jawetz, you're not the lucky one. This happens with Linux and Windows also.
I just tried the 1.19.0.5 again (Linux), and it doesn't help much. You might want to search for Cool SL Viewer, I think they have a Mac version, and they have working older versions that you could try and let us know if they help. Having the same issue on a Macbook. It just seems the viewer isn't even trying to load the textures.
Downloaded Cool SL Viewer 1.20.17 (http://hyangreflections.blogspot.com/ Hugh, today it seems to be working for me.
Please go back to the original viewer and check if it still has problems. Are you sure the Cool SL Viewer you mentioned solved it, or was it just a coincidence or a momentary thing? series 1 of 2 demonstrating texture loading problem... annotated images...
Series 2 or 2 demonstrating the texture loading problem.
My sense of this problem is that there is a z-ordering texture loading bug introduced post 1.19. 1.19 tends to look better because textures closest to the avi (or closest to the camera) are chosen first for download. Land textures are also given priority. This is no longer the case with 1.21, so the wronf textures are being selected. When the asset server are overloaded, which is most of the time, 1.19 does a much better job delivering a better user experience. Under heavy load 1.21 fails to show land. I often find myself entering a SIM completely full of water only to find land slowly appearing a minute later. Finally, the tiniest packet loss stops texture loads in 1.21. I am forced to 'paint' the view by hovering the mouse over incompletely loaded textures. Another observation; the problem is directly tied to the state of the asset servers. If they are responsive (a rare thing nowadays), they tend to mask the deficiencies of the 1.20 and 1.21 viewers. BTW 1.121.6 is better that the 1.21.5 RC. That one crashes ofrten when taking snapshots. 1.21.6 vs. 1.19.1.4 There is not much more to say about this than a comment I got from several people trying to buy items from my store, complaining they could not see my products. I tend to use multitecture vendors because they save on prim space, but given this problem, I'll have to abandon them and go back to single prim vendors. Worse, the selling price does not display quickly and so I am force to go back to ugly hover text. In some SIMs, use of hover text is prohibited (for may good reasons), so I'm stuck. VWR-8503 has got to be a contributor to this problem.
Whatever became of the project to move textures to flow over HTTP instead of the current comical UDP dance? If your web browser loaded images this slow, nobody would use it.... Textures over HTTP is in the works.
From what I've seen in the client code, during the 1.21 development there were quite a few changes to the backend, as well as the viewer side to prepare for a change to HTTP in more than just textures. Inventory list requests, changes to the LL streaming data format, script uploads (which caused em to break for a while in the trunk ^^)....gears are turning. This bug is a showstopper for me. I am currently having to use onrez to do anything inworld and it is not a good solution. But textures take so long to rez that anything on a timer never rezzes, and I am talking from 2 minutes at best for land textures to over an hour before I gave up and some never rezzed on buildings. Anything with trees is a nightmare, fog is opaque, I cannot work on my builds, I cannot shop, I cannot walk a good portion of the time from the horrifying lag that gets worse each hour until I must relog after a few hours of time inworld. This problem is since I was required to download the latest release viewer. Performance has gotten progressively worse at the last couple of "fixes", but now the viewer is functionally unusable for me.
I am a paid account if that makes any difference at all. Unfortunately I cannot paste my information since I do not know how to access it from this viewer. The SL viewer is the one I have used for the past 2 years and the only one I am familiar with. I am truly puzzled as to why a bug that has effectively stopped me from being able to function inworld, which I am getting anecdotal reports from ISC chat is affecting MANY users, and which has over 50 votes is not considered a showstopper? I can do NOTHING in world with this viewer except chat, and the ongoing issues with group chat even make that problematic. Is there any intent to fix this? Please, I am really stuck here.
I just went back and reviewed comments...and looked at other JIRAs. I, like many other users, am at a disadvantage in here. I cannot address what I believe are causes, or get into debates about what fixes should be used. I simply have to report my problems. I am reading about texture loading taking 20-30sec and faces being gray. Frankly, I have been living with all that for several releases. What I am talking about now is being unable to build, I can tell you I stood in a house I had just rezzed with the wall filling my whole screen and it took 1 minute to go from gray to smear, 3 min to go from smear to blurry, and did not focus until I moved my camera back two minutes after that. I cannot walk on my forested properties because the gray prims block my vision. I cannot build anything because my veiwer becomes unresponsive when I try to open the textures window, freezing for over a minute each time. I have been living with constant freezes of 30 sec to 1 minute, not being able to fly or walk any distance without viewer jumping. This went from what you describe as critical to a showstopper for me with this last update. I downloaded 1.19, and as was earlier described am amazed at the dramatic difference on performance, but unfortunately cannot pay my tier or shop....and my current 3rd party viewer is not good for building. I miss the LL viewer I have used for the past 2 years. PLEASE fix this or at least let us go back to the awful previous one that I actually appreciate now. I totally agree. especially to the sentence "IF A USER CLICKS ON AN OBJECT (such a a vendor), LOAD THAT OBJECT'S TEXTURES NOW. ". I remember that this feature existed when I joined SL early last year, but it was removed by no reason.
Royer,
It's not momentarily. I've been going back and forth between Cool SL Viewer 1.20.17 and SL viewer 1.21.6. And I always have the problem with 1.21.6 and never with 1.20.17. I was contacted by Dan Linden. He asked to see my SecondLife.log after a session where the textures didn't load. I went to a place that I know this happens a lot (Sanctuary Rock, and it happens to others too) and waited some time but most avatars stayed grey and some objects too. I logged out and logged back in the same location with 1.20.7. Most of the textures loaded almost immediately. Thanks, Hugh. I'm going to try that exact version in Linux.
I think the "official" viewer version 1.20.17 works okay too. So you don't need to use The Cool Viewer.
The Cool Viewer's 1.21.6 has the same problem, at least for me. As I read Hugh's comment, I was standing by 2 multi vendors that where displaying GRAY for me.
Downloaded the same exact version 1.20.17, the one suggested by Cool SL Viewer: 1_20_17_98669, reloged and vuala. I can see the textures... not only they are not gray, but they rezz in time for the vendors slideshow to actually work for me. I'm going to keep on using this version and observe. 1.20.17 is still working good!
I've just tried it for a while in Windows and it works as great! MUCH better the the latest Release and RCs.... For all Windows users who need a quick waiting solution to work again normally until the bug is resolved, I tested the simple solution (too seems :o) to reinstall the previous Second_Life_1-20-17-98669- version witch works normally and does not seem be affected by this textur picker delay bug.
Steps to reinstall this working version, here on in the last comment at the bottom : https://jira.secondlife.com/browse/VWR-9976 Yesterday, I received multiple pictures (15-20 I think). 2 or 3 loaded in a "human" period of time (= 5 minutes, LOL). The remaining pictures needed a viewer restart to be visible.
I wish it were so that 1.20.17 works well. It does not. I still end up with long downloads on it.
Versions 1.20.17 and 1.21.6 are not noticeably different when performing initial texture loads; that is, from a cleared cache, both versions seem to finish loading textures at about the same time (slowly). There is an ordering difference but I think that has more to do with a fix introduced in 1.21.6 which fixes the rendering of sculpties. Somewhere in the 1.20 releases a bug was introduced in which an object's sculpty geometry file would not be applied until the object is edited. There is a difference, however, post initial cache loading. When TPing between SIMs (and I suspect when moving through the same SIM but being exposed to a different texture set), version 1.21.6 just seems to never fully render all textures. 1.20.17 does. This becomes evident on the TP to a new SIM as well as the TP back to the original SIM. If this happens to me in 1.21.6 I relog in 1.18.3 and every image loads instantly, my download speed is around 120kb/s. In the slow loading 1.21.6 the download speed is around 10kb/s.
I'm having major problems with textures loading very slowly/not at all. Some high density sims are still 50% gray after 30mins. Other low density sims often still have fuzzy textures (within 10m of me/the camera) after the same amount of time. At this instance the floor I'm standing on still hasn't rendered fully in over 45 minutes. Clearing the cache makes little difference.
My PC should be able to eat textures for breakfast as it's pretty much a 'last years model' top-spec games monster. I've got more than enough hard disk space on my 2x RAID 0 Velociraptor drives and my DSL link is 16Mbps / 1.2Mbps. The nearest thing to a bottleneck on my PC is the processor and that is far from pedestrian. I'd like to see the cache remember objects/textures from my last 3 or 4 sims (maybe a selector in preferences as to how many) and my HOME sim should always be cached. It might also be handy to cache a percentage of the most common textures gridwide. Something needs to be done to reduce the load of the asset servers and if keeping a bigger proportion of data in caches will acheive this then I'm very happy to give up the disk space for it. Second Life 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release) CPU: AMD (Unknown model) (3013 MHz) - (X2-6000) I have 1.20 and 1.21 installed on the same PC in different folder. 1.20 loads textures much faster then 1.21. Notably, 1.20 uses much more of my bandwidth to load textures, rather then dropping sharply when objects are loaded but still grey.
Same thing here. ages for textures to load.
The extra latency of the texture loading is too annoying, and i''ve reinstalled the 1.20 viewer for the moment. DSL broadband, wired, 8Mbps / 512kbps Second Life 1.20.17 (98669) Oct 5 2008 10:25:42 (Second Life Release) CPU: Intel Core 2 Series Processor (2671 MHz) We are unable to find a repro for this bug (and I'm on DSL, not the LL network). I'm speaking specifically about 1.21.x not loading textures while 1.20.x does. If any of you are able to make this bug repro reliably and are available to test with me during the day (10AM to 6PM PDT), please send an IM to Dan Linden.
I reported earlier seeing the long stalls and tonight I tried and results were similar except that the asset servers were being better behaved so the permanent stall problem was not evident. In tried out various attempts at characterization I came across a rather peculiar behavior of 1.21.6; it dumps textures based on time. In trying to capture a good log entry for Dan, I started TPing back and forth between two points in different SIMs. The results were as I havereported earlier in this thread. Then, I cammed in to a vendor to see if I could create a more controlled texture loading situation. This vendor has 6 items in it. It has three panes, two small ones for previous and next previews plus a large pane for the item to be sold. This is a common configuration which permits the texture about to be seen to render ahead of time.
As I scrolled through the vendor's 6 items, I could see grey squares and in 10-15 seconds, a texture would finally. load. Then, when I kept clicking on the next item I was surprised to find a previous one I have seen a short time ago reappear as a grey pane. If I routated through the 6 items quickly, they would resolve OK. If I scrolled sedately, invariably, already seen textures would appear grey as they were being reloaded. With the texture console active, I could see the system trimming the cache agressively. If I wait for more than 10 seconds, I can guarantee a few of the 6 textures will have to be reloaded. This is why so many people complain that vendors are not working. This 1.21.6 viewer has a terrible characteristic in that the aggressive trimming (reported months ago) causes continual traffic to the asset servers when a person is in a texture rich environment. The trimming guarantees just about everyone logged in will cause asset server transactions. That then means the asset servers are guaranteed to melt down when the number of logged in avatars rises to a fixed value. An avie just sitting sit in one spot will gnerate asset server requests. It takes a slow asset server to cause the permaent incomplete texture problem, so I suggest people try this when the system load is high. I have not checked the earlier versions to see at what point this agrerssive cache trimming was introduced, and I don't plan to do much more on this bug. Once I send my logs and snapshots of the texture console to Dan, I'll be done. The situation is I am canceling my openspace SIM in January when the extortive price rises arrive. That leaves me with a 4K parcel, and with the projected loss of many OS SIMs where I current reside, sailing will be dead, flying vehicles will be dead. Between these serious bugs and the forthcoming destruction of what once was beautiful unified lands, I just don't have the desire to continue in this world with anything more than a basic account. Was fun while it lasted. I consistently have the texture stalling/not loading problem at M&M Creations (http://slurl.com/secondlife/DoubleMM/179/77/77
). I am there now (6:27 AM SLT) and about half of the textures have loaded and texture loading seems stalled.
I seem the notice the texture loading problem in areas with a lot of different textures or a lot of residents. Sometimes if I zoom in on a texture it will load. Second Life 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release) You are at 147379.0, 246861.0, 76.7 in DoubleMM located at sim7829.agni.lindenlab.com (8.10.148.68:13002) CPU: Intel Core 2 Series Processor (2393 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 This is M&M Creations (http://slurl.com/secondlife/DoubleMM/179/77/77
) after about 2 minutes I cleared my cache and went back to M&M Creations at 8:52 AM SLT. By 9:44 AM SLT, only about half to 2/3 of the textures had loaded.
Zak Escher's exemple is 100% reproducible! sl_mm.png attached. Using either 1.20.17 or the newest RC viewer, same thing. Textures GRAY and it isn't even trying to download them... bandwidth usage low, no packets dropped...
I've sent an email to Dan Linden with my log file also. Zak, great to have a solid repro. When you next go there, turn on the texture console and then see if during the entire grey period you see continual downloads. I suspect that the agressive time based texture cache trimming ends up throwing textures out faster than they can be downloaded. So, places that are texture rich and use larger textures (meaning longer downloads) will suffer the most from this unfortunate behavior of the viewer. SImilarly, as the load on the asset servers build, which slows down texture downloading, the viewers then place even more load on them since it forces more downloads.
I'm not very familiar with the texture console, but it constantly showed textures. I'm assuming that meant the client was trying to download them. In other sims without many textures, the texture console would eventually clear.
Thanks Zak. I think we are getting to the root cause now. Cache scrubbing was introduced somewhere along the 1.20 RCs. I do not have my notes handy to identify the exact release, but I recall this scrubbing got added to mitigate the sever memory leaks, basically a hack to get around the memory leaks. The problem with cache scrubbing is that it is sensitive to cache loading delays. A strong positive feeback loop can ensure when the cache loading time approaches or exceeds the scrubbing time constant. This approach makes client viewers perform a distributed denial of service attack on the asset servers; the slowlslower the asset servers get, the higher request rate they receive by the attacking client viewers, which in turn increases the overload.
Anyway the above is a theory, and it's easy enough to test. I'll do my final set of texture console snapshots in various texture rich SIMs to see if this theory holds up. I recommends others try the same thing on different SIMs, full SIMs and openspace SIMs. First, a "Thank You!" to the users who have helped test these issues over the last few weeks. It's much appreciated.
Here's an update as we continue to investigate this. There's likely 3 or more different bugs here: 2) The viewer mis-detects the video card's memory. See the bottom half of attached texture_stalls_2008-10-29.png. That number should not be negative. If you're seeing this issue, please mention your About Second Life info along with what the video card memory was set to (find that in Preferences > Graphics > Check "Custom" > Hardware Options button > Texture Memory), and the actual memory your video card has. (Zak Escher reports that setting the Video card memory to the correct value improved texture loading. Your mileage may vary) 3) Some textures loaded from the viewer cache get stuck in the CRE (create) state. See the top of attached texture_stalls_2008-10-29.png. This one almost seems like an interaction between the 1.21 viewer and a particular router/network connection. If you're seeing this issue, please mention your About Second Life info along with your Router / Modem make and model and your ISP. If you see a texture loading stall in 1.21 that is not one of the above, please turn on the Advanced menu (ctrl-alt-shift-d) then turn on the Texture Console (ctrl-shift-3), and take a snapshot to disk, include the UI, and PNG format is preferable. (Blur out your $L balance if you're concerned about that sort of thing.) Attach the snapshot to this pjira issue. Please mention the name of the snapshot in your comment so we know which image to look at. I just saw your comment, Balpien. Any data to confirm that theory would be appreciated. I'll poke people tomorrow and ask about viewer cache scrubbing introduced in the 1.20 RC's.
Dan,
I sent you a log file that represents me hanging out in "The Faery Crossing", a full SIM. This is in my store, so there are textures everywhere, this being a market. I remained stationary and just waited for about 30 minutes. During that entire time the texture console shows a continual download. There is a download burst at the beginning followed by a continual never ending download as the scrubbing forces cache replenishment. Zak confirmed this behavior. I would be good to see other confirmations. Imagine now, 50,000 people logged in, all forcing continual downloads. What a thought. It is at this point that I wish to suggest that the "overuse" of resources in SL, was a distributed denial of service attack brought on by faulty SL viewer code. I think that any observations and decisions made about the system overloads and SIMs in the last few months (well, for as long as the bug existed in the 1.20 viewers) are invalid because of this bug. The good news is this can be fixed! Reproducing this seems fairly easy. Just hang out in a texture rich place. You need sufficient textures so that the ones in your view will get flushed. This then forces the continuous download loop. Best, Dan,
Just to be certain this is not a specific SIM problem, I went to another full SIM, Farhaven, and stayed in one spot and had a nice two hour voice chat with another person. During that chat I left the texture console open and observed periodic downloading of textures throughout the entire two hour stay. Several dozen textures would get downloaded then a pause lasting a few seconds to 15 seconds, then another burst of downloads. The other person also had the texture console open and observed continual downloads during the entire two hour interval This is ill behavior for the SL viewer. I'm convinced this causes a DDOS attack on the servers with the active population size. So, on item #1, I ask other people to test this. It is important to get general confirmation. On item #2, yes, the VRAM size detection logic is broken. Mine was defaulting to 1580MB. I lowered it to 256MB, though I am not noticing any difference (i'll test that a bit more). On item #3, I recall seeing a CRE event once in the past few months, so the continuous run of them, as depicted in the photo you posted, does not happen to me (nice to have small blessings). I think it's long past time to go to a squid-style cache for textures.
Don't put textures in the main VFS cache at all. Put them in a 3- or 4- level deep directory tree like this: cache/textures/01/23/45/67/012345-6789-....j2p If UUIDs aren't distributed well enough, use the MD5 hash of the UUID for the directory path: cache/textures/4f/ac/02/36/012345-6789-...j2p That will give a maximum of 256 entries at any directory level. Put the header information that would be in the VFS file in the cache file itself. To prepare for HTTP texture downloads that can even be stored as an HTTP header, just like squid. And have a separate thread or even a separate cacheserver process handling opening and loading these textures. Bravo, Wayfinder.
I see all ground textures as grey, all the time, plus the other building textures, everywhere, on 60 sims I go to all the time, always, since the new patches went in. I don't even blink over something like that anymore or try to protest. It's amazing, really, that I buy land, wait on customers, and even build things while in a sea of grey soup lol. I'd like an explanation from the Lindens as to why it took 90 days to admit Wayfinder was right, and why he was greeted immediately with a stall and obfuscation excercise telling him to go examine his tracer route. I got exactly the same bull when calling up the Concierge hotline when I put in the latest viewer and found that I couldn't chat, move, or see. Clearly something was dramatically difference if one day I could at least chat on time and move and see some colours, and the next day, with the same computer, same ISP, same everything but the viewer, I can't function. I'm told then to go look at my tracer route. I do. It shows problems in Dallas. Houston, we have a problem. I've just checked my Hardware Options in Preferences and my 'Texture Memory' was set at 2048MB.
I've now reduced it to 512MB to correspond to my ATI Radeon x1950xtx graphics card and now whilst some textures still take an age to load, at least all the textures actually get there in the end. Most probably a subject for another thread but what annoys me more than anything is that far too often, the textures I really want loading first seem to be the last to finally get into focus (ie the ones immediately in front of me). Dael: Perhaps VWR-9509 is reporting the same effect you're seeing
Any estimate when a fix will be released? If so, when?
Wow, seems we've wandered really far down the rabbit hole on this one, considering it just started with "slow textures".
So, in summary, we've got a texture loading bottleneck, misdetection of video card memory, and rapid flushing of the cache requiring textures to be redownloaded from the asset server, which causes avatars to hit the asset server much more than they should, slowing down the asset server and causing even more requests, descending into a loop that causes a DDOS attack on the asset servers, causing massive instability, and rendering all tests of sim load on all regions unreliable (and removing justification for price hikes on Openspaces, since the load on the OS sims is due to an internal error, and not overuse). What we have here is a pile of bugs that have come together, in a chain reaction, to ultimately cause massive problems and actually effect the pricing policy decisions of LL. Wow. Excellent detective work, guys. Combined, this tree of bugs is probably the biggest issue in SL, and it looks like the ball's rolling. Thanks bunches to all of you. :3 I'm a litlle late to this particular party..."texture scrubbing...got added to mitigate the sever[e] memory leaks"?
So somebody decided to turn a viewer code quality problem into a grid-wide resource demand explosion? And they were sure that driving the texture subsystem harder wouldn't make it leak more? I'm speechless. Balpien, I'm not yet able to find a reference to increased cache scrubbing in 1.21 or a 1.20 RC viewer. Do you recall where you read it? Blog or mailing list or release notes or somewhere else?
Hello Dan,
I've never received a Linden response to my questions about cache scrubbing. It is empirical observation. I mentioned seeing this behavior about two and one half (2.5) months ago in this JIRA and in related ones, somewhere around Second_Life_1-20-11-90229_ReleaseCandidate_Setup.exe. Back then we were being told the texture problem was our fault, something about heavy packet losses or long network latencies. Several of us demonstrated that was not the case. Now, I have to say it is extremely easy to reproduce this. Whenever I go inworld I check the texture console (menu Advanced/Texture Console) and observe for hours watching the same textures load over and over again. Now, if you are in a texture thin area, the loading loop does not exhibit itself. I also have my friends and acquaintences do the same thing and they too see the continual reloads. Zak Esher confirmed ths behavior two days ago (see his thread above). BTW, the release notes rarely describe everything that's been changed. Could this bug go further back than 1.20.11? Perhaps, but I am not inclined to test further given the rude pricing treatment I am about to receive soon. In any case, it is clear to me we have a mega-critical bug here. Let's get it fixed please. Also, this bug should be marked a showstopper. A self inflicted DDOS is not good for anyone. Thank goodness for all these comments. I thought my computor was experiencing serious problems - worrying since it's still new. Yes, it is a major problem. I have a top of the range NVIDIA graphics card with it's own 1G of RAM plus 4Gs of RAM on my computer. It's a relief to know that the problem lies with the viewer. Having said that however, I do agree that the slooooooooooow loading is a real problem, and spoils one's enjoyment of SL.
I'm also inclined to agree with the 'showstopper' rating. Since my heart almost stopped when I thought for a while my new computer was about to die.  It sure is a showstopper. There is no telling how many people decided to leave because of these issues. And how many new people checking out SL first time have been turned down by finding a fuzzy textured world. And told others about it. It's not alone our daily experience, it is the reputation of SL that is damaged here.
I've been with SL since 1.12 (I think or close to that number) and this has always been like this..its almost like this is the "expected" way of way things are done here. I like the idea of being able to put on different tattoos at a moments notice. I takes at least 30 seconds or more for the tattoo to load. my upper body goes very blurry, than some blurry, than a little blurry then body parts get visible then it takes about 10 seconds on average for the tattoo to be completely visible...add a shirt (well I cant go around naked everywhere) and not only does the shirt have to load (another 30 seconds at least) the tattoo texture has to load again...so about 45 seconds to a minute for both to be properly rezzed. Add pants and its a crap shoot if the shirt and tattoo have to reload again but thats a rarity since I am 85% of the time in prim skirts and for some odd reason its very rare when I put one on that the shirt and tattoo have to re-rez..
I have the hippo texture viewer...thats slow death..rezz it and wait several minutes before its usable changing pages is slow too takes about a minute before you see all 16 images and they are thumbnail size. On my sandbox sim of leelight I have my machine and three other games available in SL, they take about 45 seconds to a minute for all the games and my aquarium are totally visible when I TP home. I have a led digital clock I got as a freebie and built upon it basically changing about 80% of the script adding textures and two prims to show seconds. lately every minute it has to reload the textures because the textures time out on a sim too quickly? I am a very accommodating person with this type of technology since I am an A+ certified computer technician and programmer in several languages but C and its derivatives isn't one I know enough to make a educated guess on. I'm on everyday sometimes many hours at a time I know what works and what doesn't being on as long as I have been on SL. I choose the sims I live on very carefully knowing what is good and what is borderline to not worth living or selling on. It doesnt matter what sim your on its the same thing with textures...slow to load...I guess I've have gotten used to this about the game. I like the changes which have made the SL life better but I wish someone would take the chance on fixing code in the viewer that is old outdated and useless and change it to current standards. I got out of programming for the most part since most coders are very reluctant to change code that is current in a system just add to it. its works for a while, but it eventually catches up to you in slow performance and other manifestations. We have a beta grid, use it take chances, be creative, try something new and original. I don't know the LL system but there has to be an internal grid system of a few sims, this would be a great place to take chances and see what happens. What I've heard far too often is your "prettying it up" and not working on core problems as much as you should. I shall get off my soap box, heres to a better SL today. tomorrow and the future. P.S. Dan, workingonit, Maurice or any other linden is welcome to my sandbox at any time to see what I mean its Leelight 110,48,467 if you want to see the tattoos rezzing I don't mind. CPU: Dual PowerPC 970 (1800 MHz)
Memory: 4096 MB OS Version: Darwin 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh Graphics Card Vendor: NVIDIA Corporation Graphics Card: NVIDIA GeForce FX 5200 Ultra OpenGL Engine OpenGL Version: 1.5 NVIDIA-1.4.18 I have the same problem here. But i've got what you can call the most crappy videocard (64mb) so I was blaming it on my card for a long time, eventho I remember performances have been way better in the past. Untill I lately double logged in with 1.18 (Bleeding Edge, as this is my only way to have an alt at the same time in-world), and noticed the prefs were still on full (512) drawdistance. But textures and avatars were loaded immedeatly.. avatars and textures that were still not loaded on 1.21 (lowest graphics settings) after 30 minutes... Now I see this JIRA and its comments.. so I just checked the texture console what happens if i'm in the air (2k) wih nothing around me, just standing on a prim.. i dont move and dont move my cam.. 1.21 just keeps on loading and scrubbing, on an on, for the textures i 'wear'. As soon the list is empty, it raises up with 20+ tasks, and processing them with codes DEC / INI and sometimes CRE. It stops as soon I zoom fully in on the plywood stand, so no other texture is visible, and start again on zooming out. I quit 1.21 and logged back on 1.18, same place, same trick.. but now textures are loading only JUST ONCE.. nothing happens in texture console, except when i move or turn a little.. but also just a second and its not loading or scrubbing anything contantly. I have tried (OSX only) 1.21.6.99587, 1.21.5 (98701) Release Cand. and 1.20.9.87416 (Cool Viewer).. in all 3 the same thing occured on Agni and Aditi. I know I'm supposed to attach all kinds of tech specs and details and so on and I will when these errors occur again. So consider this just validation or something based on one experience, which is that yes, slow! Also, not sure if it's related, but when I select a prim, select the texture tab, and then click the texture thumbnail it freezes me for about 45 seconds....not slow loading, just freezes.
I've noticed the change too but haven't timed or attempted to isolate it from the increased ping time and higher packet loss that has been appearing lately.
I'm curious though as to why anything is ever deleted from the cache. When criticized for it's slow loading times in comparison with actual "games" the excuse frequently given is that all the game content resides on local storage while SL has to pull it down from remote servers. But once it's downloaded why delete it? If installed games can manage several DVDs worth of data why can't the SL client? Just did a quick check of some other social MMOs on a moderately used PC here. Active Worlds has 1.85 GB of stored files and There.com has about 2.4 GB of cache. These 'games' are far from completely explored and the cache sizes will probably increase with further use. I have uninstalled The Sims Online so can't give an exact number but remember it growing to 4GB or so before it was obvious that most textures were cached. I'm sure I have a different computer, system and internet connection from the original poster and yet I share the same experience. So that rules that out. I was at a wedding 11/1 for several hours. Some of the clothing worn by several avatars was identical, yet some displayed half-loaded textures, when an adjacent avatar wearing the same article of clothing with the same texture was completely rezzed, after two hours! And I wasn't the only one at the wedding complaining about it, either. Sure made for a lousy wedding photo album.
In a low-lag sim that I own about 2/3 of, showing no time dilation, packet loss or fps trouble, where I'm getting 60 fps, on land that is very much under-utilized, in a skybox, after having spun around until the texture console says everything is loaded...
it's taking about sixty seconds to load a 512x512 texture from my inventory. I've attached a screenshot as a file attachment (textureconsole.png) rather than a screenshot because there is no paste button in the attach screenshot dialog Second Life 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release) I have to agree - texture loading is now a complete farce. We live on a full sim - just 2 avatars - prim count no where near the limit. Recently - and yes you could point to the recent upgrade - it's a nightmare. our OS are even fairing better - oops should not have said that otherwise the tiers for fulls will be on the arrack list next.
Not sure if this is in a seperate defect or not, but it does seem related.
Recently when I go to change a texture on an object my SL client complete freezes for 10-30 seconds before the window opens to select a texture. This occurs on all 3 of my home systems and the two machines I have tried at work. I'll include the specs for the current machine I am using at work at the moment. Second Life 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release) Note: CPU is actually an AMD Athlon 64 X2 dual Core 5400+ 2.81Ghz Actually, I have seen this issue (or ones very much like it) for a LONG LONG LONG time.. like back to pre-1.10 viewers. I spend a LOT of time in one place and always wondered why the viewer would constantly redownload the same textures over and over again, especially after relogging. Surely, they are not overfilling the cache.
I have also noticed a LOT of "texture thrashing" at times, especially noted with those 2-character-per-cell XyText signs. I sat one day and watched bits and pieces of one of those signs a little ways away from me constantly blur and refocus over and over again. Is one reason why I never used that technique in my version of them (too many textures). My suspicion is that there is a serious (and very old) bug in the local caching subsystem which is not properly maintaining asset tagging in the cache, causing it to prematurely expire assets (and/or expiring ones which are still in the PVS), forcing them to be redownloaded over and over again. It's only with the new viewer that the effects of the bug have been exacerbated to the point where it is appearing with a vengeance. Maggie Darwin - 30/Oct/08 03:42 PM
>Dael: Perhaps VWR-9509 is reporting the same effect you're seeing It's not quite how I would describe it but yes I think we're on the same page here. Ric Mollor - 02/Nov/08 02:56 PM I agree with a lot you are saying here. I can think of a few situations where holding on to some items would not be useful but on the whole, more stuff saved to cache means less stuff to re-download later. Sure there's going to always be a percentage of objects/textures that will change between visits but it seems silly to discard regularly used items. Amazing! For the first time I went into Dedric Mauriac's gadget shop and all textures were loaded instantly!
This shop has A LOT of textures... I've NEVER seen this as good. For testing I used the latest Windows RC and SLim viewers. Dan, Lindes, please make a note of the time and see if you can make any sense of this! Check the logs and stats from the servers. There must be a clue (another). 10:10PM PST. And I've complained so many times do Dedric.... he must have thought I was mad. Today, for the first time, I've experienced his shop as he sees it. Woodbridge/79/80/25 PS: his shop was NOT in cache, and it rezzed much faster.. not faster.. IMEDIATLY. a lot faster then my own home. PS2: I had to try in Linux also.. so I rebooted with SL 1.20.17 and the results were also great. THIS is Second Life (R) !!! I experienced the issue where the vram was being incorrectly detected. I have 768mb, SL was detecting 2048mb.
Second Life 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release) CPU: AMD (Athlon 64 X2 5000+) (2611 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 After manually setting the texture memory, i can confirm that textures appear to be loading as normal. I am using the latest nVidia drivers and i'm also experiencing the clothing textures bug related to palletized rendering. How do you manually set the texture memory?
look for the Hardware Options button on the graphics tab of the preferences window
 I was standing next to my sculpted trees. After half an hour they still looked distorted (see picture Sculpted trees before restart.jpg). After a restart they looked fine (Sculpted trees after restart.jpg).
This is just ONE of MANY examples of textures not showing up properly on my Sim! Joshua do you mean a region restart or a viewer restart?
A viewer restart, sorry
 . This has been a challenging response to write. I hoped that through careful testing I could narrow the unknowns and develop some insights into the problem. Unfortunately I only expanded the unknown. Sharing this discussion might help someone else narrow the problem.
I tried to create a simple, repeatable test to confirm the reports of textures being dumped, only to be reloaded again. Instead the test only raised new, fuzzier questions. One of the tests performed: Expected results (based on the earlier reports): after each teleport the identical scenes would take multiple seconds to redraw, as each scene re-loads from the server. Actual results: after each teleport the identical scenes were re-drawn instantly. The Texture Console did not report any textures re-loading from the server (status of SIM or NET) or re-decoding from the local texture cache (status of DEC). There were no rows appearing in the Texture Console at all. This highly controlled test is at odds with my own in-world experiences. In a less controlled environment, I found that a teleport between two sims with highly detailed objects would cause identical objects to be slowly textured. For example, an identical texture appearing in both busy scenes was progressively decoded from my local texture cache; it was not retained in memory after teleporting from the previous sim. A second baffling result occurred during this test. With no changes to the environment, and no other objects or avatars within the draw instance, the Texture Console would periodically display from one to five new textures being downloaded. I tried to correlate these new textures with the arrival of avatars in the sim (600+ meters below me). A friend teleported in using an avatar I had never seen, but there were no new textures. I was unable to identify where the new textures were coming from (daylight changes?). The new textures may not be the source of any problems; they may simply be a misunderstanding on my part. An earlier test, using the same sparse environment as above, involved a simple script to cycle through each of the 17 colorful 512x512 images from the "Library", "Photo Album" folder. On average each texture took 55 seconds to load its full level of detail. Once the 17 images were in my texture cache changing images required two to four seconds of progressive decoding. The Texture Console clearly showed the images were only being decoded (DEC), not being downloaded. In a busier environment the slow decoding of the images (all occurring on my local computer) could be mistaken for slow server downloads. I'm disappointed that I was unable to narrow the focus of this issue. I hope sharing these comments can help spur some insight into the problem, without creating any new distractions for the developers that are actively investigating this issue. Sheet, I am not surprised by youor finding. Go read my notes about texture thin versus texture rich environments. Also there are number of other factors involved haivng to do with stalls caused by single packet drops. It's all documented in this bug report.
Next time try raising the number of textures to a larger number, like 200. The problem is senstive to how much of the viewer cache is occupied. I linked
If this fixes your texture loading issue, don't comment here! Go comment in Well I tried the fix described by Dan Linden, and downloaded 1.21.6 again to give it a try... found that my texture memory was set to 64. Reset to 128 with no improvement, reset to 512 and had much slower downloads and began to crash frequently.
So I have once again uninstalled 1.21.6, reinstalled 1.20.17 and am putting up with having to relog 4-5 times a night due to memory leaks - but can actually build something and see textures. Lag is becoming worse daily, crashes more frequent, and performance seems to be degrading....I am deeply discouraged. Since I have invested so much here at this time, and have several events pending I cannot just walk away....yet. But since the point of SL is recreation and relaxation, then coming on just to spend each evening in deepening frustration is silly. Is there any hope of this problem actually being resolved by LL? Or is it just more runaround and "adjust this on your system" for months? It isn't my system, it is YOURS. Please fix YOURS. Thank you I did much the same, reverted to 1.20.17 but found out that it is now crashing more often than in the past. Strange!
So i uninstalled and began using 1.21.6 again.... and dealing with the frustrations again. No matter if i set draw distance to 128 (default), 64, or 512, the textures of near objects/avatars may take ages to appear !! And by the way, SL detects my video card memory right (512). Interaction with environment, building and even discussing with people about what we see is usually impossible unless we wait for minutes, and often it takes several minutes before the near people / objects is visible. The only improvement i can see is that SL uses now much less RAM than before, but well, this is not good news if we have to deal with this texture flawed behaviour. It's amazing that we had almost no replies from LL about this, except an invitation to "experiment". That's really unfair !! === DSL broadband, wired, 8Mbps / 512kbps CPU: Intel Core 2 Series Processor (2671 MHz) Here's more details about "Experiment". Consider the Texture Memory as multiple choice of the following values: 32MB, 64MB, 128MB, 256MB, 512MB. (You can use values in between or higher, but you really are experimenting at that point)
1) Set your Texture Memory to that of the Video Card's memory. Example: I have a 512MB video card in a computer with 1Gig of RAM Another factor is the memory taken by other applications you are running at the time. If you're running some memory intensive applications along side SL, then decreasing SL's Video Memory one step may improve SL's performance. These are rules of thumb, and are not written in stone. They will change over the next few months. Hey, I gotta suggestion here. Considerin' that most users don't know how SL works and don't know how to do all this stuff (so they're gonna be upset when it don't work), howsabout:
Second Life detects both computer RAM and video card RAM on startup and automatically adjusts graphics RAM use to the correct levels. Problems solved there, right? That's called LL doing stuff instead of asking their customers to do it for 'em. I completely agree Farseek, however, there are currently some bugs in the memory detection, eg.
Dan.
I have 8GB RAM on 64bit Vista and 512MB on my ATI x1950xtx card. You've given an examples of what to do if your RAM is on the low side but what if RAM is 2GB+? I'm just trying to work out the relationship between system RAM and RAM on the graphics card (G-RAM). Is the RAM being used as a cache for G-RAM and if so, why is it restricted to that same as the G-RAM memory? With all my 8GB RAM, should (in theory) the texture memory work at 2GB (if so, it's broke) or is the limit really the size of the G-RAM? It averages at 30% full when in SL (I have no swap drive) and I never, ever use up more than 50% of my RAM unless I'm using Photoshop or AV apps so basically, that 4GB+ I've got spare could be used for textures/cache/etc. Is there currently any scope in SL to utilise that spare capacity? What of the future? Wahey!
Just logged on using the new 1.22 RC0. All looking very good so far as this thread goes so far. Even with the view distance set to 512m, most closer textures things are in a recognisable state in less than 5 secs. An incredible difference to loading times. Quite like the way AV's start of as silhouettes until they get 'coloured in'. Now off to find some super heavy sims to see if I can break it Recommend visiting The Wastelands sim for some high-res, texture-rich environment which has crashed my SL viewer before if I had it on 512 with a clear cache.
Holy Sh**! What have you done there???
After installing RC 1.22 I TP'd to a mall with tons of vendors. Most of the textures loaded within a fraction of the time it needed with the old viewer. GREAT JOB, LINDENS!!! The only thing I don't like: textures that aren't loaded yet are invisible (and the associated object too). I'd prefer the "gray" method, so that I don't login with an invisible prim-skirt Stuff always loads good on a fresh install. Then after a few days it is back to the same old issues even with sculpties not rezzing all the way that was previously fixed and smashed out and overwritten ... AGAIN.. in the last release.
So I will wait and see if things still load fast in 2 weeks. I tried 1.22 RC and it has not improved load time on textures from my inventory. 512x512 is taking about 55 seconds in 1.22 and 1.21.
Well, Joshua, tell us your system configuration because I did not have your experience. Oh how I wished it were so. On my 8600M GT with 256MB of dedicated VRAM, the viewer allocated 512MB of texture space. I tried some tests with the setting left that way and the same tests with the texture size reduced manually to 256MB. In both cases the results were disappoinintg. No change in the download rate. Worse, the order of texture loading is now pretty much random and the initial loads appear invisible. This now causes people to appear naked for scores of seconds. You are going to have an outcry in PG lands. The viewer now crashes far more that the already far too many crashes i.21 viewer. So, this 1.22RC0 is a step in the wrong direction. I noticed a bunch of eyecandy changes. Can you guys have the discipline to fix the damn bugs first? This delivery of more or less random bitsis not conducive to closure.
Testing the new 1.22 viewer... for a couple of days it looked ok, but today...
royer_22.png - 1 minute in a deserted place and house is not rezzing textures. -Now I see black instead of gray (or completly nothing). Is there a way to tweek a limit of simultaneous downloads or connections?
Like in bittorrent, in which over 200 peer connections actually start make my downloads slower instead of faster... Ohh boy... just started using the new RC1 viewer. I was building in my land when suddenly half of it disappeared...
Rebaking didn't help. Disabling Object-Object Occslusion made everything come back. And now unloaded textures are WHITE for me... very eye-agressive. Gray was better for unloaded textures. So.....I had downgraded to 1.20.17 since the new released viewer rendered me unable to function in SL. Then you trumpet the new RC - which came on the heels of the server "upgrade". So now I can have black and unrezzed prims rather than grey untextured prims. With the added bonus of crashing frequently that I did not have previously.
So this last weekend we had the Grand Tour - a new texture rich environment full of avatars in formal dress every two hours. On a weekend with a 71K concurrency.....had to relog hourly as I lagged to frozen and then crashing within that hour. So I went back to using the 1.20.17 - with the same result. I crashed trying to walk from the hub in Winterfell to the dance 3 times, got a direct teleport and crashed within minutes, and prims or textures never rezzed. This is the exact same computer and the new graphics card that worked adequately to attend events, build, etc. The difference is the new lousy Server version and the new crappy viewer. This has been dragging on for months and all I hear is that Lindens are unable to replicate what their customers are experiencing......pay us more money! Shame on you! Today I resorted to using the new Imprudence Viewer, to be able to shop a little for Christmas. It helps a lot with textures.
Too bad it still doesn't have sound compiled in... but in texture desperate times... I just disabled Run Multiple Threads in the Rendering options. Wasn't that supposed to help and speed up rendering?
I think that was my main problem with the new 1.22 RC viewers. As soon as I disabled it textures rezz faster (and more of them load). I still see a major problem with cache. It's like doing detective work without having anyone to question. I logged in at my home and everything was imediatly rezzed in my 2048m land! Teleported to a store to check something out, came back in less than 5 minutes and everything was WHITE over at my land again.... ssssssssssssssssssssllllloowlly rezzing. Royer: the new loading texture seems to depend on the video card. For me it's black for everything except particles, which are white.
This is what happens everytime I log in to SL,it's only started happening since I did the recent update & it doesn't seem to happen in the evenings !!! One or two days last week all was fine everything rezzed properly but now it's back to this...vvvv frustrating.
The latests 1.22.2 RC viewer seems really better! So far so good!
I had the best skyding experience in ages. Visited 3 of my usual places crowded with textures and people with very good rezzing speeds! And home is sweet again. I can actually see my TARDIS (Doctor Who transport) rezzing pretty quick around me when I arrive at my destinations now! Hope it stays this way! Interesting. Using RC2 the textures rendering is about 2x slower compared to RC1.
CPU: Intel Core 2 Series Processor (2394 MHz) RC 1.22.2 currently taking sixty seconds to fully-rez a 512x512 texture from inventory.
Same here as for Royer!. Seems that the RC 1.22.2 has fixed it....let's keep fingers crossed..the 1.22.1 was so buggy that I had to give up using it, but 1.22.2 seems more stable!
Second Life 1.22.2 (104576) Dec 2 2008 12:04:44 (Second Life Release Candidate) You are at 250734.1, 243301.1, 29.7 in Skin Flicks located at sim822.agni.lindenlab.com (64.154.223.67:13000) CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (2493 MHz) (should show an Intel Core 2 Duo T9300..!?!?) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 Same experience here.
I find it severly rediculous and nothing seems to help at all. And at this moment i don't know what else to do anymore. I've ried everything, and that is EVERYthing. I spoke to many inworld and even if you have the newest of the newest pc with 512 video memory or more.. same as you have a 3 year old one. WHEN IS IT SOLVED? WHEN ? WHEN ? WHEN ? Guys, this isn't funny anymore! I just tried to switch thru a collection of skin demos. What happens? SL tries to reload my JACKET first! Please, tell me why?? I'm wearing this jacket the whole evening now! It looked okay all the time. Now it's blurred!!
I visited a fashion show tonight. The first models looked okay. After about 20 minutes I left 'cause every dress was a gray kind of "I like to be a sculpted prim one day in my lifetime". Please Lindens, go back to a viewer/server version when all this worked fine... or get lost in the lumber-room of virtual worlds! Why is this not a show-stopper? Since this bug crashes clients, puts undo strain on the asset server, and effectively crashes sims it is by definition a show-stopper. And why don't we have an actual person assigned to it? "Workingonit Linden" does not exist. Never has.
'SL tries to reload my JACKET first! Please, tell me why?? I'm wearing this jacket the whole evening now! It looked okay all the time. Now it's blurred!! '
Joshua, that's expected behavior. Every time you change parts of your clothing or skin, your client needs to combine those textures again (It's called 'baking') and sends them to the other clients. >And why don't we have an actual person assigned to it? "Workingonit Linden" does not exist. Never has.
You can find more info about "Workingonit Linden" here: Dear Lindens: this has got to be one of THE most critical bugs in all of SL. First, the obvious. It is the single biggest usability problem. It affects the entire SL economy as it is VERY difficult to shop, not to mention being a major deterrent to RL businesses thinking about using SL. In other words, it's costing LL potential income. Second it puts undue stress on the sim servers and asset servers - the causes additional lag as the client re-downloads the same textures over and over and over again. I have 2T of disk space on my desktop - is there REALLY a VALID reason to limit my cache to 1G? And even WITH a 1G cache, it doesn't retain textures but instead continues to reload them. This causes additional client side and server side lag as the client re-downloads the same textures over and over and over again.
Test - create a skybox using a bunch of textures but don't go over the 1G cache limit - maybe use 512M worth. Rez it in an empty sim or at some ridiculous height - say 3000m so there is NOTHING else around.. Copy the entire skybox and rez it in a different sim so the same texure UUID's are used TP from one to another and watch the same textures RELOAD!!!!! It's an insane problem. Caching is totally broken all recent viewers. Second it puts undue stress on the sim servers, asset servers, LL network, and the user's broadband connection. This costs LL lots of money. Please - put your BEST people on this. Implement whatever server side AND client side fixes you can and get them into 1.22! As mentioned above, use a hash-keyed directory structure and nuke the 1G limit. Stop reloading the same UUID over and over. Don't flush the cache until it's full, and use "lazy LRU delete" - common textures should be left in cache nearly forever. Fix the network code that is causing stalled textures - the client should be requesting a restart from a byte offset as needed. Ultimately, move to TCP stream delivery of textures. Consider multiplexing the stream to reduce connections (should only need one really.) @Meni:
I rest my case. Workingonit Linden is not a person. It's a useless chimera. Linden Lab's equivalent of sticking up their middle finger and ignoring the problem. They've done it on llTeleportAgent, on serious bugs with llSetPrimitiveParams, and now here. In short, if you see a project "assigned" to Workingonit Linden, it is not being worked on, and never will be. Yes, Cheshy, just another example on the extremely fine "customer relationship" this garage band in San Francisco imposes.
1.21 as well as 1.22 are TOTAL CRAP. period. And now start wiorking on it Lindens, or people will vote by feet. Opengid gained 30,000 subscriptions within the past two months. Cheshyr, you forgot that it obscures sim usage figures and leads to flawed decisions based on the inaccurate figures. Case in point: The Openspace price hike, which may be based on usage figures that are skewed by this bug.
Asset server problems, sim crashes, sim lag, asset server lag, client lag, texture loading problems, grid and client instability, and the openspace price hike. Nearly every major issue that effects SL today is linked to this chain reaction of bugs. If, in fact, this pans out, this chain reaction of bugs may be the biggest compound problem that effects SL today, and possibly the biggest in it's history. Certainly sounds like a showstopper to me. @Sharie Criss
I performed the test you recommended. I created a skybox on two sims, filling it wil the larges textures I could find. The results indicated the only delay in loading the textures was the time to decode the images from the cache on my local hard drive. None of the textures in my cache were downloaded from the servers. See my earlier comment above, dated 12/Nov/08. I wanted to reproduce the problem under controlled conditions so I could investigate further. I see the slow texture downloads that everyone else does. I have not been able to reproduce the problem under controlled conditions. Reproducing a difficult problem under controlled conditions is often the critical first step to identifying and resolving the problem. As for the comments on the issue being assigned to "WorkingOnIt Linden"...I assumed it indicated multiple developers were investigating this issue. I have no reason to believe that LL is overlooking this issue. I believe LL is as anxious as anyone to see this issue resolved. Just in the last couple weeks I've begun to see the cache problem. When I sign in my hair and the textures in my home skybox have to load. It only takes a few seconds (perhaps 5) but I've never seen it have to do that before.
with the upgrade starting version 120 ..... loading texture are getting worst ....... this is very upseting ...all textures are gray ...and lags not acceptable ....even writing text on chats are imposible so much lags ......I try a version 1.18 ....work perfectely ...but I was forced to load a new version ...I hope you will solve this problem or go back or allowed to use older versions ........if you can not solve this problem ...everytime you upgrade to new version is getting worst ...thank you for thak kind of upgrade ..but no thank you .......
Hi.
I Confirm that bug. It appeares after upgrading from version 1.19.4 . Repeat: 1.19.4 was the last version without this bug. Now I am testing release candidate version. and new avatars in region still are clouds or in grey. econd Life 1.22.3 (105377) Dec 10 2008 23:07:51 (Second Life Release Candidate) You are at 244567.2, 305816.1, 24.8 in Taboo Fellowship located at sim2775.agni.lindenlab.com (216.82.19.18:13002) CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (2671 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 there is more people like........ lot of more but they have problems with english...that is why you not getting more of comments or complaints ........take this as well under the consideration ...
Hardware Overview:
Machine Name: iMac GeForce FX 5200: Chipset Model: GeForce FX 5200 I have been experiencing serious issues with this too. Since 1.20 LL Please note the number of people experiencing this problem is much much higher then what is being reported here. most of the people experiencing these problems do NOT bother to report to jira. the main reason being is they feel LL is not listening and does not care what the customer base has to say, and that it's not worth it to report. Wayfinder wrote: Good question. The problem continues in RC 1.22.4; textures are taking way too long to load, and the lag meter is constantly reporting a client problem of "too many textures in memory". I'm sorry, but that's simply not possible on my system. I have a dual core computer, with 3Gb of RAM, a GeForce GT 9500 Video Card with 1Gb of Video RAM, and a broadband connection speed of 100 Mb/s.
There is absolutely no excuse for textures taking 30 sec.+ to load for me. A typical mall full of textures should be loading in seconds, not minutes for me. This is most definitely a showstopper issue, because it's stopping people from using the world; people with slower systems are logging off in frustration, rather than wait 10 minutes or more to download the visible area of a sim. This is causing users to NOT SEE YOUR ADVERTISER'S ADS!! This should be concerning LL to the extreme; and if it isn't, then it should be a fairly simple matter to start informing people like Coca-Cola of this issue causing people to miss the ads that they're paying to run in Second Life. Actually, to heck with Showstopper, this should be "OMIGAWD!! THEY'RE HOLDING A GUN TO MY CHILD'S HEAD!Unable to render embedded object: File (" level of priority. Fix the texture transfer) not found. _____________________________ CPU: Intel Core 2 Series Processor (2199 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 The problem continues in RC 1.22.4; textures are taking way too long to load, and the lag meter is constantly reporting a client problem of "too many textures in memory". I'm sorry, but that's simply not possible on my system. I have a dual core computer, with 3Gb of RAM, a GeForce GT 9500 Video Card with 1Gb of Video RAM, and a broadband connection speed of 100 Mb/s.
There is absolutely no excuse for textures taking 30 sec.+ to load for me. A typical mall full of textures should be loading in seconds, not minutes for me. This is most definitely a showstopper issue, because it's stopping people from using the world; people with slower systems are logging off in frustration, rather than wait 10 minutes or more to download the visible area of a sim. This is causing users to NOT SEE YOUR ADVERTISER'S ADS!! This should be concerning LL to the extreme; and if it isn't, then it should be a fairly simple matter to start informing people like Coca-Cola of this issue causing people to miss the ads that they're paying to run in Second Life. Actually, to heck with Showstopper, this should be OMIGAWD!! THEY'RE HOLDING A GUN TO MY CHILD'S HEAD!! level of priority. Fix the texture transfer! _____________________________ CPU: Intel Core 2 Series Processor (2199 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 It's a showstopper, Rascal, not just because of the slowness, but because of the other problems in this bug chain. The slowness is just a symptom of the larger problem, a chain reaction of bugs that also causes overuse of region servers (likely resulting in the skewed figures that lead to the openspace price hike), and all the lag, bugs and crashes of the asset server.
Repair of this bug chain would result in increased texture loading, increased client performance, less slowness and freezes of the client, and better framerates. It would also result in better region performance and lower usage figures, stripping away the justification for the price hike, and it would stabilize the asset server, and vastly increase it's speed. Lastly, with the load so severely cut on the entire game network, SL's internal communication as a whole would likely be vastly improved, resulting in less chat lag, faster inventory loading, faster object rezzes, fewer rez errors, and faster and possibly more stabile region crossings. So yes. This bug chain, being the biggest issue in SL today, and possibly the largest in it's history, resulting in nearly every flaw of the game itself, and causing the loss of hundreds of potential users per month, as well as the thousands likely to leave over the Openspace price hike, and the tens of thousands of dollars likely to be lost in potential revenue from openspaces that are being abandoned due to the price hike caused by the skewed figures this bug chain caused, is definately a showstopper, if ever there was one. Short of the burning of LL headquarters, or an EMP sweeping California, this is a worst case scenario. Showstopper. Yesterday I fell asleep waiting for textures to load in the notoriously low-script/low lag Gianfar Peaks marketplace in Kuma.
Three hours later I woke up and the same vendors (which I had clicked on!) had not loaded. And the same vendors that were partially rezzed were STILL not completely rezzed. So I fell asleep again. ANOTHER 2.5 hours later – no change. WTF, LL?? Agreed: literal showstopper. In an attempt to contribute something objective to this issue, here are some observations I've recorded about stalled texture downloads. First, a definition:
"Stalled texture download" means a texture that has shown no download progress in the texture debug window for more than ten minutes. Observation: if a texture download has stalled for at least ten minutes, it will remain stalled indefinitely. I sometimes run two instances of the SL viewer on my computer. When my avatars are in the same location and a texture download stalls for one, it never (so far) stalls for the other. When a texture stalls for one av, I try to nudge it along by various methods. Here are the results I recorded: Of 4 attempts to dislodge a stuck texture by TPing to a different sim and back, none succeeded. Of 5 attempts to dislodge a stuck texture by relogging, 3 succeeded, 2 failed. Of 2 attempts to dislodge a stuck texture by clearing cache and relogging, it failed once and succeeded once. Cache management may be implicated in these results because a texture can remain stalled from one session to the next for any individual avatar, and the cache is where the most and the trickiest relevant state is saved between sessions. More trivia: Of 15 recorded texture stalls, the texture in the debug window showed one of the following steady states: 3 of 15 times, the state was NET, Pkt indicator steady yellow. (client choked on the texture?) 6 of 15 times, the state was NET, Pkt indicator steady blank. (sound of crickets chirping) 4 of 15 times, the state was NET, Pkt indicator blank with a green flash once each 16s (lost network connection?) 2 of 15 times, the state was SIM, Pkt indicator steady blank. (what's up with that?) (Replicated on Core 2 Duo, Vista 64-bit and Ubuntu 8.04, 4GB RAM, nVidia 9800M GT w/512MB) Many thanks to the developers who are looking into this. After exploring this issue on and off for a week and committing one full day of intensive testing there were three discoveries made.
Running Multiple Viewers In one example, I had an alt visit a region I spend most of my time in, where all of the textures should be in my local cache. After ten or 20 minutes the textures had not fully loaded. Even after right-clicking an object and editing the object, the Texture Console clearly indicated the object's textures had not fully loaded. No progress was being made in loading the textures. It seemed like the second instance of the viewer had reached a threshold where it stopped downloading textures. From an earlier peek at the source code, I know that the second instance of the viewer does not have write access to the local texture cache. Performance Hit When Cache is Full Lowering the draw distance restored the screen refresh rate almost immediately. It's not clear what the "steps to reproduce" are for this prolonged, dramatic reduction in refresh rate. It occurred in a highly texture rich region, and I was repeatedly editing objects to force loading of their textures at the highest discard level. Rendering Speed of Earlier Viewers The rendering speeds in minutes and seconds were: The current viewer was 11 % faster than the earlier 1.19 viewer at rendering the scene from the cache, and only 3 % slower at rendering the un-cached scene. The RC viewer was slower than the other viewers tested. I assume the RC viewer includes additional debug that would not be present in a final release viewer. Therefore I would expect the final release of the RC viewer to perform similarly to the current viewer. All tests were done under controlled conditions on a private island with no other avatars present, and required approximately 40 logins to compile the results above. I appreciate the efforts of all the developers working on this. I hope this information helps in their search for answers. Pjira just lost me two hours of typing and thinking time because of that stupid login timeout. I copied my work but it did not take. Suffice it to say, I am not going to do it all again.
I agree with all the comments and voted for the issue. I have the current top-specced Mac Pro with 16GB RAM and 8-cores of 3.2GHz Xeons and a nVidia 8800GT, and MacOSX 10.5.6 which partly fixes the issues in My slow rezzing is utterly intolerable and is the principle reason why I am within a gnat's whisker of declaring SL a bad joke and abandoning it. 20 minutes to 95% rezz one wall of vendors in the female skins section of Redgrave is deplorable. To TP home and back again for another 14 minutes for the same vendors to reach 95% rezzed, is doubly deplorable. What the heck was the cache doing in support of this brief travel and return? Absolutely nothing. And why are rezzing priorities so screwed up? Surely when arriving at a new shopping location the the first items to fully rezz should be the avatars and the main items of interest, the vendors? Rezzing the building textures first is wrong. Leave the floors and walls and furniture grey until last. Why, when I am nude fine-tuning shapes with many skin changes does it take four minutes for each skin change and why do they rezz twice before I can get to work? It is not amusing when Appearance is opened and a rerezz immediately starts. And a new bug with public viewer 1.21.6: My avatar is standing in a sim somewhere and has been there for perhaps 30 minutes, an item of clothing begins a spontaneous rerezz but never finishes. It remains smeared and half-rezzed forever, and needs to be unworn/worn or rebaked to fix. Why is my cache size limited to 1GB when I have terabytes of spare HDD space to devote to SL? Allow me to push my slider out to at least 10GB. Another problem related to Georgie's complaint; why is texture memory capped at 512Mb when 1 Gb RAM Videocards are commonplace now? It seems that the Lindens are doing everything to limit our Second Life experience, rather than enhance it.
____________________________________________________________________________ libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 "We now cap the amount of texture memory used at 512 MB to prevent some driver bugs when using more than that. 512 MB should be adequate for now." --Zen Linden in
Well, it's not adequate. If it was, I wouldn't keep getting the near-zero FPS blips occurring constantly in an otherwise smoothly-animating setting. Open the throttle all the way! Don't make us keep pace with the slugs, when we paid to get better performance out of SL.
This may not be entirely a viewer issue. I have tried the other viewers all of which appear to perform just as slowly. A sculpt for instance which is about 4-5k when done in the proper format. I will wait for every thing to fully load around me. Upload a new sculpt and as soon as the uploaded image starts to rez I apply it to a sculpt. and will take over 30 second to load. so over 30 seconds to load a 5k file is pretty bad. Not sure where the hang up is. It might be viewer might not. It does not seem like it to me since the others appear to perform just as badly.
OKay now the odd thing. Lets say you have one sculpt it take 30 second. then you have 10 sculpts it does not take 300 seconds. it still take about 30 seconds for them all to load. As if they are throttling the down load of images. Now the next step. Is to make people learn how to create textures. And not use a 512x512 for some like that of an elevator button. Or when I see a solid color texture and it is an uploaded 1024x1024 image which I have seen before as well. that kills me. Now another thing. I can be working on a project. face a wall wait for it to rez turn around work on another area then turn around again then I see things rezing again as if I was not even there the first time. Also noticing in all the uploaded images on this jira. Notice all the larger objects textures have loaded. while the smaller objects are taking longer to load. A funny thing is: if you have set a larger view range, often items away from you start to rezz (prims, textures, sculpties), while you still don't see the floor prims right in front of you. Isn't that scary?
Hi Silver. I think you might have hit on one of the rezzing problems. I agree with your findings. I think priorities are the reverse of how it should be. Near objects ought to be rezzing first.
Anyway, perhaps If we set draw distance to 64 metres, then only nearby objects and avatars would rezz. I am going to experiment with very tight draw distances at the expense of a loss of the visual impact of a large space and loss of information. How are we even going to know that there is another shop over there if it is not rezzing? Is this one of the practicalities of coding Second Life? Must 3D drawing deal with general and more distant objects first because this is easiest for programmers? Or easiest for client computers? What about the frustrations of slow rezzing? Something needs to change and perhaps the only control that residents have is draw distance. Personally, I really do seek to enjoy viewing a vast well-designed scenic panorama and a tight draw distance is a huge disability. In my test shop, viewing my test wall of vendors, draw distance of 64 metres made a huge difference to rezzing speed where it was once took 20 minutes to achieve 98% rezzing on 168 metres. Today it took 9 minutes for the same view to get to 98% rezzed. However, I note that some very close avatars are still totally unrezzed, 'though I do see a pair of prim boots on that one.
Surely any avatars present should be the first to rezz? — to help us avoid bumping them when we walk into an area. It is all very wrong. Oh and the furthest walls of the shop didn't rezz at all when using 64 metres draw distance. All I get there is ocean. Conclusion : a reduced draw distance helps a little but there is something still very wrong with the speed of texture rezzing. A reduced draw distance ruins the visual experience and doesn't do anything to speed rezzing of avatars. To be honest, Avatars aren't rezzing at all at distances over 15m. The only way I know someone is there is because I see their nametag, and their attachments floating in the air. I have to zoom in on them for the actual avatar body to appear.
dan linden added a comment - 12/Sep/08 12:29 PM "HTTP Textures (now HTTP assets) is something we are working on. Scaling issues are a major consideration so we do not have a specific date yet, although we would like to ship it by Christmas."
What news, Dan? Do your tests show that HTTP will help? Any idea which version of the platform/esp. viewer will bring this to us? I have chosen to use a sim called The Gor Hub to test this effect because of the texture count and nature of the build being a densely populated mall environment.
A fresh clean install of the Linden Lab Release Candidate viewer exhibits slow and non loading of textures. This is with the hardware texture memory at 512MB or 256MB. A fresh clean install of the Imprudence v1.0 viewer (non Linden Lab code) exhibits immediate texture loading and no reloading of textures. Apparently the work around is to not use Linden Lab code. Perhaps the Lindens would like to provide a weekly update on this issue and the texture reloading issue that causes the unnecessary data traffic so we won't have to speculate which leads to possibly wrong opinions and incorrect information being spread around. Is Linden Lab working on these issues or has all work been halted and transferred to Big Spacehip as part of the new viewer project? Thanks. Oh and one more thing. Linden Lab's development team is not connected to the fiber ring are they? If so they need to be off of that so they can see how the code works on normal broadband connections. I have always assumed that the slow texture loading etc was just because of my system or poor internet or something... when in fact most of the time its LL.
Glad im not alone here anyway... The huge issue that directly relates to these bugs within LL veiwer is that this is causing ISP's bandwidth limits to CAP VERY FAST (if u have a d/l limit of course)..... oddly though its only been the last say 3-4 months that my ISP is throttling me because LL is downloading over 90gig a month for me (50gig over my limit). sheesh ... Im not the only one this is happning to if not 100s ,1000s ,10000s more people this is probably affecting who have limits on there bandwidth , day in day out i hear "dam my connection sucks and keeps dropping" .... This is huge problem for a large number of residents... hope this is your No.1 priority bug fix rite now cause i sure as hell cant see anything else rite now that deserves priority over this.... Make sure you go to every group on SL that you're a member of, and ask people to vote for this issue, so the Lindens will realize that this is the one and only issue they should be concentrating their attention on right now. This is the core problem of a massive cascade of bugs and issues, and fixing this will drastically reduce the amount of issues the Lindens have to field. We just have to get them to see that people using SL are serious about them fixing this [b][i]immediately[/i][/b]; like in before the middle of January. They've been ignoring this issue for 5 years now.
Also, if you really want to make sure that the Lindens are serious about this, check for any national brand products you see featured or advertised anywhere in Second Life. Email those companies and tell them about how this huge problem is causing people to leave and/or stop using Second Life due to the framerate lag, texture problems and bandwidth maxing this problem is causing. When the Lindens start feeling it in the pocketbook, then they'll start paying attention to this. You will have to pardon my skepticism - but having been voting and commenting on this issue for the past 4 months - and having been among many effectively locked out of most inworld functions besides standing in a corner and chatting, I have very little faith that LL has any interest in users like myself. If they did, someone would have made this a huge priority long since, rather than the usual mantra of "unable to duplicate" and "try resetting your graphics preferences". I have ceased to vote on JIRAs at this point, have cancelled my premium membership, and am working to make sure that as little of my money as possible finds its way into Linden hands. Not that I think they care, just for my own self respect.
That's why you need to seek out the big companies that are paying to have their ads and products seen in SL; like Coca Cola. Write them, and tell them that the Lindens are avoiding doing something that will drastically increase the exposure their products get in Second Life. If those companies start complaining, then the Lindens are going to notice, because it's their cashflow that's at risk.
wow tried the Imprudence v1.0 viewer not only do the textures,avaters,objects load almost instantly but i stop getting throttled and disconected from ISP to...
So yea its clear just from this that the LL veiwer needs some SERIOUS ATTENTION! My experience seems different than some others. Some places seem to be much worse than others. The other day I was dancing with my sweetheart at Phat Cats and she remained grey for 45 minutes as we danced. So, last night I downloaded the Imprudence viewer and tried again. After 15 or 20 minutes at Phat Cat's the couple in front of me was still grey. On the other hand, everything at the Pot Healers adventure rezes as fast as I can look at it, even if I run through the sim.
If the size of a UDP packet exceeds the MTU setting for the client computer (or the ISP) these packets will be fragmented and may not be properly reassembled. I ran into one major ISP where UDP packets would not arrive at all if their size exceeded 1.5k.
This might explain why some people have a major problem with textures, while others cannot duplicate it. Smaller packets have less chance or corruption, so would not require as many re-sends. Perhaps if the Linden Texture Servers could limit packet size to under 1k, the problem would be solved. A change to TCP packets would lose a few percent in theoretical texture speed, but would eliminate all the problems associated with ad-hoc UDP algorithms. I don't know why we bother complaining. LL is oblivious to the problems of slow or failed texture loading. They do not experience it because the Lindens access Second Life on their own corporate network with direct access to the servers. They should be forced to use Second Life the same way the rest of us do, through our regular ISPs, and often through ISPs based in other countries, as many of us have to.
Maybe then LL would attend to some of the basic problems instead of fiddling with trivia while their baby is dying. The HTTP assets project did not ship by Christmas '08, obviously, but it is being actively worked on.
I'm not convinced that the HTTP assets project will fix everyone's texture loading issues. Presently, everyone with a texture loading problem reports it in this Jira, and we're soon talking about several different issues but assume we are all discussing the same issue. This leads to confusion and little progress. Unfortunately we cannot "just fix it" because some of these bugs do not reproduce in the LL office, due to computer differences or network conditions. We need bug recipes that can be corroborated by other residents, then we can cross-reference the similarities in simulators or resident computer hardware or viewer version, etc., draw a theory about the cause of the bug, and then create solutions. Let's divide and conquer. Below is a list of several Jiras bugs that address specific observations mentioned in this Jira. If you have information about them please add your information to that Jira bug and not this one. If you find evidence of a texture loading bug not yet addressed by the list below, please create a Jira bug for it, and describe it specifically as possible.
Downloading a single texture takes too long Textures don't load even after clicking them VWR-11418 Textures reload perpetually Texture memory is mis-detected. (Detected Texture memory of 2016 causes slow texture loading) Texture loading priorities are incorrect (nearby textures load after far-away textures) SVC-3630 Objects are removed from viewer memory too aggressively Textures are removed from viewer cache too aggressively Framerate drops when texture cache is full this newer viewer loads textures slower than that older viewer
Thank you for your help! @Dan.
I don't think the Lindens are taking this issue seriously enough. LL never takes any complaint seriously unless the bug can be observed in their workshops on the corporate network. The corporate network is not the place to test because the client software won't to be used on the corporate network by your residents. LL continues to take advantage of UNPAID TESTERS. Look, the complaints are in. Go forth and investigate. If such investigation requires testing in the REAL WORLD just like all your clients, then send Lindens out into the real world with Macs and PCs, take out private accounts with ISPs across the country and across the world. Do not use your Linden credentials as that may entitle you to special status. Use an ordinary anonymous ID to start Second Life accounts. Then go and test these complaints. I for one am so tired of standing around waiting for textures to rezz that never do. For godsake! 20 minutes for a scene to fully rezz if I do not interact with the textures? Speedier if I hover my cursor or click the offending object. Why do the closest flat textures wait until everything else further back has rezzed? As soon as I sort out what I can recoup of my linden dollars, I am out of here. I have had enough of this LL procrastination and obfuscation. I have had enough of being an unpaid trouble shooter and tester. Isn't it about time some real rewards were offered for the patience and diligence of your tester residents? We unpaid slaves have given of a lot of free time, our loyalty, and have a strong desire to see a properly working Second Life. We EXPECT SL to be fixed as a result of our reporting. What do we get in return? Denial. LL are parasites exploiting the goodwill of well-meaning residents. The first thing the Lindens must do is to accept and believe our complaints. We do not do Jira reporting for malicious fun. Take it from me, most of the busier shops I visit have serious vendor rezzing delays. It has been like this for around 4-6 months and is probably at its worst right now. It's really simple: login with a private account through an ordinary ISP and go exploring. What could be simpler than that? I am not going to spend the best part of MY day doing YOUR research. I have better things to do with my life in the real world. SL simply sucks big time. Joke. Actually it's the other way around: my software is sucking big time for the textures that never arrive. I had the understanding once upon a time that software products eventually were released to the public with all major defects removed. It was thought reasonable for just one or two beta and Release Candidates to be made available to testing agents. The RC was considered to be ready for release but was insurance against those few little problems which might be uncovered by an alternative testing group. But what do we have? RC after RC. And no REAL WORLD TESTING by LL. Please assure me I am wrong. If I am wrong then it boils down to INSUFFICIENT REAL WORLD TESTING by LL. The residents should not be your real world beta testers. I am so tired of being one of your unpaid trouble shooters. I just want a bug free Second Life experience. Please? Allow me to let LL into a little secret. Second Life is never ready for bug free enjoyment by your clients. Why not? Bad planning and organisation, reluctance to spend the necessary funds to do the job properly, and general amateurish incompetence. Stop messing about with the frills and fix the core usability problems. I could have done without Windlight, Havok and Mono, oh and voice too for that matter. Just fix usability and reliability. I used to spend 6-8-10 hours a day logged into SL. Loved it. The Lindens have killed my enjoyment with abysmal performance. I rarely log in now for more that a couple of hours a week. I just hate it — it is such a drag. And LL asks me to spend the good part of a day on research to help them? To paraphrase John McEnroe, " you have got to be kidding!". I hope this note was helpful. Regards, Georgie Greggan The McEnroe quote is actually 'You cannot be serious', but I tend to agree. The Lindens need to do their own testing now and then, and if they do not have that facility then they need to acquire it fast.
Software gets tested for the end user under end user conditions. JIRA is already problematic. It is not especially user-friendly, it is unknown to the majority of residents, and if a JIRA issue doesn't interest the Lindens then it simply gets ignored. <a href="http://jira.secondlife.com/browse/SVC-2833">SVC-2833</a> has been running over a year and has yet to receive even the bare courtesy of a Linden taking responsibility for it. Dividing this issue into myriad sub issues and requiring us to go prove there's a problem by spending unpaid time collecting data and then entering that data into half a dozen different pages is not participation or dialogue. A Linden could walk down the street, find a netcafe, and see what shopping in Second Life is actually like. An ostrich with its posterior in the air does not invite conversation. I can believe individual Lindens can't reproduce these issues. I went shopping yesterday and had no more trouble than I've ever had. But I do have these two problems:
1) Rezzing a single 512x512 texture from my inventory by double-clicking it takes about a minute Yes, these might all be separate issues. I don't care. Not only do you expect users to report bugs in a tech-y forum like this, but you expect them to organize them for you, too? You're doing really well if you can get non-software-developers to at least report them in your sandbox, in approximately the right categories. There are already quite a few very specific repros on these issues. Please get off the corporate network to do the testing! Heheh, maybe we watched different tennis matches. No I think you're right.
But after my outburst above we are now assured than no Linden will be interested in this one. I do not understand why the Lindens cannot get it through their thick skulls — Second Life is their baby. Are they not proud of it and want the best that can possibly achieved from it? It is very very obvious that it's shareholders first and bedamned to the residents. We residents are silly enough to keep spending our money and giving of heaps of our own unpaid time to do Lindens' trouble shooting and LL is laughing at us but hopes to continue exploiting us. Sure there are many on staff who are hardworking and deserve our respect but accountants restraints are killing Second Life. A residents' strike is called for. @Dan:
We have a pretty good repro for the "dropping frame rate followed by crash" problem described in comments to VWR-8841 now. By the way, if "some of these bugs do not reproduce in the LL office, due to computer differences or network conditions" then your QA lab seriously needs work. Your users aren't doing anything difficult or magical. I think the problem is self-evident and if I had to made an educated guess on one aspect this issue, I'd say the cache isn't being used as it appears everything in drawn from scratch even if I've been in the location multiple times (e.g. my home sim); flushing the cache or changing the size to 1 GB makes no difference. At any rate, if I head to any mainland sim or large estate, I have to set the draw distance to 64 in order to see anything within a timely manner.
We are investigating what viewer-side issues may be contributing to slow textures.
I've updated this issue slightly, to consolidate the internal issue ID by which we are tracking the viewer bug. (for example, Many of the comments I have read, both about this issue and about others are filled with vitriol aimed at Linden Labs. I owned a successful software development company, which I sold in 2003. Now I spend a lot of time in Second Life, which has expanded my social life, allowed me to exercise my creativity, and has given me a new RL best friend. I am extremely grateful that SL exists.
My company's software development process was ISO 9001:2000 registered and the websites we maintained were hosted on geographically dispersed, load balanced servers with encrypted data mirroring and real time failover, so I think that I know something about software QA and reliability. I have an MBA from a top ten business program and currently work (though not hard) in M&A so I think that I know something about business. My experience trying to produce bug free software and trying to keep servers up and running at all times taught me how hard it is to do. Furthermore, I was using many more off the shelf components than LL could. As a business person, I can assure funding LL was an extraordinary risk for the VCs and there is enough public information to figure out that they are not getting huge returns on that investment. Sure, I can see room for improvement in Linden Labs' QA but please try to understand the huge challenge they face, both financially and from a software QA point of view and stop howling how unsatisfied you are with a game which is free for most users, being constantly upgraded, always on, and constantly improving. What QA? They don't test in the environment in which the software is intended to be used. That's simply crazy and counter-productive.
Being free for most users is at best highly inaccurate. Once you buy land your charges start racking up at a fairly rapid rate. The company has been reluctant to look at business models, like individual subscriptions, that have proved successful for other virtual worlds, in part because the millions of users meme contributes to the company's credibility. Being free unless you own land is part of their business model, not an act of altruism.
But to address your larger point, what are you calling for? This issue is designated as a showstopper. At this stage the company apparently does not accept that there is a problem, that they need to test their software under end user conditions. We know programmers sweat blood over their code and are often understandably protective of that code. If the issue originally advanced by Wayfinder Wishbringer proves out, then this is not just an inconvenience to residents, it is a megabug that is costing Linden Lab huge resources, huge time and huge good will. Advocating a fairly urgent approach to fixing it is in the company's own interest. Ramzi,
Thank you for the update and the acknowledgment of the issue. But, seriously, after 155 days of telling us to get better hardware and ignoring all our early (release candidate) warnings that this would seriously impact the SL community's in-world experience (and we were absolutely correct in our assessment), how are we to believe that LL are serious about working with the SL community to improve the in-world experience? Why bother putting this much time and energy looking at release candidates if our well-documented, fact-based warnings are flatly ignored? There's simply no excuse for allowing 155 days of this nightmare to go unchecked. Great to finally see some progress and acknowledgment, and I hope the issue is resolved quickly. But LL's credibility black eye is simply too huge 155 days after the fact... This is embarrassing. -DK PS Head2 Footman, I hear you. And I'm usually on your side of the argument and support LL, because I do get it; and I do understand their challenges very well. But the issue here is different. Some times, you are absolutely correct; the negative response from the community is abusive and uncalled for - childish and reprehensible. But, in this case, LL have established a Release Candidate programme precisely with the objective to augment their QA capabilities, a perfectly acceptable and, in fact, commendable decision on LL's part. It's a very smart thing to do! But it is utterly useless - and down right insulting - if we as a community spend the time and effort to supplement LL's QA capabilities, find the problems, document them ad nauseam, and are not only ignored but are told the "get better hardware - not our problem" party line (which many of us have heard for years). It's inexcusable, especially after 155 days. I totally agree with Alberik. Thank you Dan Linden for providing an update.
It would have been delightful to read that you are ready to roll out fixes, but I welcome honest communication on this set of problems. Bravo Your detailed instructions on what to post to help you most are a big help. Unfortunately - I am not a programmer and have trouble putting things into program speak. I notice that the other Jira issues you specifically related are mostly very few posts and "unassigned" with you as the reporter. I get confused as to what problem is what. So if I'm trying to rez a texture - and not seeing it - is it that the texture is taking too long - or single texture taking too long? Then when I tp away and come back - and I don't see it - I now mystically should report the problem somewhere else yet again? All I know it it takes me too long to see stuff. My heads spinning. @Edward: If you're rezzing a texture and not seeing it all after 10 to 20 seconds, please report that in VWR-11418 "Textures don't load even after clicking them". Adding a snapshot of the texture console is crucial to seeing what's wrong. The description of VWR-11418 explains how to do that.
@Georgie: If you see the closest flat textures wait until everything else further back has rezzed, please take a screenshot showing the texture console and add it to SVC-3630 "Texture loading priorities are incorrect (nearby textures load after far-away textures)" , along with the info from Help > About Second Life. Thanks folks! Dan, I did just as you are asking Edward to do, back on Nov 4. That's my picture of a slow-loading texture at position 20. My comment on Nov 4 fully explains the conditions of my test, in an I'm-a-software-developer-and-think-I-know-what-you-need kind of way, including all the information you requested then, and are requesting again. Was it missing anything? Was it useful?
I'd take the time to re-post it in the new issue, or even re-run the test (I am still having the trouble), if I thought your being inflexible actually had some utility that was worth my spending the time. Is any of the information posted in this issue useful? Would it be more useful if moved to your new issues? Useful enough to make the effort? Seriously, what can we provide that will be more useful to you this time? Some very credible posters here have stated that it's simply an issue of spending a couple of hours doing some basic coding, to switch from UDP to HTTP; and examples of other applications with 3D environments show that it works well. Yet you come at us with this "scaling" issue. Scaling what? Either you're using UDP, or you're using HTTP. It's one or the other; nothing's being scaled; it's just a case of "get 'er done!"
So why are the Lindens balking at this fix which others have identified as the source of the vast majority of texture-loading issues with some authority? Kelley:
As much as some posters here are long-time coders and probably can make the best assumptions of what goes on sim-side by observing the client side, not even they can tell what is going on behind the curtains without taking a look at the actual sim code, network setup anddatabase structure, nor can they know about all the bottlenecks or issues that might arise elsewhere in the system by doing a whole protocol change, by observing things from afar. Dan even stated that they are doing the http switch, but it sadly didn't ship to christmas 08. I experienced an interesting behaviour. Dunno to what sub-ticket this might be connected, so I'm just describing it here.
I was standing in a big store (GothiCatz!) and the building and environment rezzed in... well... usable time. Just 99% the vendors and boxes where the object stood on "for sale" stayed grey, no matter how long I was standing still and waiting. Then I hovered over one item and since it was for sale, the hover tooltip showed up. 3 seconds afterwards, the texture of the object was fully rezzed. Then I started selecting one item (right-click -> edit) and its texture rezzed as well. Perhaps that helps for finding the bug or at least help some of you when you want to go out shopping. Yes, when using hovertips on an object or selecting it, the client sends a request for the object's information. Owner, creator, scripted status and such. In the same turn, the request for that object's texture is prioritized, possibly with a re-request of the texture.
Prioritizing texture requests for all objects tho wouldn't make a difference, as they'd all have the same priority again, just as they have now. I've attached another screenshot (blurry.png), this time with an in-world object that won't fully rez unless I get really close. Note the texture console says it's not even trying to load any textures. This is in my home skybox. The 4 textures on the blurry board should be in my cache. I'd been standing in this spot for several minutes with no texture console activity when I took this shot.
I don't seem to have as much trouble as some people, but in my own workspace, with all the time in the world, I'd think textures would fully load. draw distance: 160m Second Life 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release) > Prioritizing texture requests for all objects tho wouldn't make a difference, as they'd all have the same priority again, just as they have now.
Correct. But with selecting I can do what the software should normally do automatically: Give the 30 textures right in front of me a higher prio... Just a quick comment that I tried 1.22.5. It is much slower at loading textures than 1.22.4. I now see water for a minute or so after I TP to a new SIM. I can watch the SIM's land textures get painted on. People are deliciously unclothed and naked for quite some time, enough to take luschious blackmail photos. This is the slowest I have ever seen the viewer render things. I checked my settings and they are the same as when I ran 1.22.4. BTW, my computer profile is the same as when I was actively posting results here months ago.
1.22.5 now has consistently exhibits that nasty behavior I reported a month ago of rendering objects invisible for a considerable length of time (arond 30-60 seconds) while the 1st phase textures load. One peculiar behavior is the the initial ultra-low res textureload phase takes a very long time but then the intermediate res textures loads very quickly. Then it stalls for 30ish seconds followed by the final highest-res download. This behvaior has similar characteristics to the 10-second stalls I reported months ago (just read my earlier postings in this jira). It is likely related to a single packet drop followed by some very long timeout/retry logic in the viewer. 1.22.5 is totally unusable for me. I will be going back to 1.22.4 by disabling the mandatory must-update switch. This is getting tough since all of the revious releases have different showstoper bugs in them. 1.22.4, though better than 1.22.5 in texture management hasa crash on PNG snapshot bug. Oh well, no photo shoots for a while Finally, you asked if the texture memory slider is currect now. Yes, it is, but it does not, at least for my machine, make a difference. I usually set the texture memory manually to 256MB. BTW, clicking on "recommended values" does not reset the texture memory slider (minor bug). On 1.22.5 my texture memory slider is capped at 512m on a 640m card. Is that now considered "correct"?
Maggie:
Well, that's somewhat expected in 1.22 for now. See some comments above: @ Head2 Footman: I think the issue isn't how they're keeping it running, but rather how they're addressing the issues themselves. This issue has gone largely ignored, as most difficult issues to, in favor of features and easy fixes that they can brag about. What LL needs is more people like Dan Linden who aren't afraid to drop the rhetoric and talk to residents face to face, so to speak, on their level, and discuss the problems they're having, determine what may be causing them, and draw attention to the problem within LL to get it fixed. My hat's off to Dan Linden.
@ Alberik Rotaru: Free accounts, or at least those with payment info registered (which used to be required, and I feel should be again), also tend to buy money. It's not as much income for the game as a subscription, but it is more than they would have had otherwise. After all, not everyone has solid, reliable income with which they could confidently get a subscription, though when they do have extra money, they may well be tempted to buy linden. Possibly alot of it, and that's where alot of the money is in free accounts. Finally, LL's CEO M Linden ( Aka Mark Kingdon ) has acknowledged this issue on the SL Forum.
http://forums.secondlife.com/showthread.php?t=300019&page=2&pp=15 The problem seems to be indeed that texture rendering priority could be the issue. It could explain the half working workaround by setting draw distance to 64, all other graphics qualities set to low and deactivating Basic Shaders. Most remarkeble is to see that the exe of viewer 1.21 is ~65% of that of 1.20. PROPOSAL: Totally forget and ditch 1.21 & 1.22. Ditch it, burn it, scratch it, drown it, burry it.... At this very moment the business in SL stalls, simply because around Dec. holidays many newbies have arrived ( which is to be Recommend everyone to install 1.20 again at your login screen and replace download 1.21 by 1.20 on your website !! Any comments that are not adding any new information are irrelevant, and so is the Priority at this point. Gordon is just trying to keep the PJIRA clean. Your reports will be laughed at
 LL doesnt care how important this is to YOU. The only way to improve the priority is MOAR VOTES. Kelley, they however don't care for lynchmobs.
No matter how this is turned, LL is aware of this issue. They are aware of the impact of this issue. They have endured post after post of LL blog comment style writing here. Further screaming and shouting won't change a thing, nor will going after a scapegoat, nor will changing the priority here, nor will accusing LL or any body else of anything help. It will not, aside of heat up things even more. Dan already stated they're working on it, he already stated the first steps in this process. What, seriously, more do you want, than them to work on it? The magical code fairy won't descend and fix what is a horribly complex and probably very badly planned and designed system over night. Yes, I'd love to see this fixed ASAP and tomorrow, but quite frankly, the possible fact that it can't be fixed quickly scares me alot more than any possible slowness on LL's side ever could. Because it means the old system is truely screwed and horribly planned. And any flaming of probably hard working developers won't exactly heighten their spirits to work faster on this. Tho, as I said, in a way this lacks good two-way communication. We simply need to be informed more about the background process, the found causes and analysis that has been going on in the background. Information on progress reaffirms people that progress is going on. It calms them, lets them see the efforts going on. Silence, even if it doesn't equal lack of process, leaves people up to growing frustration and accusations of no work being done at all, as we can see here. in the end, this JIRA is supposed to be for calm, technical discussions, information exchange and voting, not for mudslinging, accusations or petty priority-fights. And yes, it takes all sides to keep a fire going. So to all residents involved: Stop this. Just stop the flaming. This isn't how either side in a mature environment should behave, nor will it help the issue. And to LL: Please tell us a little more about what's going on. What the plans are, what has been found and determined as causes, bottlenecks, and what a possible roadmap for fixing this is. It'd be much appreciated. My 2 cents. I have a few questions -
Does this Jira in general and ranking of issues in particular depend SOLELY on technical issues? The majority of textures loading in 30 - 40 seconds is perhaps not show-stopper technically. Like an malicious ghost with boney fingers locked around our throats, slow texture loading continues to gradually strangle the air and the life from SL. It is a spreading festering wound that trails a sea of putrid gray behind it. This weekend, in one mall in one half hour, I heard 4 separate couples give up and leave in disgust because nothing was rezing for them. If the DOS attack on LL servers caused by repeated loading of textures Identified in this thread is only a moderately severe technical bug, it is important to consider what it did to SL when it became the basis for the Open Sim land pricing decision. Because metrics showed a heavier than expected demand on servers, we had Jack Lindens announcement of a 67% price rise in the middle of a real world economic recession almost the size of the great depression. As posters in this thread have identified, those metrics \were likely based on totally flawed data because of a bug linked to slow texture loading. The upheaval of the OS pricing decision can never be quantized and diced into metrics and put on a spreadsheet. But lets consider this - SL had a negative island growth of over 2007 islands last month and negative growth of 1977 islands in November. That is a loss of 261,095,424 square meters and just under $450,000 US in tier in under two months - on something directly pointing to THIS ISSUE. ( Those figures do NOT include all the sims shut down in the last week of December to avoid the Jan. price hike) That this SOCIAL crisis is being brought about by the underlying TECHNICAL, documented and repeatable bugs that have been going on now for years, and getting perceptibly worse for 1/2 a year makes it very tough for strictly technical persons who deal only with code and need to slot everything into neat little piles. I don't mind people being passionate about what the definition of "is" is in a Jira description. There isn't anyone evil here. I just see also people trying to communicate a social crisis of unprecedented proportions in a technical forum because it is the only place and the only way they can do it. There IS an underlying technical bug causing this whole fur-ball. It has been identified, sliced, diced and it can be reproduced. The social avalanche is still rumbling along causing new damage, destroying everything in it's path. Thus it it worthy of continued reporting here. I use the free openjpeg decoder instead of the faster kakadu one, (kakadu is 32bit only). texture decoding is a lot slower, but it is worth the overall performane gain that comes with compiling an optimized 64bit viewer. 10fps+ over the linden builds! I havent noticed texture decoding getting better or worse in any recent revisions. This is probably a problem in how the viewer is using kakadu.
This is a serious matter.
I have voted. I have submitted my test cases and my day-to-day anecdotal experiences. I have followed other users examples and replicated the the user experience they described. Dan Linden had asked for more specific cases, and to file them more specific bugs, as it seems that this JIRA entry is rather umbrella. I have done so. If you haven't, do. That is the sum of what I can do. Keep submitting your test cases, screenshots, and the output of your session, both here, and under any "Relates to:" that might describe more specifically the case you are making. Don't waste your time on arguments. Please cease this back-and-forth over the priority. Please, for the sake of all users and your fellow JIRA contributors, focus on the bug, not on academic or pejorative arguements. Thanks you Linden is working on the issue - see the release notes for the Public Nightly Alpha's.
http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Public_Nightly/1.22 I think the problem here goes back to the 6 Jan post from Dan Linden that seemed to give the impression that Linden didn't have a grasp on the issue and was throwing it back to residents. Georgie Greggan's response to Dan was spot-on & I think a priority flag of showstopper is warranted based on it's definition and to ensure that Linden understood the gravity of the resident's concerns. However, assuming that Linden is now in fact actively working the issue based on the wiki notes, I think it's a moot issue for the time being. This is a meta-issue, leave it as such. Individual issues should be addressed in one of the linked issues. If you don't find your issue there, create a new issue and link it here). This thread has become too big (and encompasses too many problems) to be just one actionable bug.
(a large number of above comments in the last 24 hours have been deleted.)
Please remember that The Second Life Community Standards apply to all areas of Second Life, including the Second Life Public Issue Tracker. Any Resident who disregards these guidelines may be banned from future use of the issue tracker. Please re-read: http://wiki.secondlife.com/wiki/Issue_Tracker#Be_courteous There has been a number of comments in the past 24 hours which do not contribute to the investigation of this bug, but rather are a discussion thread (between residents directly) about this issue or how to prioritize this issue. For further discussion like this, I have created a thread in the SL Forums which is more appropriate and that others can follow if they choose: Please go to: http://forums.secondlife.com/showthread.php?t=302416 I will shortly delete the comments of this nature, above, from this VWR-8503; so that the comments remaining are those which track the technical details of this issue to assist Linden Lab. In addition, some of the comments do qualify as Flaming, Private Discussion, and Editing Wars, which are prohibited. Those residents will be contacted in-world to let them know their participation in the Issue Tracker has been revoked. Priority: the Priority set at this time is sufficient and does not need to be changed further. This issue is being actively investigated by both residents & Linden Lab. Please see Dan Linden's comment on 06/Jan/09 for specific diagnostics you could contribute toward an eventual fix. Please limit your further comments on this issue to contributions like this, and move other discussion, although welcome, to the SL Forum. Thank you, For easier reference, the comment by Dan Linden that was referred to above is this one: action_94327 (click to jump). Added this link to the description.
For the coders out there. I went through and pulled apart all of the texture pipeline code and the texture decoders for the textures itself. The only code that has changed in the change from 1.20 to 1.21 was the commenting of many over verbose texture pipeline debugging message, and a reference to an apr pool was added in the texture decoder.
Underlaying changes to the texture decoders(KDU + OpenJPG) libraries may have occured, and stalls may be occuring there. I have no clue about the code, but I do know there was a performance drop on texture loading between 1.19 and 1.20. Not so much between 1.20 and 1.21.
In 1.20 I first noticed pictures from my inventory taking 20-50 seconds to fully load. I have some bad news, good news, good news, bad news and a question.
Bad: I was mistaken about the status of the HTTP Textures project. It is not currently being worked on. It's still on the schedule, just delayed a bit. Good: Good: Sculptie texture priority was increased between 1.20 and 1.21. This appears to be the cause of Bad: As I just said, Sculptie texture priority has been bumped back down and they will load slower in 1.22 RC 6 than in 1.21.6. Question: I've seen various reports claiming that 1.20.17 texture loading was worse than 1.19.1. Was it? If so, we need a repro. Really. With, like, steps and stuff. Please make a jira titled "1.20.17 texture loading is worse than 1.19.1" with a detailed recipe that anyone can run, link it to this jira, and I'll be ecstatic to investigate. wasn't this issue initially about 1.20 being worse than 1.19 ?
@ dan
Why is HTP not being worked on? WHY is it being put off? How long is a "bit"? i month? 2 months? 3 months? a year? I have stopped playing SL due to this problem. I can NOT do the following things due to textures either taking 30 minuets to load or textures not loading at all regardless of priority. I can no longer do the following: shopping, vendor textures won't load or are taking for ever to load. Dancing, club textures and sculpties won't load. driving. roads textures won't load. Role playing, fire, police, combat. Textures not loading or taking to long to load. Enjoying all SL has to offer, textures taking to long to load or NOT LOADING AT ALL. Sculpts textures aren't just loading slow but half the time not loading at all, all we see is the round grey spheres of the base primes. Dan did you not read every post here? if not you should. Again for perhaps the 100th time, you are NOT going to find or experience OUR problems wile your connected to the grid on the corporate network. Dan, 1.19 is no longer supported and wont work on the grid unless thru a third party open source code viewer. how are w supposed to repro? why does it have to be a different jira? it's the SAME issue. how many jira's to you need on this? Oh and thank you for warning us that 1.22 RC 6 textures problem will be even worse then RC 5. Thank you for the update Dan.
(yes, this jira used to be about the difference in texture loading between 1.19 and 1.20) Now for a repro, I can't run 1.19 anymore, but I'll keep it simple: -using the 1.19 viewer, open a texture from inventory that is not in the cache, note the time it takes to fully load. Try this at home, not from the corporate network pls. @ simqt
You can find old viewers at http://wiki.secondlife.com/wiki/Old_versions . Note the instructions and warning at the top of that page.I'm on an AT&T 3Mbps DSL connection, and not connected to LL's network. The 1.19.1 viewer and 1.20.17 show the same results for me; a 512x512 texture takes ~38 seconds to download and a 1024x1024 takes 50 - 60 seconds. Do you see similar results? You guys need to pick a few sims as testing locations. IMHO anyway.
There needs to be consistency in the tests. You need to load the same textures. And you should try to coordinate test times/dates so there will be nothing like that major database work done this morning skewing the test results over time. I don't think it would take that long to set up a texture swap test meet. Just sayin.. Dan, did that 512 texture have alpha? If not your times are only slightly better than mine. It takes about a minute to load a 512x512 texture with alpha, from inventory, by double-clicking it, after all other textures have loaded. This seems like a lot for a single texture. Assuming 10:1 compression (a wild guess) that's about 14 Kbps. That's what I get in my skybox in Sentry, which I own half of. There is rarely more than one other person in the sim.
Right now there's nobody else here, and I just got a time of 60 seconds on the money. 38 seconds to download a texture?? And the alarm isn't going off on this?
There must be a serious flaw in the download of the client. If a normal webpage loads this slowly nobody would visit it. I don't understand why it would take this long when the texture can be downloaded instantly through the web search. This is a 512x256 texture : http://secondlife.com/app/image/f2af69c7-4005-fee5-d7fc-c044663dc6b8/1 It downloads instantly through the web, but through the SL viewer it takes ages... @Maxx
Yes, 38 seconds is a long time to download a texture. That's why I'm still waiting for evidence that 1.20.17 was worse than 1.19.1. If a bug snuck into 1.20.17 it's likely still in the current versions and I want to find and eradicate it. 1.22.6 RC is available now -> http://secondlife.com/download
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Meta Issue
Reopened
Showstopper
Meta-Issue: Poor texture loading and freezes indicate larger chain of bugs
of client mem.
Does this occur in any particular region, time of day, or while doing any specific activity?
Also, what kind of internet connection do you have? Are you running a wired or wireless network?
Please post a copy of your traceroute between your system and data.agni.lindenlab.com