Try turning that down to 128 MB if it's higher; or to 96 MB if it's at 128, and let us know if that makes any difference.

You are at 220229.2, 296780.2, 23.4 in Alessandra Island located at sim4343.agni.lindenlab.com (63.210.157.247:13001)
Second Life Server 1.22.3.89352

CPU: 8 x i386 (Unknown) (3200 MHz)
Memory: 16384 MB
OS Version: Darwin 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:49:16 PDT 2008; root:xnu-1228.5.18~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8800 GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28
--------------------------------------------------------------------------------------------------------------
Hi Ramzi.
Testing was confined to this one sim. I needed to stay in one region to ensure observed changes were relative.

I conducted a number of tests at 512, 256, 128, and 96 MB of texture memory. The results were inconclusive. The texture memory setting appears to be largely irrelevant with this defect. Certain user actions in the scene became implicated in initiating freezes. In fact, my discovery is very repeatable. This is the quirky behavior I was able to reproduce in the MacOSX RC10.

I am either walking my avatar or camera surfing. The freeze begins if the viewer is suddenly required to draw a drastically changed view, because I have rounded a corner or swung the camera around and possibly zoomed a little. The permanent freeze may be interrupted briefly by some occasional split second breaks as distant avatars or other movement in the scene occur.

Neither the Windows RC10, nor the MacOSX release client 1.19.1.4 exhibit this behavior.

The freeze will persist forever or until the user quits, or, as I discovered, punches the ESC key. And then the same persistent freeze can occur seconds later if the user is a bit hasty. Neither clearing cache nor fiddling with graphics settings appears to have any useful avoidance effect. The freeze just IS, and the ESC key, the escape. There appears to be nothing the Mac RC10 user can do to avoid this happening except by not using it. Yes, the MacOSX RC10 is usable but frustrating more than is reasonable.

The release client for Mac, 1.19.1.4, does not exhibit this behaviour. Same hardware, same graphics driver, same location, same client settings and same tests, including texture memory variations. Settling on 512MB failed to reveal these pauses. There are only the briefest pauses when doing some extreme, fast, camera moves to other completely different views. The improvement is so remarkable that my viewer preference in Mac clients must be for the release version and not RC10. They are very different in performance. Naturally, I have drawn the conclusion that the graphics driver on this computer is not to blame because MacOSX release 1.19.1.4 runs okay.

I thought RC8 had finally licked the nightmare that has been my SL-on-Mac experience in 2008, and RC9 wasn't around long enough for me to evaluate, but RC10 seems to be as bad as previous RC's: frequent 20-25s pauses in ui responsiveness (which also seems to affect non-SL ui too - my iStatMenus for ram/cpu/network/etc all stop updating too. i always run it in a maximised window, not full screen (full-screen mode does NOT appear to play well with Mac's multi-desktop Spaces feature ).

i especially concur with the at least 2x better frame rates under a Windows client (XP or Vista) on exactly the same hardware (main & RC). if killing OSX 10.3 support will help address this (and hopefully force a tiny percentage of mac 10.3 users spend $120 and enter the modern era), can it please please please be done asap!?? im really tired of having a SecondRate SL experience as a Mac-preferring user.

In addition to this frequent-pauses issue, I'm finding recent RCs are also not closing properly after i've been logged in for an extended period. SL & kernel_task keep the cpu (core2duo) at ~50%. i've left it like that for 15+minutes but still doesn't close. only force-quit does.

Last night I completely uninstalled both SLs (main & RC10), deleted %user%\Library\Application Support\SecondLife (includes the cache), rebooted, reinstalled just RC10, but all issues remain unchanged for me.

I have both main & RC10 graphics settings the same (inc texture memory at RC10's preferred/default 96MB (i have 8600M GT 256MB), rather than main's default to 256. (i've read elsewhere (SL forums i think) that on a Mac one should not set it to maximum, as that leaves nothing for the OS to use (which uses some, being all Mac-ish. I'm guessing the same consideration applies to Vista and its fancy Vista-ishness.)

this is all on 1 MacBookPro (June2007 core2duo2.4GHz, 2GBram, 8600M GT).

CPU: Dual i386 (Unknown) (2330 MHz)
Memory: 2048 MB
OS Version: Darwin 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:49:16 PDT 2008; root:xnu-1228.5.18~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 7600 GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.16070 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 15/65128 (0.0%)

Machine bought in January 2007, used to kernel panic within a day or 2 when ripple water was turned on, this was fixed by an Apple OS update in spring 2007 and then plain sailing with no freezes...

... Until sometime in 1.18 a change was introduced and now my iMac freezes with beachball, unable to command tab or force quit, requiring power off / on as often as several times a day.

My situation with 1.19.1.4 was that in addition to all this freezing, I had the frequent mini-freezes, and I could often command -tab to another app and wait for the viewer to recover or force quit it if it didn't.

My situation with 1.20.10 has been the mini-freezes are cured, just leaving this single issue of the russian roulette unrecoverable random beachball of death. The factors that seem to influence this are

1) Zooming in and out
2) presence of other avatars
3) time since cache last cleared.

Helping someone rez and position a megayacht in a marina, a frequent activity for me, is an example of something that causes these freezes. Sometimes as soon as I restart, it happens again a minute or 2 later.

I regularly run with Av impostoring off and graphics memory set to half installed (since I have 256 I used to set it to 112, now the system sets it to 128 by default).

Someone today just advised me to turn off VBO as well. I am trying this out now and will report if it makes any difference.

Even still, it seems there is far too much tinkering that needs to be done to get the client working on all machines.

Went to North Shore Wharf in Viedma and alt zoomed around the megayachts for a while. There were a couple of other avatars present.

Gave up on the alt zooming and walked off to look at some hovercraft. Beachball! And I managed to command tab! When I command tabbed out of SL, things were very slow, I did think the iMac was about to freeze. But I managed to Force Quit, so I avoided having to power off, which is progress.

I guess a user learns to avoid certain GUI actions as it becomes clear what brings on these problems. Consequently, treading on eggshells gives one a less freezing game. But pushing, pushing, pushing to find under what circumstances the freezes occur seems to show that some sims are worse than others. Sure, a sim populated with more prims seems to be a major problem. Avatar numbers in a sim need only be somewhere between 0 and 10 for problems to be encountered.

I minimised the viewer so I could write some notes about my experience when it entered one of its tantrums. The entire MacOSX was almost unusable, having slowed to a crawl. This is very bad behavior when the minimise action is supposed to return the Mac over to the user for other purposes.

In addition, if I have been using 1.20.10.x for a while, say 30 minutes or more, and I quit the software, it does not fully quit. Force Quit must be used. This fault is probably associated with the previous observation. So again, we have bad behavior with this viewer. It is worrying that resident status and changes may not be properly saved on these hung quit operations.

I commented earlier that using the ESC key was necessary to break out of these lock-ups but further experience shows me that Force Quit is needed more often than ESC as ESC frequently does nothing. I found that maintaining a cleared cache with frequent relogs was ineffective in avoiding lockups. It's possible to enter a permanent beachball lock-up within five minutes of a cache clean and relog. Many freezes do not even present the spinning beachball as there is no cursor displayed at all.

So what was apparently fixed in 1.20.8.x has returned and is even worse in RC10.

Please publish an RC11 with fixes for these defects. A new release version based on RC10 for Mac is clearly contra-indicated. A replacement for release viewer 1.19.1.4 should at lease be the equal of that in performance, if not better.

I am so tired of relogging to do cache cleans. I must habitually have the cleanest cache in SL. But I get no benefit with these hangups.

So yes, I am getting a lot of these problems too. And nothing I do changing settings seems to help. I pretty much have the same RC10 experience. Georgie says she walks on eggshells. That works a bit... no hasty moves, so I keep camera moves short and simple and gentle. For me, camera movement is at the heart of all of this.

Where I get most of my hangs is when I am on a new sim for like less than 10 minutes usually, and I want to do some camera surfing... one that nearly always works is where I do a quick zoom to a distant object or avatar (say 50 to 60 meters) and rotate the camera around it for a better view. Bingo! – lockup. This is supposed to be when the new view and objects in it are supposed to rerender but the viewer doesn't wait for that. It just locks up.

Also, Quits that don't finish; MacOS becomes a dog when SL is minimised during a UI freeze.... yes I get all of that.

1.20.10. is not ready for release.

Just now I did a fresh relog after clearing cache. Then I TP'd to the main Solage Fashions sim and while I waited for stuff to rezz, I started dancing with one of the animations in my Huddles EZAD. I got an immediate lockup with Spinning Pizza Of Death (SPOD). It is notable that no camera moves or avatar moves had been started. Just dancing. I was dancing for maybe 10 seconds with a fixed view and fixed backdrop.

It was found necessary to use Force Quit to escape this.

I am forming new suspicions...

It begins to look like most of my lockups happen soon after a relog after clearing cache. So a cleared cache is part of the problem! Or is writing to an almost empty cache the actual problem? Perhaps, the concurrent use of an AO or other animations is also a part of the problem?

I will experiment with these ideas in mind.

I have proven to my own satisfaction that an empty cache is part of the problem. And so is frequent clearing of it.

Start a new session, log in with a clear cache... TP somewhere; walk around a bit; do some camera surfing; it's almost guaranteed that a solid lockup with (more than likely) no cursor, not even a SPOD, (Spinning Pizza of Death).

The idea that (frequent) clearing cache as a cure-all is not helpful with RC10. During my sessions with frequent needs to Force Quit and my responses of always clearing cache before resuming after a Force Quit, is a guarantee of continued lockups.

The work-around seems to be to be very gentle with camera and avatar moves following a cache clear. Treat the viewer with great respect because it will bite you every time if you don't.

So my new personal rule with this RC10 is leave the cache clearing until the client starts to encounter problems and after clearing the cache, take it very easy; and do nothing much, especiailly until the inventory fetch process is completed. It is probably a good approach to not TP and not go exploring after a cache clear untill it is settled. More so with RC10 than other versions, I suspect.

I think the way the cache works may need to be reconsidered. Should it behave more like a FIFO buffer arrangement? That way, residents need never be bothered, no worries with a cache as it will be maintained at a respectable size and condition automatically and there will be an end to manual cache clearing. I am not a coder so I sure don't understand the basics in this area, it was just a thought. However, while RC10 seems to have particular issues in this area, obviously other versions are less troubled. But if I had my druthers, I would like cache clearing to be handled automatically, without the user needing to be involved.

By the way, while I was testing for these freezes, I incurred a failed transaction, at Solange Fashions. The vendor got my lindens but I didn't get my merchandise. Could that have been related to my tendency to freezing and to cache rebuilding, or was it purely the usual asset server glitches? Some of both?

If I clear my cache, SL will lock up (sometimes for the familiar 20-60s, sometimes irrecoverably) if I move much at all until the sim is substantially cached/rezzed. After that, it's back to its normal level of unreliability (as described in our earlier comments).

Also:
I'm finding that Mac RC10 (and several prior) sometimes take MUCH longer to rez stuff. If i TP to a new sim, the bandwidth indicators show 10-20% - it's just 'comin in slow. Reboot into Vista, RC10 pulls it in at max speed.

I have both clients set to 1000kbps. I usually have them at 1500 (I have 8Mbps ADSL & can often achieve that even from overseas/US sites if they will serve it (eg. Microsoft)), but I've recently discovered that setting the Mac SL Viewer lower helps alleviate this behaviour sometimes. But again, the Vista/XP client can usually go full speed. Grrrr....

Has anyone else noticed this?

Yes, yes, yes! Thank you Lindens. RC11 is wonderful!

Late in my experience with RC10 I formed an opinion that the viewer threated the cache as a higher priority than rendering the scene. The virtual environment hung up because work that was expected to be done was not, if that makes sense.

I did a cache cleared login to the new RC11 and camera surfing was so fast! No pauses. Frame rate generally seems to be much improved over RC10.

My issue is resolved. I am overwhelmed with gratitude. I will click the resolved button after I post this.

Georgie.

The adverse behavior was not evident and performance has improved.

In my opinion this issue can be closed.

I noted that the release notes that came with RC11 in the download were different from those in the blog article and on the web, and did not seem to mention the key bug fix.

I'm very glad to get a client that finally seems stable after months of hanging and freezing, so thanks to all who worked on this.

I need to reverse my decision that the problem is resolved.

Yesterday, there where no noticeable pauses even after clearing cache.

Today, I used RC11 much of the day. I was troubled today with 15-25 second pauses. And finally a permanent spinning beachball that needed a Force Quit to escape.

I was at the following location soon after clearing cache and all I did was a short camera zoom to get a closer look at a hair vendor. It is probable that some of the nearby objects (out of camera view) had not fully rezzed and I think this could be part of the problem.

I am wondering if the occurrance of the hang depends on what region I am on. During my many TPs, I sometimes saw that yellow dialog telling me I was in a region with different server software. Some regions gave no pause problems at all.
-----------------------------------------------------------------------------------------------
Second Life 1.20.11 (90229) Jun 19 2008 21:05:20 (Second Life Release Candidate)

You are at 172142.5, 316019.5, 22.4 in Calico Kitty located at sim3910.agni.lindenlab.com (63.210.156.68:13001)
Second Life Server 1.22.4.90499

CPU: 8 x i386 (Unknown) (3200 MHz)
Memory: 16384 MB
OS Version: Darwin 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:49:16 PDT 2008; root:xnu-1228.5.18~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8800 GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.16182 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 8/11540 (0.1%)
-------------------------------------------------------------------------------------------------

Used it today, got a freeze requiring force quit, discovered VBO was on, turned it off.

Since then, freezes have been more and more frequent, at present I just had several cycles of freeze, force quit, log in and immediately freeze again.

Official advice on setting Avatar impostors and VBO would be welcome.

Case reopened

Notably, the freezes never sem to happen when I'm out of range of other avatars - I can spend hours in my skybox alone, working on projects, without a single freeze. When I leave the skybox to visit other avatars, the freezes begin.

Freezes seems to be triggered when zooming in on something (usually an avatar) with my camera ... but I can't find a reliable way to reproduce the effect on demand.

But a new experience was the fatal one last night: I was alone in my home parcel, arriving there a few minutes after a clear cache restart and TP to home. I had fully rezzed, the room had fully rezzed. I had rezzed my Huddles EZAD on the floor. I was planning to do a normal Huddles edit to add more animations. I had the Dances notecard open, edited it, but had not saved changes. I was in the middle of getting Properties of the dance animation still in the Inventory. I dropped the context menu and then the fatal beachball event began. These are actions I always do on the home parcel, to add animations, always without problems until last night when using RC11. There were no other avs on the parcel.

With such varied circumstances surrounding individual pause events, It is extremely hard ro reach definitive conclusions. The hangs are most definitely associated with a cleared cache. If one survives after clearing of cache, the pauses become less and less until acceptable performance follows. One conclusion that is agreed to is that the pauses in RC11 are not as severe as in RC10. But there sure IS an unstable period early on after cache clears and it does not always involve the presence of other avs.

Heck! This is a tough one and not as clear cut as the RC10 events.

Relevent or not, but my home sim Klaatu is denying me entry at the moment and has been this way for 15 minutes or so: "The destination may be temporarily unavailable or no longer exists". I can move freely to other regions but not my home sim which is now described as offline and an invalid location. Ephant next door has assumed the same status. It's likely some maintenace is being done, I suppose. I thought we already had the latest server software (1.22.4.90499). OK, got home but the map says offline still - slow to update I guess. Don't know what this was about, maybe a switch to a new host?

Latest example - ! started off visiting a friend, looking at a building, zooming in and out, no issues. Then I went somewhere else and immediately froze. Force quit, log back in again, immediate freeze. Repeat about 3 times. Cleared cache and logged in again. Kernel panic, had to power off and on again.

Logged in again, things were fine for a few minutes. Then the viewer simply vanished without warning.

Aquarius, I too have seen a disappearing viewer. I was able to make it visible again because I run a little utility that lists running applications. I used this to resume. I investigated further. Why did my client vanish on several occasions? I am going to consider the possibility of inadvertently messing up a key combo.

On a Mac, Cmd+H hides the application. Cmd+Shft+H teleports me Home*. I use Cmd+Shft+H very frequently. If I accidently misstrike the shift key I lose sight of my client. The client is not minimised so it won't be seen in the Dock. To recover, in the applications menu right of the Apple menu, choose Show All.

I discovered we have a key combo conflict here. In the SL client Cmd+H is supposed to invoke Local Chat. It does not, it hides the SL window. In addition, hiding an app in the MacOSX has a quirk: You can start another copy of the client (probably a different version, though. The more I poke around the weirder things become.

So don't call Local Chat with Cmd+H because it will hide the client window.

*I actually use Ctrl+Shft+H (on the Mac) because I often run the Windows RCs. But the same key combo misstrike can occur.

Related but different is RC11's failure to quit when required. I did not see this in RC10. I have quit the client after long logins — the client window disappears but the application remains running and a Force Quit is necessary. This occurs to me every time my runtime is longer than about an hour. This almost suggests a separate issue for the JIRA. We could bundle my issue and your issue into a JIRA which looks at RC11 quit problems. Would you care to start a JIRA with your issue? I will add my quitting problem.

You are at 261988.8, 263967.5, 88.6 in Second Life Birthday located at sim7145.agni.lindenlab.com (8.10.144.147:13000)
Second Life Server 1.22.4.90499

CPU: 8 x i386 (Unknown) (3200 MHz)
Memory: 16384 MB
OS Version: Darwin 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:49:16 PDT 2008; root:xnu-1228.5.18~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8800 GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28
------------------------------------------------------
It was so bad that quitting when I had the chance, then relogging at the same place.... I launched into immediate continuation of the previous circus. RC11 behavior was utterly intolerable. I quit a second time. Then I launched 1.19.1.4 with my avatar at the same location. The difference was stark indeed. RC11 was a terrible continuing ordeal and 1.19.1.4 was an absolute pleasure. Next, I relogged to the same location again with VBO disabled with RC11. There was still some initial pausing but that relented after a time. So a disabled VBO in RC11 was helpful while leaving VBO enabled in 1.19.1.4 did not break performance at all.

Testing was at 60-80m altitude around that weird airship. I found that RC11 frequently locked my position while flying. That happened after I bumped into an object while flying. I could not fly in any direction. That condition was escaped by striking the F-key to stop flying. More weirdness.This may well be a Havok4 conflict with my Conover's Flight-Helper 6.3.3. When that was unworn the problem disappeared.

This location makes an ideal test location to debug the MacOSX version of RC11.

i think i also ran into the problem where the Viewer disappears, once where it's hidden (and possibly caused when TPing Home with ctrl+shift-h), and i vaguely recall the Viewer just disappearing entirely - not even running any more.

my incoming streaming/caching speed is also good, i can sustain 1300KB/s with max set to 1300KB/s. higher can cause slow-downs/stalls.

for me, this is the biggest improvement in the Mac SL Viewer since Apple's "Leopard Graphics Update" early this year (which i suspect was new nVidia drivers for 8600M GT?). however i've had only a few hours inworld since RC11 was released, so i'll report back again later this week.

For me the lockup is guaranted to occur in RC11, most commonly in shops, because I surf and I always have a cleared cache. The two conditions go together for me. Clear cache and camera surfing in busy locations, especially stores. It is rarely because of the presence of a lot of AVs, just prims and scripted stuff, with maybe one or two other AVs in the area.

This morning, with an almost clear cache, I was exploring stores. At each store I had to relog after Force Quitting to escape a hang, only to immediatedly descend into a low framerate/hang scenario the second my avie re-rezzed in that same location. I tell you, it has become very frustrating to go shopping and test RC11 at the same time.

I could minimise my problem by never clearing cache until forced to by SL bogging down but that point arrives pretty quickly. I could avoid camera surfing as well. These tactics slightly lessen but do not prevent the chances of a freeze. And anyway, under RC11 and not clearing cache, the frame rate deteriorates so rapidly that something has to give. It almost always ends with the beachball hang and not always does the beach ball put in an appearance. Just the hang with no cursor at all.

I should probably stop shopping but where would be the fun in that? I do persist with RC11 because of the new features and I sure do want to get to understand this bug and to press the issue with LL. If I thought I was achieving nothing, I would most certainly revert to using the 1.19.1.4 client. The 1.19.1.4 viewer is an absolute delight to use compared to RC11 as it shows nothing of this problem.

But soon 1.20.x is going to be made the main release viewer. I am fearful that if RC12 or 13 or whatever is made the release client without fixing this issue, a lot of Mac users are going to be very annoyed and disadvantaged.

What is still not clear, is the impact of the graphics card and driver in folks' Macs. I am testing with two computers both with nVidia 8800GTs and the latest MacOSX 10.5.4 including whatever drivers come with that. I have no idea how an ATI GPU deals with RC11. It may like RC11 better than the 8800GT. That is for others to test. I must say that my experience with RC11 is very remaniscent of those MacBook Pros having the nVidia 8600M GPU before MacOSX 10.5.2 gave us a better driver. Yes I went through that terrible time — my MBP was absolutely unusable for SL because it rapidly developed a falling frame rate over 5-10 minutes until the computer solidly locked up and had to be powered down to escape. RC11 feels very like that but its effects are a little less drastic over time. The end result is the same.

The final proof of the GPU and driver not being the problem this time is that these computers handle 1.19.1.4 with no problems at all.

I think my RC11 testing must end here. It's broke and now I want to get on with enjoying SL. I guess that I will not have any more to say here until I start testing RC12.

(To set an argument, right-click (or control-click) the application and choose "Show package contents". In the resulting finder window open Resources and in there should be a file named "arguments.txt". Open in text edit, add an argument to the end of the line in there and save, close and run.)

Another argument combination that seemed to help was "-set YieldTime 20", and also enabling Advanced>Rendering>Run Multiple Threads.

We are continuing to investigate.

I have used "Advanced Menu/Rendering/Run Multiple Threads" constantly for a month or so now. I cannot say whether this setting has helped or hindered.

Today, I inserted the string "-set YieldTime 30". Others trying this should ensure that the quote marks are included. The lapse into a rapid onset zero frame rate and that freeze which was only ended with a Force Quit has gone. Woohoo!

My frame rate in this sim loaded with >1,000 textures in the immediate vicinity has fallen to ~8.0fps. I suppose this is to be expected as the client must maintain a lot of visual information for when my avatar might turn around or I start some camera surfing. The frame rate rises and falls as the camera pans 360°, swinging up to 17 and back to 8 as the circle completes. It seems to me that this is quite normal and is as it should be.

No lock up, no beach ball pauses. There is the expected choppy rendering when moving about at low frame rates in a fully rendered busy area. If the avatar walks into a nearby empty scene, frame rate does recover somewhat but is still only about 15. This too is expected as the viewer is still remembering the detail in the area 5 metres behind. All very normal, I think.

As to the impact on the cache, after an hour moving around in this busy area, there is no sense that I need to relog and do a cache clean. Time will reveal more on that.

The inclusion of this string has most definitely improved this RC11 so much so that It is quite comfortable to use the test client now as my regular viewer. I hope owners of Macs with less grunt than mine can try this adjustment to RC11 and report their impressions.

I did try the -set YieldTime 30, it did not help.

Am trialling RC13 now and glad to be back using the old dark skin. However, the Mac still freezes in RC13. I mean not just one freeze but like as before, successive freezes with millisecond long ability to interact with SL. Five or six freezes with momentary breaks between them. This is most evident now in scenes where I have just arrived and there are say 10 or 12 avatars standing around.

On frame rates etc, I do expect some slowdowns because the client is dealing with 4.2 million pixels on my 30" screen. But it is distressing that the Windows RC13 and the Windows nVidia driver deals with my graphics demands very comfortably. I don't like Windows, I am a Mac fan. Otherwise I would use the Windows client all the time. There are many residents similarly equipped but who choose not have MS products on their Macs.

Dare I mention my use of a flight assist which gives me fast flying and dashing*. Wearing that, I cannot overfly Barcola/ Miramare/Dore without being logged off because of the areas' slow handoff in border crossings. My symptoms are the usual freeze while in motion: The scene is locked but I am still traveling and if I happen to have crossed a border while the screen was locked.... Pfffft... Greyscreen image and I am logged out. I relog to find my location has been set to 'Home'. I guess there are a number of faults interacting there.

I have to remind myself occasionally what it has been like by spending some time in SL using the 1.19.1.4 release. The performance of this client is still FAR BETTER than RC13. When wearing the flight assist over regions mentioned above, even If I fly over sea where the region beneath has not started to rez, there is no freeze, there is no border handoff drama. The 1.19.1.4 experience is far more pleasant. I think 1.20.x can be much better. The Mac drivers and especially, 1.20.x, need more work.

*Thomas Conover's Smooth Flight Helper.

VWR-7779 was originated by me. I now have to declare it "Unresolved".

Mahalo (thanks)

The viewer, for me is running extremely well if I do NOT go into the prefs at all. Avatar imposters in ON, Hardware skinning is OFF, VBO is off, and my anti-aliasing is set to 2x, texture memory is set to 256MB (I have an NVIDIA GeForce 8800 GT 512MB).

Thank you.

Recap for my situation:

nVidia 7600 with iMac (details below)
1.19.1.4 performance: experienced a mixture of short recoverable hangs, freezes that required force quit and freezes that required hard restart; it was worse than 1.20.12 over all

1.20.12 performance: with Av impostoring off and VBO off and texture memory set to half installed VRAM, no more short recoverable hangs and nearly no freezes requiring hard restart; however, ANY occasion of beachballing required me to force quit the viewer - it never recovers

1.20.13 performance: seems a bit worse because occasionally when the viewer beachballs, I get messed up graphics in other windows outside of SL - this didn't happen in previous RCs!! right now I have rainbow colors splattered over my display from the last viewer crash and the viewer is not running; once this happens, a hard restart is probably in the near future. I have had to hard restart more often with 1.20.13

Georgie's hangs seem to recover, mine never do
Georgie has a different nVidia card from mine

I agree with Sahoni that presence of other avatars increases the frequency of beachball requiring force quit. For example, talking to 2 friends, had to force quit several times in a half hour

I definitely find that alt zooming around with camera constraints disabled causes beachball requiring force quit. I do this all the time - building, helping people with megayachts etc.

Regarding setting prefs, remember you can do this before you log in, from the Edit menu at the top left of the window. You can fix your prefs, quit and then log in.

Hardware:
Model Name: iMac
Model Identifier: iMac6,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.33 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 4 MB
Memory: 2 GB
Bus Speed: 667 MHz
Boot ROM Version: IM61.0093.B07
Chipset Model: NVIDIA GeForce 7600 GT
Type: Display
Bus: PCIe
PCIe Lane Width: x16
VRAM (Total): 256 MB
Resolution: 1920 x 1200

My freezes definitely only occur in the presence of other avatars, never alone. I use a macbook pro with an 8600M GPU, and have SL texture memory set to half my VRAM. I've tried toggling imposters on and off, and VBO on and off, to no effect. I've also tried the "-set YieldTime 30" tweak which - while making my GPU run significantly cooler (less fan noise, w00t!) - didn't seem to cure the problem.

I don't see any relation to cache cleaning. I rarely clean my cache. Even when I do, the problem still occurs.

I did notice that two of todays freezes happened immediately on starting a new avatar animation - I sat on an object that should animate my avatar, and my client froze (before I even saw the animation). Once I'd recovered, my friend clicked on the same object, and my client froze again (without me seeing her animated). Unfortunately when we tried a 3rd (and subsequent) time, everything worked fine, so sadly this isn't a solid repro and may just be co-incidence.

A short time later, my client beachballed, and didn't look like it was going to recover. After force-quitting, I noticed that my system.log at the time of the freeze looked like this:

Jul 16 22:01:09 (my name)s-macbook-pro kernel[0]: NVChannel(GL): Graphics channel timeout!
Jul 16 22:01:39: — last message repeated 2 times —
Jul 16 22:01:48 (my name)s-macbook-pro kernel[0]: NVChannel(GL): Graphics channel timeout!
Jul 16 22:02:03 (my name)s-macbook-pro kernel[0]: NVChannel(GL): Graphics channel timeout!

(etc)

I've kept the Second Life thread dump that popped up in the "do you want to report this problem to apple?" window ... but haven't pasted that here because (a) it's big, and (b) I'm not sure if it contains personally-identifying information (or passwords, or whatever) - however, if it would be useful to the investigation, just let me know where to send it

(I also sent a regular automated crash report once I'd logged back into SL)

Then somewhere I read something about the Mac viewer doing this when you run in a window. So I switched to full screen mode and dropped my resolution to 960x600. It has been mostly smooth sailing ever since. I often go for hours even in high lag without a freeze. The problem is still there but greatly reduced.

Not sure if this work around is applicable to this specific problem but I am sure some of you will put this to a thorough test and let us know if running full screen helps.

Second Life 1.20.14 (92115) Jul 14 2008 14:53:05 (Second Life Release Candidate)

CPU: 4 x i386 (Unknown) (2660 MHz)
Memory: 1024 MB
OS Version: Darwin 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 7300 GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.4.56
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.16656 (Mozilla GRE version 1.8.1.13_0000000000)

Today, I could not wait for the pause cycle to settle because I wanted to try re-enabling camera constraints again. I did that without restarting RC14. The result was immediate improved stability — no more pauses. I sure do miss not being able to move the camera over long distances but until this defect is rectified, I find I'm forced to accept the constraints. I will test constraints On/Off for a few days, perhaps playing with other graphics settings like VBO and texture memory.

::EDIT::
Oops! I have had VBO enabled all along. I never really accepted that VBO was associated with my pauses. Nor, for that matter, did I suspect that halving texture memory helped on my hardware. So texture mem is back to the full VRAM setting and I do not have a pause problem. I have been using 2x AA without problems. I just re-enabled 'everything' water reflections and avatar impostors. About the only thing still limited or disabled is AF, and, of course, my camera constraints are back on. Looking good. However, after a cache clear relog, big camera moves give some minor pausing. That amount almost seems normal considering the work being done to download a lot of data. So I might return to an earlier conclusion that clearing cache is part of my problem. Add to that the unrestrained camera moves then the cause of my pauses is narrowed considerably:—

Cleared cache + unrestrained camera + camera moves = heavy pausing.

If I drop the draw to 128M or lower then clear cache I can swing the camera around without a single freeze.

Second Life 1.20.14 (0) Jul 17 2008 13:45:46 (Second Life Release)

You are at xxx213.0, xxx133.0, 501.3 in REDACTED located at simxxxx.agni.lindenlab.com (216.82.20.xxx:13001)
Second Life Server 1.22.4.90499

CPU: Dual i386 (Unknown) (2160 MHz)
Memory: 2048 MB
OS Version: Darwin 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:49:16 PDT 2008; root:xnu-1228.5.18~1/RELEASE_I386 i386
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: ATI Radeon X1600 OpenGL Engine
OpenGL Version: 2.0 ATI-1.5.28
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.16673 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 525/247061 (0.2%)

What I've found is that consistently at around 3:42 secs there is a big "hiccup" in the viewer (a momentary freeze). Between 5-6 mins viewer becomes jumpy / mini-freezes. At about 8:00 mins the view is very bogged down and at 10 mins it's so bad I can barley walk - I need to either tp somewhere else or re-log. I did the same test test four times, each yielding the same exact results.

Before each test I restarted the viewer and tp'd to the same location, I did not empty my cache at all or change any prefs, clothes, etc. I tp'd to the exact same location and limited my avatar to a small area.

I noticed at the onset of each noticeable decline in performance that one of the cores (processors) was close to being maxed out / if not already maxed out. I know this is nothing new to report... just thought I would share it. This is totally repeatable... I've done it four times now with exactly the same results.

I have draw distance at 96m, VBO turned off, 2x AA, and run multiple threads enabled, VRAM set to 256MB (half of total vram).

However, I think what others are describing here may be something different and I am now seeing the same thing in the new RC14. Everything seems just fine, then suddenly everything just freezes. However, so far I am seeing no difference with just changing the camera constraints. This has happened to me occasionally in the past but not often enough to be a real problem. now it suddenly seems to be happening quite regularly. I was regularly running my draw distance up to 512 in the 1.19 viewer but I have noticed de4clining performance issues and have been going no higher than 256. Now I am finding I need to stay under 128. that seems to considerably reduce freeze ups so far.

Modelnaam: MacBook Pro
Modelaanduiding: MacBookPro4,1
Processornaam: Intel Core 2 Duo
Processorsnelheid: 2.6 GHz
Aantal processors: 1
Totaal aantal cores: 2
L2-cache: 6 MB
Geheugen: 4 GB
Bussnelheid: 800 MHz
Opstart-ROM-versie: MBP41.00C1.B03
SMC-versie: 1.28f1
Serienummer: W88120UHYP4
Sudden Motion Sensor:
Status: Ingeschakeld

Mahalo

However, today I was filling in a web form while the RC14 client was beachballing terminally for about the 50th time. Safari started to beachball as well while I was typing into the text field on the web form. This happened several times - each time I had to task switch and wait for Safari to recover.

I run the SL client with the web browser off and all web pages opening in Safari. I had already cleared web cache in both RC14 and Safari before this happened.

It would be interesting to hear if others find any correlation between web browser running and frequency of hanging.

The other bad thing with RC14 is it's continuing RC13's tradition of randomly messing up the display outside of the SL window when it freezes. The dock background and icons may change color / texture, the apple for the apple menu may vanish, and multiple black or rainbow colored one pixel lines may appear around other windows.

No, I do not suspect that Safari being open is causing any defective or laggy operation of RC14 on my Mac Pro.

RC14 is still giving me grief after a cache clean if I TP to a fresh region. I get some lag, some pausing with camera moves, on a site that has not fully rezzed. IMHO, I should be able to move my camera where I want BEFORE the whole place has rezzed. This freezing is very much worse with camera constraints disabled. I never used to see that in older clients, say like 1.19.1.4. My freezes are now happening always without a cursor or beachball showing; they always end after a time and I never need to relog or Force Quit. It appears that different Mac models handle RC14 in different ways and trip up with slightly different symptoms.

While this freezing is still a problem, and a serious one for some Mac models, being permitted to continue using 1.19.1.4 is vital. And I am still distressed that frame rates in Mac versions of these clients are so bad compared to the Windows versions. Apple/ATI/nVidia/Intel are not talking about this but sure as hell, they have to fix the drivers. I can't help thinking that our pauses are still connected (in part) with awful graphics drivers. But 1.20.RCx still presents problems because when I disable camera constraints. RC14 is found wanting where 1.19.1.4 is okay.

And I am noticing that regions generally are so much slower than in the past at rezzing the scene I have entered. 8 to 10 minutes is incredibly slow. That must be a server-side problem and I have a gut feeling it is at the heart of all the problems for Mac. I have a nominal 8,000kbps ADSL connection so that should not be a problem. I have also tried three different modems and performance is similar for all of them. Can some of these problems be sheeted home to poor server performance, or a mismatch between server and Mac client?

This is just a feeling I have. Things are not right and I can't say definitely what I think the problem is. When I boot into Windows and run that version of RC14, SL experience is so much less troublesome. The fact is, it's not my job to solve the problem, only to report my dissatisfaction and my impressions.

When people ask me what do I think of running SL on a Mac, I have to tell them it is dreadful compared to Windows. I really don't understand why Linden Lab is not addressing this issue with Apple relating to frame rate issues. I will probably resume booting Windows myself, if I am going to spend any more time with SL, which I seriously doubt. Running SL in MacOSX is simply too much of a pain to continue. And I have the fastest Macintosh ever built. I am sorry for those folks trying to run SL on lesser Macs. Brave and patient souls.

I'm going to try keeping my Dock hidden while using SL and see if I can have a nice experience today on SL (better than most of last week). Last week I tried going back to v1.19 and the beachballs and freezing were still happening (even with a fresh instal of SL). So for me v1.19 is no better.

Keeping camera constraints enabled for both 1.19.1.4 and 1.20.RC14 seems to be my best interim get-out-of-jail answer. But I still see hangs, though not as bad. It is not a solution because I want to run with no constraints as I used to, and as I can with the Windows clients. The "solution" to Mac pause problems is first to repair this inability to run with no constraints, then attack the remaining less severe pausing. If I can't use my camera unconstrained, I don't want to use the client at all.

As my previous post showed, running any MacOSX client is becoming intolerable on my equipment. It just ends up after half an hour, wearing me down. For a long time I used the Windows version. It ran very well — it spoiled me. Then I thought, as I dislike Windows so much, I should use the MacOSX client. I am no masochist: the MacOSX clients are still far too painful to use. I will continue to use the Windows clients. Aarrgh, maybe not. I am fed up with SL, period. LL is abandoning support for Panther users. LL might as well abandon support for Tiger and Leopard as well. And I'll probably abandon Second Life. Unfortunately, 90% of my login time these days is spent on working on these hangs, and not on enjoying Second Life. The pausing is too much "in your face" and up front annoying. It is just too tiring and time wasting to devote any more of my time to this with its endless freezing. I must drop Second Life for more pleasant diversions.

The Windows clients do give me minor pausing. It is common to both the MacOSX clients and the Windows RCs. But Windows pausing is almost unnoticeable compared to Mac. Why the discrepancy?

The inertia being shown towards Mac usage on SL by the Lindens is having the effect of turning me off from Second Life. I suppose LL does not really care about Mac users. Why don't we have a target? "LL will ensure that by RC16, Mac clients no longer freeze." Please? We are given assurances that "it is being looked into". That reponse is no longer good enough for me without a set target. The entertainment part of my computing time is now devoted to games and I almost never login to SL (except to test the latest RC in the hope that LL has done something constructive). Messing about with skinning and other frills cuts no ice with me while these pauses continue.

I am sorry that my attitude to SL has changed. I used to love it and logged in for active usage of up to 12 hours a day. Now? I login for an hour and end pissed off in frustration. LL knows why.

well, I have cable connection of 20.000 kbit Downstream, and when I measure sl behaiviour, I only have an average DL of only 24 KB (less than 240 kbit) sustained speed !!!

the best result for 1 minute I have only 110 k peak, average speed less than 12 KByte ...
at those ranges, its no wonder rezzing in sl is taking ages ... and moving is very quirkie.
when I download from an avarage fileserver, f.i. Apple, I get sustained average speeds of above 2.200 KByte !

when I'm wrinting this, my avarage sl DL speed is sunken under 5 KByte/sec.
perhaps this could be the reason of poor performance on Mac sl viewers ?

I try to move in sl now, and get immediately a red "Client" warning, my dl is peaking at 21 KB !
ONLY 21 KB, not 210 KB, not 2.100 KB !!!

no wonder I have freeses, the data gatering has become a real bottleneck ?
perhaps it worth invenstigating this more with LL ?

well, as far I'm concerned, I call this network congestion, and a a serious one !

ooh, look, one single peak at 133 KB now ... bringing my average speed at 8 KB for a while.
I now try to walk a lil in sl, quirkie, and got stucked when I try to move around for 20 meters, then sl freeses, takes several 10's of seconds to recover, bringing my network by moments at 0 KB/sec DL ...

whééééééééé

so I have to tell I'm almost alone in my current sim, having nothing but fixed buildings around me, no particles and much water.

(Was: Mac client RC10 and later: Pauses & fatal hangs, esp. after cache cleaning)

I've been in SL for over 2 years now, so I know most of the tricks for tweaking performance. This one has me baffled--I've tried everything to no avail, including all of the suggestions listed above.

I'm more than willing to provide any data needed—just ask. I want to help hunt this down and squash it. As Georgie said, this is really ruining what used to be a good SL experience.

=============

Second Life 1.20.14 (92115) Jul 14 2008 14:53:05 (Second Life Release Candidate)

You are at 179638.0, 314699.0, 63.4 in Wales Springs located at sim8130.agni.lindenlab.com (8.10.149.197:13002)
Second Life Server 1.22.4.90499

CPU: Dual i386 (Unknown) (2160 MHz)
Memory: 3072 MB
OS Version: Darwin 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386
Graphics Card Vendor: Intel Inc.
Graphics Card: Intel GMA 950 OpenGL Engine
OpenGL Version: 1.2 APPLE-1.5.28
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.16806 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 481/92167 (0.5%)

I have just been testing 1.20.RC14 for Windows. A vastly different experience. It was notable that a bug in the Mac version is also present in the Windows version. Is it a bug is it or the result of a Preference setting? When one feels that a new location has rezzed fully, it is surprising to see several speech balloons but no avatars. On closer inspection avatars ARE showing their prim parts but no mesh parts: We see shoes, hair, attachments but no body. Only by approaching within say 5-8 metres, does the avatar fully rezz. Something to do with having Avatar Impostors on I guess? If that is the case I'll be leaving avatar impostors unchecked. I don'r really see the point of using avatar impostors. Oh and I got the usual sudden Windows client stoppage where I had to quit and reboot the computer. But that is for another Jira topic.

All along, while testing Mac version 1.20.RC10 and up, I have been claiming the Release 1.19.1.4 had superior performance. I recently began using 1.19.1.4 again and I was shocked to discover it had deteriorated and exhibited elements of what we are finding wrong with RC10-14. It is as if 1.19.1.4, while it's code is unchanged, has developed bugs, and appears to be meeting new aspects of the grid that it handles badly. I already alluded to this in an earler post.

Something has been done to the grid that generally makes the use of any recent Mac client very buggy indeed. So I am not so sure that the RC14 client is fully responsible for present woes. Yes, it looks to me like the current server release 1.22.x is not compatible with Macs. I never logged in while 1.23.x was being rolled out so this is not about that server software.

Okay, my main impression now is that when a resident logs in with 1.19.1.4 or 1.20.RCx, it can't communicate properly with the region's server. Or the network is so slow that it actually stops talking to my client. I am no guru on these matters so I am surmising. These are my impressions. Yesterday, I logged in with 1.20.RC14 in my home on my own parcel. As soon as the scene began to rezz and my first group IMs started to show in the viewer, the freezes began: l-o-n-g freezes punctuated by tiny breaks. This would have cycled on forever had I not logged off eventually. I immediatedly logged in again and the start of the session was much more normal, just the usual cyclic pauses when moving and messing with the camera. These pauses subsided enought for me to start using Second Life. I determined then and there that my previous login had failed, though I was still there and stuff was trying to rezz and failing. This was not the first time I have seen this but these days I am expressly looking out for this sort of weird behavior. I can't help but form the view that occasionally the Mac client can't properly link to the server of the current location, or the server is ignoring the Mac client. This does not appear to be related to the server being busy. My home region at most times only has 3-4 residents logged.

I always have the Statistics Bar open so I need some advice on what data I should collect during these events. That can be hard because the Stats Bar must be opened first since it never remembers it was in use or its HUD position in the previous session. I ask that this be one of the things fixed in the coming RCs.

So, my main interest now is my wish to see the grid (esp. the current sim) talking to my client without causing excessive lockups.

Conclusions I have reached recently...

MYTH: MacOSX 10.5.4 graphics drivers are still the main cause of Mac problems in SL. TRUTH: My many 3D Mac games with all settings maxed run just fine as native apps on the Intel Mac.

FACT: LL management is busy servicing the 90% plus users of SL who use PCs and therefore the <10% who use Macs get under 10% of the attention and resources from LL. Such is life.

I am actually having a reasonably stable experience still. I just spent several hours with no freeze ups or crashes. Did multiple telelports then spent and hour or so showing someone the ins and outs of the dopestyle HUD.

HOWEVER...this has come at quite a cost. I am running full screen, no voice (turning it on crashes me every time), camera constraints enabled, draw distance never greater that 128.

Those are some pretty heavy sacrifices and even with that, it is rare to go several hours without a lockup or crash. Just around the beginning of the 1.20 RC cycle I sat in a skybox at 300 meters, with my draw distance at 512, and spent several hours with camera constraints disabled examining every corner of the region I was in without moving. I seriously doubt I could even get those settings to that point now without crashing. That is a huge drop in stability.

Up til RC14 it was still good enough. I could live with the problems. Now it is back to the fragility I experienced when I first started SL over a year ago.

One thing I have been noticing. If I stay in one place for a long time, then cross a region boundary or TP to another region, I will freeze up within a few seconds. The reason this caught my attention is that it is very much like what was happening at the beginning of the region crossing grey screen problem. (SVC-972). The only difference is how the crash takes place. In that instance you got grey screened while attempting to cross. In the current crashes you seem to get safely across, then lock up.

SVC-972 seems to be a communications failure issue. This one seems to be shaping up the same: a communications failure of some sort. I will also mention VWR-6000 in reference to Mac/SL communications failures. I do know that these issues are being taken seriously by Linden Labs. There are some good people here struggling with what seems to be a difficult problem to pin down.

I'm very pleased that finally a Linden (Ramzi) is listening to Mac users .

Yes, as I mentioned in my first comment here, there have been problems like this with the Mac for a long time. However, until the recent RC versions, they have been at an acceptable level and even improved over the past year. As I mentioned above, I was able to examine an entire region from one place at 512 draw using the camera controls with no freezing and smooth action. I don't know about anyone else but I consider that really sweet performance. If windows does even better then great!

But there has been a significant decline in performance through this RC cycle. At first I chalked it up to all the new graphics features. I noticed I had to keep my draw distance under 256. Things just got too unstable when I went much higher. Now things are unstable over 128 and I have found that the camera constraints do seem to lock things up contrary to what I said in an earlier comment.

So that is one reason we are talking about the RC. I really cannot say for certain that what we are dealing with here is the same problem I dealt with last May or even related. However, I do know that the problems have grown considerably worse over this RC cycle.

I would like to hear from others here if their performance improves in full screen mode over running in a window. Of course you need to start the program in that mode since changing to full screen while inworld will usually crash the viewer within a few minutes.

I tested only for a brief time as it's late and I should be in bed. There appeared to be slightly less pausing, though it was still evident. My full screen testing will be brief because I won't be using it for my regular SL business. In just a few minutes of login time, the motion seemed smoother and frame rate faster.

It has not been a good test, nor do I intend to persist. If I can, I will avoid ever entering that mode again. I hate it.

However, if I incur serious pausing while using the RCs, I will try full screen and report my findings. Goodnight.

The biggest disadvantage of running full screen, though, is it simply cuts you off from the world. You can't even access any of the web based search or browse features on a Mac in full screen.

I have noticed this before, that I sometimes don't get IMs inworld and only see them when the are forwarded through e-mail. It seems to be happening more often lately. But I never thought about watching if this was somehow related to freezing. now that I am thinking along the lines of a communication breakdown things like this are standing out.

Cotytto: My you are observant! On that strange business of missing IMs in world. I sure have seen that plenty of times but I didn't connect the dots. I have seen the full messages in email and thought hmmm.... what? I didn't see that message inworld, it should have showed up. And yes it is a recent phenomenom, meaning that I have probably only seen that in the RCs. But on IMs, especially Groupchat IMs, we have all know the problems of lag and also of having messages not get through. That's a grid problem not a client problem. That one is extremely annoying.

Full screen solves one problem but introduces another.

(1) Since about Release 1.15.x my login screen has been totally black and I have had to shrink it with the handle at the bottom right to see the information which LL likes us to read before login. That's been a problem for 2560x1600 displays. Now, that window can be left small — I can read that stuff and see the login screen graphic. I login and then I get full screen.

(2) Can I use other applications alongside a fullscreened viewer? Yes and no. If I already have Safari open on the secondary screen, I can browse okay. But I can't type. TextEdit is open also and even though I give that app the focus, my typing is considered as happening inworld — all keystrokes are considered to be doing inworld control functions as per normal: F for Fly, M for Mouselook, etc. And the Dock is inaccessible. It's a shame I can't type text outside of the client because I use that ability a lot in windowed mode. Copy/Paste involving a NoteCard does not work either. "Windowed" will normally remain my preferred mode for this texting requirement.

How is full screen performing? In one of my usual test regions, lag is pretty bad as usual with frame rate 10-14fps. In WinXP I would normally get 30+ here. Leaving camera constraints enabled means my avatar moves and camera moves are reasonably pause free. Trouble immediately strikes with constraints disabled. Lots of pauses but control seems to be returned a little quicker than in windowed mode. Overall, constraints disabled in full screen still yields a poor camera surfing experience and is best left in constrained mode.
::EDIT:: In full screen and camera constraints disabled mode, pausing is just as bad as in windowed. It is no solution.

BTW, my Draw Distance is always 128m. Texture memory 256/512, VBO enabled, Avatar Impostors disabled, AA is 2x, AF disabled, Reflection Detail = Everything, Run Multiple Threads is ON, Fast Alpha is ON, Disable Camera Constraints is ON.

And while I have been typing this on another Mac, my frame rate has dropped to 2.1FPS, for which there seems no logical cause.

w00t!!! I logged off and found the MacOS informing me that four Apple software updates are ready to be installed. The frame rate had droped while this stuff was downloading. I wish Apple would not do that! It's a new innovation with Leopard and a damned nuisance.

full screen - 960x600
bump and shiny ENABLED
basic and atmospheric shaders ENABLED (no reflections)
Avatar Impostors OFF
Hardware Skinning ON
Nearby local lights ON
Draw 128
max part count 2048
post process qual - low
mesh detail first 4 mid, last 2 low

Hardware
anisotropic filter DISABLED
Antialiasing DISABLED (this had a bug recently so turned it off and haven't checked it since)
VBO ENABLED
Texture mem keeps reverting to 128 out of 512 (lowering this helped with the problems last may and june...not sure now. is there a way to lock it into 512?)

Camera constraints ENABLED
Run multiple threads is ON

No voice

Max bandwidth 1500...hmmmm...wonder whether that might make a diff. what is yours set at Georgie? I generally have 0.0% packet loss even right after logging in but I have heard others with good data transfer have probs at 1500 and do find at 1200 or so.

Disk cache 330 (someone with some knowhow recently said that this was better high on linux. I have always heard it was better low)

using the "Silver" skin

arguments.txt: (I may take out the -purge and see if things improve there)

--settings settings_releasecandidate.xml --channel "Second Life Release Candidate"
-multiple
-purge
-noprobe
-port 13000

Looks like there are a few settings I could mess around with a bit and see if they help or hurt.

Not sure how that bandwidth setting relates to my i'net connection — I left it at default. Also disk cache size is default. A long time ago, I was running at 1100 or so bandwidth. I never saw any change, positive or negative. I was advised it's better at default. I tried different cache sizes. Again, I saw no help gained from this change. But I was not looking to fix freezing back at that time.

Am I stable with camera constrained? I get pausing at new locations but it settles after a while. It's worse than on the Windows client and I can still use constraints disabled in the Windows client. As I reported previously, I never need to use Force Quit any more. Holding down Cmd+Q when the cyclic freezing is happening eventually gets through, and a proper quit/save does happen.

Aaargh.. I am in a shoe shop presently. No other avies here, been standing in one spot for 30 mins with the view not changing, only one avie besides me in the whole sim, but the frame rate is still killing me at 4-5fps. Unexplained ultra low frame rates continue to be my biggest ongoing pain.

Lagmeter: Client: Client framerate below 10. Possible cause images loading. (That's wrong because all textures loaded a long time ago. Network: Connection ping time is 300-600ms. Possible bad connection or file sharing app. (That's a wrong conclusion too.) I do not know why these sorts of messages appear in the Mac RC when the Windows RC has no such problems. Lag meter is giving the occasional Server: Sim frame rate is below 20. Wow! I am seeing the occasional Sim FPS drop to zero. Doesn't seem to be much I can do about any of this.

Am I stable? I don't think so. But on my home sim, Lag Meter reports all normals. I guess some of those sims are just simply broken and need work by the owner or LL. But this is the point, isn't it? So much of SL's sims give a lot of grief to Macs. Nothing's perfect. What do we do? Aspire to using the highest client settings and never go anywhere. Or compromise and screw everything down because a big part of the grid is underperforming. Well, my aim is to extract the best experience and best graphics looks. Then I go and grumble about freezes and poor frame rates. I have the fastest most capable Mac Pro ever built so pooh to compromise. There see? I am my own worst enemy in SL. LOL.

Immediately noticed a huge improvement in TP response times. Over the last several RC iterations there has been a long freeze after clicking a teleport of any sort. Sometimes up to 20 seconds before the screen goes black and the TP actually begins. Running in windowed mode the TPs are now instant as they were before. I have encountered others complaining about those TP lags but don't recall where.

Minor attack by a noob with a cage gun in cordova. attached dopestyle - activated shield, filed abuse report, deactivated shield. Flew through Gorguen, newcomb and wanderton checking out various builds then TPd to sandbox island, flew to the extension then back to sandbox island.

Noticed I had no problems at all with any sim crossing or TPs. No delays, no loss of control, no flying off into the sunset, no rubber banding. This is a major improvement over my recent experiences running full screen.

TPd back to morris welcome area and walked into the main crowd. Probably 40 - 50 people present in the 4 sim meeting area. no significant lag. crossed into Bonifacio and couldn't stop walking for several seconds as I sank into the ground. That was the first real problem. Then someone from the crowd IMd me and I swung the camera view around to see if I could spot them. At about 180 it stopped cold and gave me a beach ball.

Time was 7:55 - 24 minutes of super active use with 8 or 9 sim crossings and zero problems before the lockup. It seems to confirm the crowded areas comments I have read here.

As to the max bandwidth. I run about 6 people a day through checking packet loss, setting SL as a trusted program in the AV and firewall and adjusting their bandwidth if they can get the packet loss close to 0.0. Almost everyone comments immediately after bumping up the max bandwidth that it is a major improvement. I have had a few on rare occasions say it caused probs at 1500 so they dropped to 1000 - 1200 and it cleared right up.

In fact about an hour ago I had one that bucked the trend. set SL as trusted in AV, still huge lags, bumped the max bandwidth to 1500, still huge lags...then she mentioned her brother was downloading music files on the same connection Just out of curiosity, Georgie, how is your packet loss?

I also had the same concerns over lowering the resolution with taking pictures since I am a professional photographer/commercial artist in RL. Then I discovered you can lock the snapshot into any resolution you want. I shoot snapshots at 1920x1200 even though I keep the resolution at 960x600. I have the 23" cinema. The performance has always been better for me at the lower resolution until now. It is beginning to look like I might do better windowed

I was surprised to see none of the TP freezes I mentioned before. I have been getting them almost constantly at times lately. But these aren't my usual actions either. I often spend more time in each place and that seems to have some relation to the probs.

Then I hit the morris meeting area and moved through all four sims, stopping and spinning the camera around the crowd in each. a bit laggy but nothing serious. TPd to Miramare. hit some serious crossing lag into barcola. moved through the crowd back into miramare with no prob spinning the camera or spinning my avatar.

So by this time I am looking for a way to crash it. I headed to waterhead. That was when I hit the double TP. Just as I was turning to head into the crowd the screen went black again with the TP progress bar. I hit cancel, headed into the crowd and spun a few times. Then I took off out the back of waterhead through borrowdale, pooley, OIP and HIP. dropped into the crowd there and had a short freeze up of just my avatar on landing. Spun the camera then headed to HIP 2.

Figured I was going to have to get serious to crash this thing so headed back to Calleta to the rags to riches slum buildings. They always seem to get the memory leak flowing. I went through the buildings rezzing the textures til the drive was running almost nonstop and I started getting the misplaced textures (VWR-1001).

TPd home then remembered I was going to check the FPS. Turned it on and I was hitting 49 FPS. So i headed to morris again to test that. dropped from 15 to 3.1 fps as I walked into a crowd of about 25 avatars. it dropped to 2.7 as I spun the camera through a couple 360s. Just standing in the crown I hit about 7 fps. Moved through the crowd into all four sims, spinning the camera in each. Headed out the back side of the dore welcome area building, hit page up to fly and froze solid. time 9:49 PM

so that is 51 minutes and about 40 sim crossings through some of the heaviest avatar crowds in SL, spinning my camera and avatar all over the place as I went. the last half was with the bullheaded determination to crash the thing. I can't call this a conclusive win for full screen because this problem is so inconsistent, but this is pretty much what I have been experiencing with my current settings. will test some more when I have the time.

I tested in some of the same sims you mentioned.

Okay I remain bothered with some freezing and frame rates all over the place. There comes a time when the stats bar bandwidth drops because the new sim has rezzed and my client has all the data it needs. If I must move the camera around a lot before that completion point arrives, sure I get pauses. A little bit of camera movement gets some more data downloaded. I push the rezzing to hurry it along. Patience is needed. A time arrives when I can move around freely and zoom/circle the camera all over the place and little if any further pausing happens.

So for me a little patience with moves is needed when I arrive at a new location. The Stats Bar is a good guide to when the scene is ready and rezzed. I do see minor packet loss occasionally but only as fractions of 1%. Mostly 0%. I wish that Stats Bar was there when I log in, instead of needing to deploy it every time.

Apart from my freezes, the next most irritating thing is invisible avatars — just the prims showing. I have to move to within a foot or two for them to appear. This never used to happen and is just plain strange and unnecessary. Oh and another annoyance is white clouds instead of ruthed avies. Gimme ruth any day. I can put my camera hard against a white cloud and it remains a white cloud. I can stay in that sim for 15 minutes next to a white cloud and a white cloud is all I see. This is nonsensical.

I am again using an unconstrained camera, I employ some amount of patience for the time it taked to download the data to my client, perhaps one or two solid freezes which melt and usually after 5 or 6 minutes I can move freely even if there are a lot of avatars (usually many white clouds and grey people with a sprinkling of disconnected prims indicating the presence of more avatars. I have to keep reminding myself that the 30" Cinema has to collect 4.2 million pixels from the servers and this takes time and that time is governed by the Grid's network speed and my own internet bandwidth.

Border crossings are still a pain. For some reason I keep walking when I have taken my hands from the keyboard and the ground swallows me up. This tells me that the sim I am in is too slow at talking to the next sim and handing me over. I doubt that this problem has anything to do with my client software. I hope that new sim server software still to come addresses this issue. Another type of glitch is the one where I am walking on a sim and the screen freezes but I still hear my footsteps marching along and it is the fault of the sim not getting me the graphic data in a timely fashion. When I graphics recover, I have indeed walked a long way, and usually far further than I intended. When this happens, approaching a boarder crossing, it's a given that I will be logged out with a greyed screen. These I really hate. I recall there is a SVC Jira on this. But it all comes down to sluggish or overloaded sim servers. Fingers crossed.

You are at 278512.4, 260185.3, 21.8 in Han Xiang Zi located at sim5176.agni.lindenlab.com (8.2.32.177:13002)
Second Life Server 1.22.4.90499

CPU: 8 x i386 (Unknown) (3200 MHz)
Memory: 8192 MB
OS Version: Darwin 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8800 GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.16839 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 18/1236 (1.5%)

OK now that i have showed my set up ill get to my comment

by the way i have all the same issues as posted in this thread cycling freezing etc etc etc

now one thing i found that actually helped the performance a little on my mac and a friends computer is as follows

in the network setting in the prefs menu i found that by cranking the maximum bandwidth setting to max and the cache size to max helped
but one thing that helped the most was (and i have no real idea why) but by putting a tick in the "custom port connection" tick box and just leaving the port as is seemed to help?? and when my friend also did this too it helped her

so maybe you should all give it a go and see if that helps

What I heard early on was that the cache size is for disk cache and that is always slower than memory. hence you should only boost disk cache if you don't have sufficient memory in your system to handle SL. However I haven't really run any tests myself on that and others have disagreed so I may check into it a bit more.

About packet loss. Macs seldom have a problem with it because a lot of us don't bother with anti-virus programs or firewalls. (Yeah...Macs can be hacked I won't get into that debate here.) And that is the number one cause of packet loss. But there can be other causes. I have seen bad video cards cause up to 50% packet loss. That person was NOT enjoying their second life. I got a bit frustrated as well because nothing I knew helped. I have also seen packet loss caused by someone setting the max bandwidth too low, like around 150.

What you want to look at is the accumulative packets lost in the system info (Help - About second life, or ctrl-P then click the about button lower left).

Even in fairly healthy systems you will often see high packet loss percent when you first log in. Nuvolino's stats above are a good example. That was captured immediately after login. It shows 1.5% but with only 18 packets lost. If that was the percent 20 minutes in, that would be a major concern, but small packet losses like that during login seem to be pretty universal and seldom indicate a serious problem. Here is my stats immediately after my first log in at home today: Packets Lost: 0/1422 (0.0%). When logging into laggier environments I have seen initial packet loss as high as 200 packets.

However, in a healthy system you should see no further packet loss at all. I just logged in again and this was my starting stats:

Packets Lost: 3/1482 (0.2%)

Then I TPd straight to Morris, walked straight into the center of the meeting area, walked around through the crowd through all four sims, then back out through the morris building and checked my packet loss again:

Packets Lost: 3/24608 (0.0%)

The same 3 packets...no more. If the number of packets lost continues to go up while you are online, that indicates there is a problem somewhere. If the percentage quickly drops under 0.5% and stays there that is generally acceptable, but you should strive for 0.0% data loss after log in.

11:55 - 5/2207 (0.2%) loggin
12:05 - 246/56623 (0.4%) at sandbox island
12:15 - Lock up in crowd at morris

12:17 - 5/2365 (0.2%) loggin
12:24 - 5/45486 (0.0%) waterhead
12:33 - 9/115897 (0.0%) HIP
12:43 - 26/172601 (0.0%) Miramare
Froze maybe 5 minutes later but was really busy helping someone and didn't think to take notes. logged right back in but didn't check packet loss for a while.

~1:00 loggin
1:35 - 26/172601 (0.0%) Tikka
1:49 - 195/322281 (0.1%) tikka - inventory population
2:02- 195/391212 (0.0%) Tikka
2:16 - 201/482055 (0.0%) Morris
2:19 - walked into the middle of the crowd at morris, swung my avatar around, and froze solid

so I am lasting 20 minutes to an hour or more between freezes at my current settings. This is full screen and all settings as described in my earlier post. In the third session I spent most of the time in my workshop at Tikka with only a few people around. Very low lag.

I am wondering if there is any relation to inventory size and inventory population. I have over 31,000 items. Prospero Linden recommends keeping it under 20,000. I have been offending a lot of people lately by declining everything anyone offers me. and I have taken a couple shots at ruthlessly deleting stuff and have actually cleared out a couple thousand items.

When I log in I can open any folder and find any item I want. but there is no number of items at the top of the inventory. As soon as I search for anything, or click recent items, the inventory starts going through and population. It is like it shifts into another mode. I think all these freezes happened after that shift but I don't remember for sure. How many inventory items do you have, anyone?

OK...looks like the 1.20 viewer has gone live...time to go download and give it a good test run

Now, I still freeze, especially around the time of entry (and after) to a new sim. I used to think that this was entirely related to rezzing the scene and to the client downloading all connected data. But is that also relative to the baggage we drag around in inventory? If inventory does matter, then that is why I frequenty suffer my most serious lockups after clearing cache. I do have a habit of clearing cache for almost every login. Naturally, I often have that delay while the inventory reloads when searching. It is hard to break a habit formed, as we are advised to perform a cache clear, whenever some SL difficulty occurs. And my most common difficulty has been my freezes. Is this a catch-22?

Yeah, I will have to download the new release 1.20.x. But I somehow feel that as Mac freezes won't have been addressed that moving to that new client is pointless. I suppose it gives us the opportunity to end this Jira and start a new one under the Release 1.20.x title. After reviewing the list of changes and fixes, I think the new Release is a must have and it signals the end of this 1.20.RC0-14 project.

I did a quick test. spent some time in IMs at my Tikka place, that fulfilled the staying in one place for a while-populated the inventory-Everything that I have been thinking might be connected. Then gave it a workout at morris...couldn't freeze it. This may indicate things have changed in the new viewer or that this wasn't related to the problem in the first place. Will be very interested to hear how it works for you Georgie.

0/64420 (0.0%)
0/101886 (0.0%) populated inventory
0/141065 (0.0%) test at morris
14/181087 (0.0%) another test at morris

So according to this test the inventory population does not cause freezes in the new viewer. And since you have a good, small inventory and still get the freezing I don't think it is related.

As to clearing the cache, that is what the -purge command does in my arguments.txt file. It automatically clears the cache every time I relog. I did that because it has long been recommended for any problems and 90% of my relogs are due to problems even in the best of times. But I have been hearing things lately about that being a possible cause of problems in itself. That is one of the things I want to test as soon as we can have one viewer to test on for more than a few days

I quickly had my first hang in the new release and it was a solid beachball permanent one requiring a Force Quit. Posing a snapshot, the snapshot tool was open and I added a check to the checkbox for Auto Refresh.

Hmmm...

Yes, it is a big job to recreate all preferred settings in the new viewer. I have chosen...
Windowed;
Camera Constraints disabled;
Run Multiple Threads;
Draw 128;
Particles 4095;
Impostors OFF;
AA x4;
Texture mem 512/512;
VBO ON;
etc...

I had been active without problems for quite a while when I got a sudden freeze up while turning. It wasn't a crowded area. Just at the edge of sandbox island with a few buildings and cars around and two other avatars. I froze for maybe ten seconds and I was thinking that was it when it unfroze. I decided that was a good time to check my packet loss:

321/576767 (0.1%)

so that was about 1.5 hours of activity before I started encountering problems. Less than a minute later it froze up for good. But I am down to a maximum draw distance of 128, camera constraints on, and running full screen. That is a lot of important options crippled just to stay alive. I will do some tests to see which of those limits I can push back.

The interesting thing I am noticing is that most of these freezes are not in a crowd. and thinking back over my experiences with this I don't think crowds are a factor at all. To me it just seems random at this point. sometimes in a crowd, sometimes leaving a crowded area, sometimes when a large area suddenly comes into view. But that pretty much describes most of the activity in SL and those things rarely cause me to freeze.

I was getting the VWR-1715 pauses as well but it was very seldom. It was like now and then it would drop into that mode and it has happened much more recent that RC9. I hadn't looked much into that Jira issue...it would be a full time job to get involved with every jira issue that effects me.

A large busy store (but low customer count), Henmations which used to treat me badly, was a good test for zooming and circling an unrestrained camera. My freezes still occur but seem to be less severe, releasing me to move the avatar or camera quicker than before. I would have to say, with unrestrained camera moves, my Henmations camera test still gives me angst but the ordeal is briefer and over after a few minutes. Packet loss is up when doing that but still sub-0.1%

Generally, my 1.20.15 experience is positive. However, I already have material for a new Jira. I have discovered that it will fatally hang with a beachball, if I use the Snapshot tool and increase the image dimensions beyond the defaults, beyond the physical pixel dimensions of my Cinema display.

I'm on a 2 x 3.2 Ghz quad xeon Mac Pro with a GeForce 8800 GT and 6 GB of RAM. Straight off I'll say that viewer performance on OS X (Leopard) vs WIndows XP is quite markedly different. I get 20-25fps on Ultra settings in a densly populated sandbox under Windows vs about 6-15fps at best on Leopard. Plus avatar cloth is always disabled on the Mac viewer but can be enabled through the Debug Settings menu and works fine, but that's a different issue anyway.

RC8 did seem to fix the vast majority of freezes. Went from on average 3-5 10 second freezes per minute down to around 1 every 10-20 minutes if that. The RC releases since, and now the official 1.20 viewer have seen those freezes come back though. They seemed to peak, resulting in total viewer hangs on the days when the 1.23 server was being rolled out. Is that just a coincidence or did anyone else experience it?

By far the worst thing about the freezes, aside from really hindering productivity in world is that they also lock up the rest of the system for the duration of the freeze. This makes multitasking (and being a designer) very difficult at times. Try drawing in Photoshop and have the viewer freeze on you!

I was under the impression that VWR-2051 was the main root of the problem, but that's now been marked as fixed and I'm still seeing the problems. It seems like many things cause them, mostly any kind of camera movement has a large chance of freezing – especially larger, sudden movements as already mentioned by others. But I've also seen freezes seemingly occur from UI elements being drawn, tool tips, tool tips on objects, blue notification windows, friend notifications, the mouse approaching or changing the focus of a UI element... the list goes on. One thing is for sure though, once they start occurring, the only remedy is to restart the viewer, or they get progressively worse. It's not uncommon to end up with, like I said, 3-5 10 second freezes per minute. Try doing anything with that! Right click an object freeze for 10 seconds, click edit freeze again for 10 seconds ... freeze again for 10 seconds click the General tab freeze for 10 seconds... give up and log off. Just think how much time in a single hour that wastes, just on being frozen!

I wish I could say I had a solid repro for any of the freezes, but only general, ordinary use tends to cause them, not actual testing. Try planning or doing something quite important, and the viewer should chime in with some freezes at the most inconvenient moments. Turn the camera around a lot, zoom in on things, rotate the camera around things, walk around, turn, fly, land, zoom on something far away, zoom on something close up, zoom on another avatar, reset view, etc. and you should eventually start freezing, if not immediately. Some sessions can go for up to an hour without any freezes while others start immediately. Haven't noticed any apparent cause for this (density of avatars, objects, busy sims etc. seem to make no difference).

I hope we can see this finally fixed for real soon. It's coming up a year now since the first freezes started, back in the Voice Firstlook days... the Lindens did a good job of killing most of the freezes in RC8, but it's gone back downhill again. Roll on the next RC cycle!

At times, the view seems to have very good performance... but they seem to be infrequent and not consistent. I've experienced this with v1.20.15 in sims on both server versions 1.22 and 1.23.

Mahalo

I really wish I could get a handle on some factor that made a difference. However I think Sahoni's statements pretty much tell the story...this happens no matter what you are doing. I have had it happen under any and all possible circumstances with equal probability. It seems just as likely to occur when I am standing dead still in an empty sim as it is when I am spinning my camera view erratically in a jam packed region.

It is also just as likely to be a sudden total freeze out of nowhere as it is to progress through a series of freezes before complete lock up. Sometimes the freezes seem uniform - timed, other times they seem random.

And to make it even harder to pin down, some days it is tolerable and some days it is a nightmare like yesterday with no change to any settings or activity patterns. Although I was beginning to get the feeling yesterday that the problems may be arising from moving between sims with two different server versions. I never go the time to test if that was the case. probably just looking for something to blame it on and that yellow notice popping up was starting to look like a good scapegoat

I only hope someone at LL is having better luck pinning this down than I am.

At least, in the RCs I never saw a fatal beachball event that required a Force Quit. Just the frequent cyclic freezing which I ALWAYS recovered from after five to ten minutes. But now in 1.20.15.x, cyclic freezing is less common because, instead, I get heaps of fatal hangs. And still the abysmal frame rate. I use all the workarounds that Ramzi advised. I may as well never have bothered, because my experience remains woeful. Please explain.

It is particularly galling to be standing in my home on my own parcel, just quietly inspecting my inventory. Boom! —> fatal beachball hang. I am convinced there is more to this bastardry than issues to do with graphics, camera moves, draw distance, placing arguments in the command line, etc.... All these are red herrings and designed to convince suffering Mac users that minds greater than ours are hard at work solving this. Time to laugh sardonically.

Let's look at that... inspecting my inventory. I understand that such an action entails interaction with SL's servers. We are forced to purge cache after every crash and that means my inventory is constantly reloading itself whenever I open it. LL advise to clear cache when things are not working right. I do so religiously. There's the problem! What is wrong with our client software and the servers which creates these interaction screwups? Another time. I was just rezzing some drow ears on my avatar. The scene had fully rezzed, I was posed on a posing stand, stationary, no camera moves, and it was a quite place with no other avatars on the sim and very few scripted objects. As soon as the ears mounted, crunch!... fatal beachball event. And my teleports that go crazy? I had teleported to another sim. At the very moment that the black TP screen was replaced by the first glimpse of the new location, fatal beachball event. That was just today and I had not been logged in for very long. And what about the new problem in teleporting? I choose a place to TP to. It's an LM I have used many times before. I rez in the new sim and it is not the correct sim. No, there were no dialogs about the desired address being unavailable so a nearby location was selected for me. None of that, simply the wrong sim because reusing the LM took me to the correct sim. What about the TP where the progress bar is slow and you are told the TP failed because it was taking too long but you arrive at the chosen location anyway? HUH? Some new Jira's needed I guess.

I have the Status Bar and the Lag Meter up all the time. It's a constant that my frame rate is rubbish and there are constant warnings regarding slow ping times: "Connection Ping Time is 300-600ms. Possible bad connection or file-sharing application." The Windows version gives me very little of these warnings, none of this angst . The truth is that my internet connection is fine, and I never indulge in file sharing. So what is wrong with the simulator servers that they are so sluggish when dealing with Mac clients? May I point out that on older server software and older clients, the SL experience was very much more pleasant. There were never any pauses and freezes on my gear, though frame rate could be a tad poor at times because of terrible graphics card drivers Mac users were stuck with. Back then I used a slower internet connection and slower hardware. I have improved my end of the deal. What has LL done if not gone in the reverse direction?

I repeat my recent observations:
MYTH: MacOSX 10.5.4 graphics drivers are still the main cause of Mac problems in SL. FACT: LL management is unwilling to commit resources to a platform which has under 10% usage by residents.

In addition, because these longstanding bugs are described as difficult to solve, we are told to reduce our experience by employing "Workarounds". All that says to Mac users is that the solutions are for the Mac-using resident to provide, because LL has washed it's hand of us. LL suggests some ineffective workarounds to lessen a Mac user's experience instead of fixing the problem? LL seems destined to drive all Mac users away from SL. Please explain.

Quoting the Help bubble:

"Showstopper
ONLY the most severe, confirmed issues which demand immediate attention from Linden Lab. For example, inability for many Residents to login. IMPORTANT: Abusing this setting will cause revocation of Issue Tracker access. If in doubt, mark "Critical" instead."

In my view, this IS a showstopper, but I left the priority unchanged.

I also added (or changed) the affected version from Release Candidates to Release Version 1.20. This should negate the need to start a new Issue.

Now, if this issue is a bug then a specfic problem area is targetable and fixable. This issue is not like that so I changed the Issue Type to Meta Issue. A Meta Issue is described as a general category of problems and in the case of VWR-7779, looks like there may be a number of undefined problem areas combining to create serious issues for users of MacOSX clients.

The usual and suggested workarounds don't really help, as evidenced by others and myself. I've tried everything imaginable without success. As I stated more than a week ago, I am very willing to provide any additional data or information that may be needed, but at this point I don't know what that might be. Dear Lindens—if you are listening, please advise us on how we can help further troubleshoot and resolve this issue. Or at least tell us if you are making any tangible progress on this. Give us a little hope, please...

There was something a while back about some debug data collection that was screwing up the mac and linux RCs, and it was taken out of them at some point in the RC cycle. I wonder if it was introduced back in error in the later RCs, and removed again in the main client?

CPU: Dual i386 (Unknown) (2600 MHz)
Memory: 4096 MB
OS Version: Darwin 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8600M GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28

I'm not ready to lynch the Lindens quite yet and, while this is annoying me I wouldn't put it at showstopper until I find out how widespread it really is. The best thing we could do at this point is see if we can hunt down people who are NOT having these probs and find out what they are doing differently.

That said.... for those effected this is a major show stopper issue. I get best stability on 1.19.1(4) with a draw distance of 64m.... if I increase my draw distance at all..... back to the house of pain. I have not found a way to run 1.20 without lock-ups.

Some of the 1.20 release candidates worked better for me.... the last two not as well... the release of 1.20 - on my machine - has been the most problematic. I lock up within two minutes.... note, this is a lock up of all applications running. I am dead in the water.... and I struggle to kill the SL process to continue with doing ANYTHING on my machine.

I've tried both work-arounds suggested in the release notes (and others suggested elsewhere) and still complete disruption of my entire computing environment. It doesn't get any more show stopper than that.

As a suggestion.... Linden folks.... can your opening survey test for machine type? Can you actively query your Mac user population and get a metric for what percentage is effected? There "has to be" a way to resolve this issue....

Is there anything we can do to help further identify what is happening in the quest for resolution?

It would be exceptionally supportive for a Linden representative updated us on where this issue stands..... for those of us who have been monitoring and such for months and months.... such an update would go a long way towards easing the pain....

Great comment; I think you are referring to the Thread Monitoring code, which is a debug process we were using during the Release Candidates starting with RC7, but then turned off for viewers on Mac & Linux in RC9. (The purpose of that code was to force a viewer lockup of Second Life to turn into a viewer Crash, complete with detailed troubleshooting information. But this proved not to be useful for Macs.) This Monitoring is indeed still turned off in the final 1.20.15 viewer, so this could not be a cause of the ongoing Mac OS lockups that people are reporting.

UPDATE FROM LINDEN LAB:

I. Again, a big thanks for the continued comments on this issue (esp these detailed ones, which are very helpful). I am following the comments; apologies for any perceived silence about this bug (perhaps it is an amalgamation of bugs) on the Mac. We were unable to address it in the 1.20 viewer because its cause remains mysterious... As residents have pointed out, it does not affect all Macs equally, so we have not had solid steps to reproduce it. Also the scope of the bug is large and was not a good candidate to be able to solve quickly in pre-production leading from RC10 to the final viewer. Internally we now have some Macs which can exhibit this behavior. We do hope to further attack the problem while testing the new codebase of a 1.21 viewer (the next Release Candidate cycle).

II. As recap, the previous experimental workarounds were:
i) reduce Draw Distance below 128m (Pref > Graphics > Custom > Draw Distance slider) and UN-check Advanced > Disable Camera Constraints
ii) use an argument "-set YieldTime 20" in Arguments.txt for the SL viewer.

... but these have not been successful for all residents who experience the problem.

III. Our most recent investigations point to a (possible) different cause, related to "readbacks" from the Frame Buffer.

This seems to be strongly taxing on Macs with an Nvidia 8600/8800 card; most MacBook Pro machines have this card. (It's unclear if this extends to the Nvidia 7600 which, Aquarius, you also reported above.) The SL viewer utilizes a readback when it is compositing a bunch of images: it renders the series of textures to the Frame buffer, then "reads" the composite image back as a single texture. One utilization of this is in going into Appearance mode.

For Residents who have offered to help, We would like to gather more results experimenting with these workarounds:

iii) turn OFF Avatar Impostors, which is another key utilization of readbacks. This is disabled from Preferences > Graphics > Custom > Avatar Impostors
iv) turn OFF Occlusion calling (on by default for all users), which is another key utilization of readbacks. This is disabled from Advanced menu > Rendering > Object-Object Occlusion (make sure it has no 'X')

• These tests may help confirm the source of problem on Macs with this chipset. It would be instructive to know if (iii) or (iv) causes any change (Positive or negative) to the frequency of the cyclic pauses, length of freezing, the time to onset of problems, etc.
• If you experience and improvement, it would be helpful to know if you are also using Workarounds and (ii) too, or removed them. (iii) and (iv) address readbacks most directly and may work on their own?
• If you are willing to post your results here, please include what combination of , (ii), (iii), (iv) has caused a noticeable change for you

Thanks for your help on this, and we hope it makes possible more performance progress in the future viewer!

Graphics Card: NVIDIA GeForce 7300 GT OpenGL Engine

I already had avatar impostors off. I killed the Object Occlusion too and gave it a good test run. Ran the draw distance up to 320 and disabled camera constraints just to see if it would lock up. I was hitting between 6 and 9 fps even in uncrowded areas. I was getting the long pauses before TPs would start and the double TPs on almost every TP. The hard drive was running excessively at times. It was really pretty messy but I didn't seem to be getting the freezes and it seemed to recover from the worst lags ok. I eventually started freezing after turning camera constraints back on and dropping back down to 64 draw in the crowd at morris. After a few minutes it froze solid and I had to force quit.

I was still running with some of the prior suggestions on, so I'll try relaxing those and see what happens: I was using 256 out of the 512 graphics memory, and the draw distance was set to 128m.

I did what you said, and then went wandering at some of the Rezzable sims, with no hangs. At most some minor slowdowns, but those were much more like the bad old windows days, not like the shiny new mac days

My iMac does have an Nvidia chip in it (8800GS I think).

I was still using the other suggestions (128m draw distance, limiting the amount of graphics memory used), so now I can try relaxing those and see what happens!

I did notice that by turning off "occlusion calling" that my flexi-prim skirt stopped rendering like it used to. But that's a small price to pay for no more beachballs of doom!

Apart from the above observations, no pauses at all and no signs of the beachball, no TP problems.

Ellen> I wore one of my prim flexi dresses and there were no unusual disappearing acts. I do think that problem may be specific to particular items. I recall when the mesh dress was a big problem for nearly everybody when Windlight first showed up but I have not seen that effect for a long time.

Georgie is happy.

I reported earlier that some of the initial workarounds made little to no difference to my glitches. These last two sure did impact positively, although I already had Avatar Impostors set to OFF. I think the biggies are Camera Constraints and Occlusion. So, as you intend, Ellen, I will be also be peeling back some of these earlier workarounds in the next few days. I have a good feeling about this. It's a pity that I now have some side-effects like a grey world that I never saw before. So there is a lot that needs to be accomplished with improving rendering effects and with frame rate.

On that last point, There is perhaps no possibility of an improvement there until the arrival of Snow Leopard, MacOSX (10.6). "Snow" is described by Apple as not a new OS in that it will introduce a lot of new features, no, but it is instead going to be a performance update with many performance aspects including how graphics works, all receiving fine tuning and in a lot of areas, a full rewrite of the code. There is plenty of reason for optimism here but we will have to be patient as Snow will not be seen on Macs until around June, 2009. Here is an update to my computer information.....

The Workarounds:
Draw Distance>96m
Camera Constraints>enabled
Argument "-set YieldTime 20" deployed
Avatar Impostors>OFF
Object-Object Occlusion>OFF

ALL MY RELEVANT SL SETTINGS:
Graphics:
Custom> Ultra/ Run Windowed/Window Size>2556x1556
All Shaders>ON
Reflection Detail>Everything>ON
Hardware Skinning>ON
Max Particle Count>4096
Post Process Quality>HIGH
Mesh Detail:
Objects>HIGH
Flexiprims>MID
Trees>MID
Avatars>HIGH
Terrain>MID
Sky>MID
Lighting Detail>Nearby Local Lights>ON

Hardware Options:
Anisotropic Filtering>OFF
Antialiasing>2x
Enable VBO>OFF
Texture Memory>256 (VRAM installed>512MB)

Network:
Maximum Bandwidth>900kbps
Disk Cache Size>600MB

Voice Chat>OFF

Advanced menu>Disable Camera Constraints>OFF
Advanced menu>Rendering>Run Multiple Threads>ENABLED
Advanced menu>Rendering>Object-Object Occlusion>OFF
Advanced menu>Rendering>Info Displays>Avatar Rendering Cost>ON (occasionally)

Finally, my hardware summary:
Mac Pro3,1>DualQuad Xeons/3.2GHz(Harpertown)
nVidia GeForce 8800GT>512MB VRAM
8x2GB RAM
Network>ADSL2+ Router/Modem> 8,000/384kbps

I gave the ideas a try, but I can't decisively say that one thing did or did not improve the situation. Here are a few observations:
--Suggestion , especially draw distance, reduces load on the processor; I've never really been able to go much higher than 128 m normally anyway because it just bogs the system down (but not in a crashy way). Camera constraints really didn't seem to matter, except that I realized how accustomed I've become to having Disable Camera Constraints turned ON. Having it turned off made me feel really restricted.
--Suggestion (ii) is inconclusive for me.
--Suggestion (iii) could possibly have given some improvement. I was in a speed building competition with a group of avatars and didn't have the "normal" stalls and stutters as in previous sessions. There was one time when I changed a color on a prim that I got the network stall and stutter for a few seconds. I've actually found a very inelegant trick for dealing with severe network stalls that cause sound/music to break up and stutter: shutting the lid on my laptop for a few seconds, then reopening will clear the interruption and restore normal behavior (at least until the next incident).
--Suggestion (iv) I can't try. The occlusion option is grayed out on my computer. It shows an X next to it, but I can't change it in any way.

Other observations:
While I had some perceived limited success at the speed build I mentioned, things got really bad later on at a different sim (Dreams, to be exact). There is a building contest there, too, and I was walking the grounds looking at what everyone had built. Repeatedly, I would lose control of my avatar. I could watch my network completely stall, traffic plummet to zero, and my avatar would just keep walking and walking and walking until the network popped back to life again. I would describe it as extremely severe (and so frustrating too). There were few if any other avatars in the vicinity and there weren't many scripts around either (this was a condition of the contest). I got one curious thought, though: the contest had split the sim into many small 512 plots. Could all of these separate parcels and navigating around them contribute to network load and stress? I was trying to think back to SL5B and seem to recall a similar pattern. All those small SL5B plots and my avatar was constantly walking off on its own. So, a hypothesis to test: Does navigating from parcel to parcel on a sim cause anomalous network load/stress?

In all of the notes here, I am seeing one thread maybe: "something" (that elusive something) keeps hijacking control of network traffic, slams it to a halt for countless seconds, and renders everything frozen. But what is the exact culprit? Sure, if we remove every network input and stimulus, everything should run smoothly. But obviously this is silly-what's the point of SL with no sound, no color, no lights, no options, etc. I can handle a slow system that still responds predictably-it's this unpredictability and random chaos that has been difficult to deal with. I don't mind running SL with a 96 m draw distance, but taking one small step and walking half a sim every few seconds is driving me crazy.

I have one other observation to share and ask about: For the past several iterations of 1.20, including the current one, I rarely am able to quit SL successfully. I almost always (99% of the time) get an Unexpected Quit when I quit SL. However, this unexpected quit only rarely generates an LL crash report the next time I launch. It generates an Apple Crash Report every time, and I've actually been sending those Apple's way. So, does anyone else here have that same problem? And, what long term, cumulative effects does an unsuccessful quit have on my SL performance?

==========

Just for the record again: MacBook, 2.16 GHz Intel Core 2 Duo, 3 GB 667 MHz DDR2 SDRAM, Mac OS X 10.5.4, and only me, myself, and me on DSL 2016Kbps/384Kbps

The experiment continues...

You are at 239206.4, 281570.2, 24.1 in Royal Poinciana located at sim3588.agni.lindenlab.com (216.82.22.69:13000)
Second Life Server 1.23.4.93100

CPU: Dual i386 (Unknown) (2400 MHz)
Memory: 4096 MB
OS Version: Darwin 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8600M GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.17034 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 2/2906 (0.1%)

I'm new to this thread as I found my way here in hopes of a resolution to the freezing issue I'm seeing with the official release of the viewer. I've always used the release versions of the viewer, so I have no experience with the RC.

When I first joined SL in 4/2007 I would periodically experience a GUI freeze in SL that would affect all running apps. I could still SSH into the machine, but killing processes would just result in zombies. Sometimes I could wait out the freeze, but most of the time I had to force restart or restart from an SSH connection.

The problem gradually got better until somewhere in the 1.18.x timeframe (I think) when the whole-machine freezes disappeared. SL would still beachball periodically, but I could at least task switch to another app in the meantime. With the latest release viewer (1.20.15.92456) I am now experiencing the whole-machine freezes again.

For me it is almost completely due to zooming with the camera. If I zoom to within some distance of an item/avatar, the machine freezes for 10-15 seconds, unfreezes long enough to one or two key presses and then back to a 10-15 second freeze in a repeating cycle. Key presses register and are played back after the freeze. Once the freeze occurs I can recover by pressing Esc a few times which will bring my camera back to default view distance once a freeze cycle is over.

I will look over the latest suggestions in these comments, try them out and report back if any are successful in consistently addressing the freeze.

I have been testing out Ramzi's suggestions and I have not noticed any differences in performance using the different combinations of settings. The only thing I have noticed that helps me is to keep the draw distance way down (below 128) and turn off VBO.

Mahalo

Generally, my SL experience with the new suggestions employed (minus my reversion to VBO ON and Draw Distance upped to 128m), it has been mostly event free. I do have to indicate though, that my Frame Rate and Ping times have never been as poor as they currently are. The Lag Meter is almost constanlty showing yellow and red LEDs. And this is unsustainable. It was not so long ago that when I walked my avatar around on most sims, the motion was smooth and realistic. (That was probably when I used the Windows viewer.) Now that motion is always chattery and laggy. I suppose that is partially due to the use of the "-set YieldTime 20" argument. The argument workaround will be the next one that I will target for removal. If I can't move around SL with some amount of motion fluidity, then I do not want to continue using the MacOS version of the viewer. We are in a testing phase so I will be patient. I will remove this one next to see if my freezes return.

With Draw=128, and VBO ON: after two hours of beachball-free and stall-free time, I did see one strange event. It was probably a one-off but I feel the need to report it. I called up the Map. [Aside: I always run the Map so that it covers the full SL scene, so I see nothing of what is happening ingame.] I am watching the Map's sims rezzing themselves, the regions are zoomed to full size. I begin dragging the contents of the Map around to as I usually do, while it is rezzing. I get a viewer beachball lockup and the need to Force Quit. I suppose what I was doing was exactly similar to moving my camera in a scene.

On logging out... If my session has been longer than about ninety minutes to two hours before I log out, the 1.20.RCs and now, 1.20.15.x never log me out cleanly. Sure, my desktop clears of any Second Life visual elements but it remains running — it is one of my running processes and it cannot be quit a second time. Here again, it is necessary to employ the Force Quit. I usually reboot the Mac as a precaution. My suspicion is that my client and the servers have had a communications problem and the logout function has not been completed successfully. Later, logging in again, I don't see any negatives with my character/account etc, and can conclude that the logoff WAS successful, but just not clean. So, instead, this causes me to think that a longer playing session is building corrupted junk in memory. A memory leak? The Console shows no memory leaks happening with Second Life unlike as with past viewers. Maybe some of the viewer code in RAM is being overwritten when my game is struggling with slow communications and graphics? This possibility could also explain fatal beachball events. Something is scrambling my Second Life viewer functionality. Could this be corruption of the client itself in memory? In a UNIX-based OS, this is not supposed to happen because software runs in protected memory. Or does it, when the client and SL may be misbehaving?

I am considering moving my cache to a different HDD, perhaps even to a RAMdrive. I understand running the cache in a RAMdrive significantly improves graphics performance. Up to now I have not found any RAMdrive software. However with the cache located on another HDD, work is shared and there should be less HD head thrashing and that should benefit performance.

7:02 logged back in to Meteora after a freeze. No one else in the sim. TPd to Morris
7:36 had to relog due to persistent freezes and excessive drive use
7:43 logged back in @ morris after 7 minute delay "region still loging you out"
7:57 Total lock up at morris requiring force quit.
then I don't recall any problems until I started freezing up again at 10:00 and logged out. I got sidetracked helping a friend look for land. We spent a long time talking, standing in an empty sim for sale. There were about 36 prims used out of 15,000. I noticed the freezes starting again after I returned to my place in Tikka.

I just went through one of Insky Jedburgh's castles (heavy texture use) and everything went to pieces: Drive running excessively, textures flashing and changing at random (VWR-1001), long freezes every few seconds. it was almost impossible to control my avatar. There was only me and one other person in the region.

The thing that is frustrating me most here is that every time I read someone else's posts on this they seem to be having a totally different experience. (thanks for the update Georgie <g>). I have been running the cache on a separate drive from the program almost from the start. I switched it back to my main hard drive for a short time when I started working on this problem. It seem to have no effect so I moved it back to the other drive.

Chipset Model: NVIDIA GeForce 8800 GT
Type: Display
Bus: PCIe
Slot: Slot-1
PCIe Lane Width: x16
VRAM (Total): 512 MB
Vendor: NVIDIA (0x10de)
Device ID: 0x0602
Revision ID: 0x00a2
ROM Revision: 3233

Second Life 1.20.15 (92456) Jul 21 2008 13:53:05 (Second Life Release)

Here is what i get (a kernal panic) about every hour or so, if not, as usual SL slows down to a studder and just locks up, forcing a force quit.

Thu Jul 24 09:03:49 2008
panic(cpu 3 caller 0x001431A9): "zalloc: \"kalloc.8192\" (31 elements) retry fail 3"@/SourceCache/xnu/xnu-1228.5.20/osfmk/kern/zalloc.c:770
Backtrace, Format - Frame : Return Address (4 potential args on stack)
0x7467fc88 : 0x12b0fa (0x4592a4 0x7467fcbc 0x133243 0x0)
0x7467fcd8 : 0x1431a9 (0x45aef0 0x459b38 0x1f 0x3)
0x7467fd38 : 0x12fa53 (0x2aec2d8 0x1 0x54 0x1a236f)
0x7467fd68 : 0x12fa72 (0x1690 0x1 0xbfe00000 0x0)
0x7467fd88 : 0x11d99f (0x1690 0xd0eb570 0x7467fda8 0x1a236f)
0x7467fdb8 : 0x12d0f6 (0x10f0 0x0 0x0 0x0)
0x7467fdf8 : 0x126257 (0xfa1fe00 0x0 0x54 0x7467fee4)
0x7467ff08 : 0x1973dd (0x7467ff44 0x0 0x0 0x0)
0x7467ffc8 : 0x19f3b3 (0xcb2c820 0x0 0x1a20b5 0xcb2c820)
No mapping exists for frame pointer
Backtrace terminated-invalid frame pointer 0xbfffce58

BSD process name corresponding to current thread: Second Life

Mac OS version:
9E17
Kernel v

total mind blower...haven't had a freeze up since. Logged in just after I made that last comment and just now logged out perfectly normal. Two long cruises through six different sandbox regions. spent time at waterhead, morris, miramare, OIP. HIP, then a long chat with friends back at my place in Tikka. Then back through the sandboxes and the infohubs. Not the slightest hint of any problem whatsoever.

Talk about stumbling into it. The first really radical move I made seems to have cleared everything right up. Now watch...everyone else here will try the same thing and it will crash them silly That seems to be how this thing works.

So I expanded it to 1000. w00t!!

But it always recovered and it never got close to the level I was seeing when my cache was set at 300. I never got to the point where I knew if I didn't relog I would crash. This is probably the biggest improvement I have seen so far in this problem but obviously the problem is still there.

So the 1000 cache didn't fix it. It just seems to hold it off a bit more...unless it was just the stuborn randomness of this thing striking again. This is really frustrating. We keep trying things that seem to work then fall apart.

(1) First thing this morning, I started the application and entered SL Preferences;
(2) Clear Cache, Quit and restart the application;
(3) Log in;
(4) Teleport somewhere, in this case, Torley's new sim, "Here"; (probably not part of the hang leadup)
(5) I took a copy of his texture set; (probably not part of the hang leadup)
(6) Then used the scroll wheel to zoom the camera back a fraction to take in a little bit more of the scene;
———>>> BOOM!!! Fatal beachball hang.

It is almost guaranteed that following a cache clean and a tiny amount of camera manipulation, I will hang. I have seen exactly this too many times now in the new client. In the RC series I never had a fatal hang under these same circumstances but entered a long session of cyclic pauses which I needed to quit out of anyway.

Apart from my abysmal frame rate, this is the next annoying part of Second Life. My recent experience will be repeated I expect: when I next log in, there will be no more hangs. Well, not unless I clear cache again.
---------------------------------------------------------------------------------------------------------------------------------------

Regarding my plans to restore from some of these workarounds, I am not so sure where to go. I would really like to have the exceptionally slow rezzing of a scene speed up a bit, and I strongly want to try removing the commandline argument to improve frame rate. But one thing at a time. Easy does it and one thing at a time.

This craziness was confined to that sim because I TPed out of it to another normally troublesome sim and it was free of these pauses. I am more than ever convinced that the sim, any sim, is at the root of my freezing. Or, looking at it another way, the TP entry to the sim, any sim, may be imperfect or incomplete and never properly receives the teleporting avie. A return again to Eventide North and everything worked perfectly where I was able to manipulate the camera all over the sim. This has been a very strange and informative experience. The following measure was taken unfortunately on the return visit to the sim when its operation was deemed okay:

Second Life 1.20.15 (92456) Jul 21 2008 13:53:05 (Second Life Release)
You are at 243617.5, 261040.4, 23.6 in Eventide North located at sim5646.agni.lindenlab.com (8.2.34.202:13002)
Second Life Server 1.23.4.93100
CPU: 8 x i386 (Unknown) (3200 MHz)
Memory: 16384 MB
OS Version: Darwin 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8800 GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.17067 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 553/647211 (0.1%)
----------------------------------------------------------------
While I am here, on this morning's travels I was reminded of something that is really beginning to peeve. I do not know whether my anti-pause workarounds are causing this. Everywhere I go there are avies, dozens of 'em, who barely rezz at all unless I move real close to them. The presense of some avies is evidenced by their prim hair and shoes being drawn; others show merely because their nametags are visible but even worse, some avies are totally invisible. How do I know that there is an invisible avie nearby? Occasionally, I use Advanced menu>Rendering>Info Displays>Avatar Rendering Cost. These numbers always display even on invisible avatars.

Whatever is causing these disappearing avies, I hope it is fixed soon. The absent avie form is now my chief annoyance as I seem to have come to an understanding about my rare hangs which is a personal rule never to clear my cache until absolutely necessary. Regarding cache, I have experimented with different cache sizes: it's currenly set to 1,000MB. Different sizes seem to make no difference to my experience. I would hesitate though, to set it to less than the default 500 because my hangs result from small and empty caches. On the other hand a large cache, to my way of thinking, is going to add lag because the client will need to search through a larger database to find what it wants.

First the similarities. I could only find one similarity. Cool Viewer throws out an immediate fatal hang almost immediately I have cleared cache, logged in, TP'd and started a camera move. There is something seriously wrong with both 1.19.1.4 and 1.20.15.x if they both hang the computer after a cache clean and an initial small camera excursion. Is there something about my hardware that is particularly sensitive in these circumstances?

Now to a brief look at Cool Viewer's comparitive performance. Absolutely superb campared to 1.20.15.x. I am touring SL as I write this coz I don't want to misrepresent anything. Accuracy is important.

After my initial hang and Force Quit I relogged at the same location and performed some camera moves. I was able to turn that store at Henmations inside out with my unconstrained camera moves. Absolutely no pausing, no lag, no avatar jitter when walking, the scene rezzes superfast. Everything is way faster.

I have set Draw at 128m, Disable Camera Constraints is enabled, VBO is ON, Texture mem is 512, Avatar Impostors and Hardware Skinning is ON, and all my other graphics settings have equality with my 1.20.15.x settings. And all avatars are rezzing fully in busy welcome areas. No-one is invisible. Frame rate does dip under 10 occasionally but it does not sit at 5 and 6 fps for hours at a time. My avatar walks around in a crowd, I work the camera, watch folks walk past without their moves being a slide show. S-M-O-O-T-H. Smooth and responsive. And no pausing!

The comparison reveals to me that 1.20.15.x was not ready for release. There is far too much wrong with the new version, as far as my Mac is concerned.

I will remain part of this Jira project but my enthusiasm is certainly being tested. I will test when new ideas need testing but my normal SL experience will not use the new viewer but instead the patched 1.19.1.4. Jeepers, who needs to boot Windows to enjoy Second Life when we have Cool Viewer for Mac? I wish some of the resident open-source patchers were part of the LL development crew because maybe Macs would get the quality service they deserve. I mean no affront to the Lindens — you do great work — but I suspect they could use some extra expertise.

• currently no improvement seen with all suggested workarounds (same iMac as before, nVidia 7600):

• draw distance 64m
• texture memory 112 out of 256 available
• AV impostors off
• VBO off
• line inserted in arguments.txt
• object-object occlusion off

Command tabbing does seem to be a factor. I normally command tab to Safari a lot (which is why I thought it was something to do with Safari itself), also to other apps including Photoshop.

However, the fatal freezes arise without command tabbing; sometimes a lot of hard disk sounds accompany the freeze, sometimes it starts with a bouncing icon in the dock warning me that the crash reporter was downloaded from the internet (sigh) and do I want to run it.

As well as freezes that are fatal for the SL viewer but allow it to be force quit and restarted, I also get fatal freezes for the whole machine, that require a hard restart. One instance of the latter today was when I had just uploaded an image.

In my case this has been going on throughout 1.19. I remember with clarity that the problems started on my machine when the 1.18 viewer version that was supposed to fix the MBPs was released.

Also 1.20.15 and 1.20.14 are worse than previous 1.20 RCs in that they occasionally cause various artifacts to appear in windows outside of the SL viewer - dotted lines across Safari windows, lines around windows, scrambled dock background, disappearing icon for Apple menu.

Still, the network keeps stalling periodically, in all sims, with few/many people, anytime of day/night. Any advice on what I should try next? (And no--I can't afford to buy Windows or a Windows machine.)

Second Life 1.20.15 (92456) Jul 21 2008 13:53:05 (Second Life Release)

You are at 188265.8, 248218.0, 26.6 in Henmations located at sim8026.agni.lindenlab.com (8.10.149.93:13002)
Second Life Server 1.23.4.93100

CPU: 8 x i386 (Unknown) (3200 MHz)
Memory: 16384 MB
OS Version: Darwin 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8800 GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.17088 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 35/58895 (0.1%)

All workaround guidelines except Draw Distance (still on 128) were followed. I don't bother varying Draw because it appears to have no effect on my (clean cache) hangs. Just in case AA is implicated, I no longer leave it set to 2x; it's disabled. And Texture mem remains at the default 50% of VRAM, 256/512.

I now run separate caches for whichever client I am using. I have to do this to avoid any complications when switching clients. But as I noted earlier, both 1.19.1.4 (patched) and 1.20.15.x do exactly the same post cache clean fatal hang. I guess the 1.20 hang is duplicated from 1.19 because LL was not aware of it in 1.19. And obviously, this seems to be a problem specific to my hardware.

I've set my SL preferences to highest and lowest settings, and done all kinds of imaginary hoodoo-voodoo that shouldn't make any difference, but worth a try anyways (logging on to areas with no AVs, logging onto areas with no megaprims, removing all clothing and attachments, etc.). I've deleted all SL prefs in my library (clean re-install), and just about everything I could think of.

The crashes are non-reproducible and happen at completely unexpected times, in a nutshell;
1. Launch SL.
2. Crash (either immediately, or eventually).

Often, someone will have a suggestion that I'd try (i.e. enable port in prefs but don't change port) and I'll log in and think "Woah, that must have worked!" only to be disappointed by a random freeze later.

The freezes seem to be more prolific during peak hours, if that makes any sense. I seem to experience less of them after midnight East Coast time. Freezes can happen at any point using SL, before log in (as the splash screen loads), during the log-in progress bar, immediately upon spawning in-world, or any time after that - whether I move around or am simply sitting and looking out at nothing but water and sky.

Lately, the hoodoo-voodoo that seems to work for me (unless I'm fooled again by misleading successful sessions), is to log in at my HOME location. That seems to work once I get in-world, but still the pre-login crashes plague periodically.

It's strange that sometimes the client runs fine for hours-and-hours-long sessions, while you can do all sorts of complex work in world. Log back in a few hours later and crash-city. Don't change a single thing and for some reason it behaves again. Next day - crash city again.

Before I joined SL, I was so proud of how long my machine would be up continuously without requiring a restart. Sometimes weeks on end without needing to reboot. Since SL, I have to FORCE reboot literally DOZENS of times daily. Hardcore OS crashes outside of Apple's protected memory scheme can wreak havoc on important system files! I know Windows users are used to doing complete re-installs of their OS every time one of their e-mails farts, but for Mac users, the only reason for completely reinstalling our OS should be under very extreme circumstances only. If SL is capable of creating such an "extreme circumstance" for a measurable percentage of users, it should be considered a showstopper, ...well, for Mac users anyways.

Another observation: Whenever I click any other alias on my desktop, you see the icon's "opening" animation (ghosted icon 'blooms' to show the app is being launched), but often times, the SL icon doesn't "bloom" and I wonder if my doubleclick took effect, until I see the program's screen appear. This might be during times when CrashReporter launches - not sure, I'll have to watch, but if others can confirm this, it might be a problem in the initialization process (he sez as if he knows wtf he's talking about).

right now (after a couple of hours logged in):

Real Memory: 685 MB
Virtual Memory: 2.25 GB
... and rising

I have pretty much every suggestion in place and I have just left it all alone for a while to see if I can spot a pattern of behavior. What I think i am seeing (not so sure about anything any more <g>) is that things get progressively worse when I stay in one place for a while. I did this at the Memory Bazaar/Ross infohub earlier today. everything was smooth when I first arrived, though many textures were very slow to load.

But the longer I stayed there the worse things got. As someone mentioned in a previous comment, it is like a slide show more than a movie. if I turn 360 degrees I see 10 to 15 still frames. The hard drive runs excessively. often one texture on the floor or walls will start cycling through various textures I have seen recently. It will flash black for a second, then be someone's skin for a second, then turn into a tree texture for a second, then black again, etc. I am also running into the same problem someone mentioned that avatars don't rez. It is like they are wearing an invisiprim. I see nothing but their name and a pair of shoes (usually with bling).

If I teleport back home there is a short rough period as things rez then I can turn 360 and see it as a smooth sweep. My home place is a skybox well above 1000 meters. I don't seem to have too much prob there. but I also have a place on the ground and I am having the same difficulties there. the longer I stay there the worse my performance gets.

I think the staying in one place is what has been throwing me off. When I make a change to a setting, I go in and give it a good test run, hitting all my usual haunts but focusing more on watching how things are running and not staying long in one place. So everything runs fine. Then I go back in and start doing the things I usually do, spending much more time in each place and everything goes to pieces again.

the worst place lately has been waterhead. It doesn't just freeze up there every time, it sometimes simply shuts down the second life viewer. Then if I log back in to the same place it just keeps shutting it down within just a couple minutes.

I have found this is something I can consistantly reproduce...stay in one place, particularly a place with prolific texturing, and the freezing starts. teleport back home and it smooths out again.

There is something strange about all that. Why would that frame rate drop to a third of its former value and stay there? Just because I did a 360? It makes no sense. I did some more 360s later but the frame rate stayed on 5fps.

BTW, I have all the recommended fixes still applied and also VBO off.

And I still have that obligatory fatal hang soon after logging in with a clean cache. I wish my lottery tickets were as dependable. I can't get the idea out of my mind that cache management generally is seriously buggy.

I ask myself: what are SLers hoping to achieve in this particular issue? Well, I am totally clueless around how an application might work, it's structure, or anything. I mean, I watch the Activity Monitor during my events but have no idea what indications to look for. The reason we have the Release Candidate cycle is because LL does not have the resources to proof and troubleshoot its own changes. That's the job for willing users. Now I have to ask what I am trying to do with my obligatory fatal beach ball hang after every cache purge. I wish I knew. I feel I have to do more because it appears that the issue may only affect some hardware types, not all Macs. That means it may never be fixed unless I can give LL a direction to follow. But I can't. It's so frustrating.

So I go in a slightly different direction. I want to connect the dots if possible. Having a very powerful Mac, I should have a far better frame rate when using 1.20.15. It is galling to be discussing these issues with other MacSLers to learn that they are having a rock solid run from this new client. Or are those users a bit noobish and 5-10fps plus some minor pausing is okay by them??? I must say that we all should be expecting 20fps+ from SL. 15-20fps is the threshold where smooth motion graphics begin to replace slide shows. Maybe nearly all Mac users are happy with slide shows instead of movies when they move the avatar or observe the passing parade.

It is amazing that when I log in or TP to a new simulator, I have a high frame rate on the Mac Pro, sometimes as high as 40-50fps. That quickly falls as my grey world view rezzes its objects. But I still end up with an initial 15-20fps after the scene fully rezzes. As to why the frame rate progressively falls over time after that short period, with all else being equal...??? Yes, move around in a confined location such as a store with few or no other avatars present on the sim, you would expect the experience to remain static and whatever the conditions are present to cause a certain work load on the sim and the client, they should continue without change. Frame rate should be static. Is it time spent in the sim or the avatar's movement in the sim that degrades frame rate over time? It seems to be a bit of both.

Yesterday's comment of mine re the Athen Shire experiment, shows me that frame rate is not necessarily entirely dependent on the Mac's grunt or lack thereof. There is some other seemingly illogical factor. Is there still a problem with memory leaks? I used to read of memory leaks in Console messages, seven of them every time I started the SL client. Those messages no longer appear. Is there a different sort of memory leak? Why does the client's real and virtual memory grow over time? Isn't this the job of the HDD cache? I am beginning to think that perhaps memory is accumulating garbage which impedes efficient running of the client. Of course I am just fishing here. I have no idea.

Running this client troubleshooting exercise, where the heck do I go next? It all comes in little bits of experience. I don't know how to connect the dots.

Rereading this contribution has prompted a thought. I use the 30" Cinema with SL running in a window of almost 2560x1600 or around 4.2 million pixels. What if this Mac is troubled with such high graphics numbers when running Second Life? I suspect that only a few Mac owners are using these monitors. I will run my world in 1920x1200 and see if there is any detectable improvement. Frame rate should definitely improve. One thing that bothers me with 2560x1600 is that the login screen is totally black and only starts showing LL's login information and graphic at sizes ≦ 1920x1200 pixels. There is a Jira on this matter.

BTW, running in a smaller window has made a tiny improvement to my frame rate but generally not helped with overall experience. Again, after my avatar did a 360, frame rate dropped and stayed low. 2560x1600 pixels restored.

I'm having terrible freeze issues. I have 3,642 inventory items (yes, that few) and am on a brand new sim with almost no build on it at all. Script perf is in the 1,400 (that is correct it is that low). I have tried three different networks by three different providers in three very different locations 27 miles apart from one and other.

My usual FPS is between 42 to 54. Ping rate is usually between 24 to 107. Until I start to chat. Or pull up an interface window. Or transport. Then the ping rate spikes to astronomical numbers: 10,000 to 18,400. NO KIDDING. After that, my FPS drop to ridiculously low numbers: .3 was the lowest, often 1.4 to 4. Needless to say I freeze a LOT.

I've been watching this pattern for a week now, always the same.

I have tried every darn thing I see on these pages and I am a member of MaCusers in world and have tried their recommendations as well. In desperation I uninstalled the new SL viewer and went back to 1.19.1 (4). It has helped a tiny, tiny bit, but the probs are growing worse again.

The only thing I have to try (which since the computer is less than 60 days old, I should not have to do) is replace the graphics card driver. Why? because when I go to the Nvidia site, they don't even list Macs in their set of available upgrades and downloads. I can't figure out which one to get.

Model Name: MacBook Pro
Model Identifier: MacBookPro4,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.6 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 6 MB
Memory: 4 GB
Bus Speed: 800 MHz
Boot ROM Version: MBP41.00C1.B03
SMC Version: 1.27f1

Chipset Model: GeForce 8600M GT
Type: Display
Bus: PCIe
PCIe Lane Width: x16
VRAM (Total): 512 MB
Vendor: NVIDIA (0x10de)
Device ID: 0x0407
Revision ID: 0x00a1
ROM Revision: 3212
Displays:
Color LCD:
Display Type: LCD
Resolution: 1440 x 900
Depth: 32-bit Color
Built-In: Yes
Core Image: Hardware Accelerated
Main Display: Yes
Mirror: Off
Online: Yes
Quartz Extreme: Supported

Yes, I have discovered a simple workaround which makes all other proposed workarounds mentioned here, unnecessary. I am speaking of my own problem and not of others reported here.

My own problem is this one about a cleared cache and the instability which follows at next login. Both my Mac Pro3,1 and my MacBook Pro3,1 now have all the desired settings in Graphics and Advanced menu restored because none of those worked for me. Even the argument inside the application has been found unnecessary. I saw exactly the same cleared cache instability on the MBP as well as on the MP.

Restating... If I clear cache and log in, the next session will be very unstable and will always result a fatal hang with a force quit to follow. The aspect of that which had not been explored was "did I need to persist with that unstable session?" The answer is no.

So my workaround after clearing cache is login, maybe wait for some rezzing to occur, then relog. A perfectly smooth session will follow if one's problem relates to a cleared cache.

There remains

(1) the poor frame rate and choppy motion, and
(2) the missing mesh detail on many avatars until the camera gets near to them and sometimes not even then.

Neither of (1) and (2) appear to be related to the issues in this project but remain as bugs in this viewer.

Concluding, my relog workaround is effective on both of my Macs and all my preferences have been re-enabled. I have never seen any of the other instabilities reported here by other contributors. I assume that I won't have anything more to add here in VWR-7779 but I will remain interested because I would like LL to overcome this need to relog, this strange behavior of the cache manager. And I sure do expect to see a better frame rate soon like in the old days. Are sims too crowded, too busy? I am sure they are. Even with no avatars present, many are too busy.

I am trying to find out what is causing this cycle, but alas the Stats Bar is fairly new to me as well as sim performance issues... so my learning curve is high!

The Time Dilation appears to be what is causing what I once though was a Viewer issue (laggy viewer). Even if I bump my graphics settings up and draw distance, etc... I am only noticing the relationship between the dilation and my avatar's stability in-world.

No more beach balls and app lock-ups for me it seems, no more Force Quits. Although the Time Dilation cycle thing has me freaked out. Not sure If I need to open a support ticket for this issue. Region: Vulcania

Mahalo to everyone for the great participation in regards to the Mac/View Performance issue

~Sahoni T.

Maybe I could achieve the rates you spoke of Chris2, but I would have to disable a lot of stuff in Graphics preference settings. I am not happy to do that. Maybe I should, but that would ruin the visual experience. Is that how you do it, Chris2? Compromise on the appearance of Second Life? Maybe my 30" screen is the real culprit here. I imagine most anyone could get 40-50fps if only running a 1024x768 (or 1280x1024) window (if that is what you do) but that's not my style.

I guess pretty pictures equals slow frame rates.

When I run the Windows version of the browser, I do indeed see those sort of frame rates but I don't want to run Windows.

Currently, in both both versions of 1.19.1.4, and 1.20.15.x, I get this bad instability when I relog after a cache clean. I have described here the way this happens and my workaround so it should be very easy for LL to drill down to the root cause and fix it in the next viewer update. My hopes are not high because there does not appear to be a lot of dev resources being thrown at the MacOSX version of the viewer. Am I the only one seeing this clear association with cache clearing and instability on both 1.19.1.4 and 1.20.15.x, and on a Mac Pro and a MacBook Pro?

BTW, I no longer have pauses and freezing. I do see them in the first relog after the cache clean, but if I log out and in again my instability ends. I see this odd instability on a MBP and two different Mac Pros, so it is likely to be quite common on other folk's Macs. My Macs are all Intel Macs running OS10.5.4 and all have nVidia GPUs.

CPU: Dual i386 (Unknown) (3600 MHz)
Memory: 4096 MB
OS Version: Darwin 9.2.2 Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 i386
Graphics Card: NVIDIA GeForce 8800 GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.26

The workaround listed in the release notes hasn't had any noticeable effect for me (YieldTime 20).

I have been experiencing freezes ever since RC 10 and the current release is not immune. It is comforting to know that Linden Lab is aware of the problem and I have tried every workaround suggested by Ramzi, to no avail. None of the suggested tweaks seems to improve the user experience, alone or in any number of combinations. Freezes may occur immediately upon login, after ten minutes, after 30 minutes or, and that is more ironic, after hours of pristine operation just before I logout. It is one of those cases when you seem to be dealing with a bug with a mind of its own .

However, I have noticed the following which might help further investigation:

1. When a freeze occurs, my partner and my friends see me disappear from view and from their contact list for the entire duration of the freeze. Like some other posters here, I believe one or more SL servers boot Mac users off temporarily, which may cause the Mac to hang (the whole operating system comes to a halt).

2. If I am in a location where scripted objects are present, I freeze more frequently. I don't think this is unrelated.

3. I have bought a high-end iMac with all the extras (specs below) but the freeze problem occurred in the 2006 iMac I had before, with a different brand card (it was an ATI card) and with a different Mac OS X. Perhaps I am saying something silly, but if I switched off Atmospheric Shaders, freezes disappeared altogether. With the current Mac and the nVidia card, they do not. Therefore, I believe that Windlight may be responsible in part for the problems we are experiencing, as it has always worked on PCs better than on Macs.

I am not a geek (no offense intended, I admire all geeks and actually I think they are sexy ) but I am a long-time Mac user (since 1991) and most of the time, a software problem on a Mac is due to an application that does not comply to Apple's GUI guidelines, what we call a Windows port. SL is a Windows port for me (think of the menus, we Mac users have to use the SL menus inside the browser window instead of the Finder menu bar; this alone makes SL a Windows port). I am pretty sure that a great deal of problems would disappear if LL started to work more closely with Apple, Inc. and rewrite the browser code to make it Mac OS-compliant. But I am afraid this is unlikely to happen.

Second Life 1.20.15 (92456) Jul 21 2008 13:53:05 (Second Life Release)

CPU: Dual i386 (Unknown) (3060 MHz)
Memory: 4096 MB
OS Version: Darwin 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8800 GS OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.17408 (Mozilla GRE version 1.8.1.13_0000000000)

1 From the View Menu, select Hover Tips and the Show Tips submenu.
2. If Show Tips is checked, uncheck it.

Hover Tips calls for a brief balloon description of everything your mouse cursor comes in contact with, and I have the feeling that in a few cases this feature waits for a response from the server and loops, causing a freeze.

As a matter of fact, the same scripted objects that caused the Mac to freeze and force restart have ceased to be a problem.

Sandor

I always enable "Tips On All Objects". You've hit on the problem I think, well my problem anyway.

I still have other problems like a miserable frame rate. Let's see how that is affected with tips off.

Now I don't know what to do... Turn off Hover tips permanently and that is something I rely on a lot.

Or, stick with my usual immediate logoff after I clear cache. I wil probably stay with the second workaround as I don't freeze if I clear cache, login, and then quickly relog.

I would like to keep my Hover Tips ON.

In both cases this sounds like a server problem.

[EDIT]
As a matter of fact, I only need tips off immediately after my login following a cache purge. After a few minutes I can re-enable hover tips on all objects. WOW! I don't need my relog trick. No more freezes!

It is very promising to hear that my workaround solves your problem.

Now, if we could get feedback from other users experiencing freezes, this would help LL investigate the problem in another direction.

So far, LL has put the blame on some mysterious incompatibility between some nVidia cards and SL graphics engine, but all our findings increasingly appear to detect a server-Mac client problem which is totally unrelated to our graphics cards' performance while running SL client, which is buggy in more ways than one on the Mac anyway (one only has to read the release notes to be aware of this).

It is the same old story: whenever a Mac user has a problem, it is dismissed as a Mac hardware issue or Mac OS fault on the onset with the implied wish that we switched to Microsoft Windows. It takes time to work around this prejudice and be proven right when we say the problem lies somewhere else.

Fortunately, we Mac users are very stubborn, very intuitive and very vocal with Linden Lab, besides having an operating system that has always been years ahead of the competition and is more sensitive to Windows ports like the SL client.

For the time being, I am patting myself on the back. And I am glad I helped you, Georgie.

Sandor

Any glimmers of relief, dear Lindens? Ramzi?

I do not mean to exclude other possibilities for the problem you are experiencing but it looks more like a REAL network connection problem that could be dealt with by opening a support ticket, which is something you can do because you are using a final release. Just a suggestion.

Sandor

Overall my situation seemed to improve with a new monitor. But the issues were clearly still there. One of the main problems is the cyclic mini-freezes. At times my avatar looks like it is limping with a slight freeze up on each step. the freeze is at a different point in the animation each time so it isn't the walk animation doing it.

Among other things, I also have had occasional failures filing abuse reports. Instead of the standard auto-reply that they had received my report, I would get messages that they could not find a valid user and they could not create a new user for my e-mail address. For several days the frequency of these shot way up. at least one in three reports were failing to get through.

I opened a support request on that. I decided to run in a window for a day to see the emails as they came in, to see if I could spot a pattern. There were absolutely no abuse report failures the entire day. So I suspected this might have some relation to the full screen mode.

I got a prompt reply from the support asking me to gather information from my computer including a log file. I felt it would be better to have a log file in full screen since the problem had vanished in window mode. So I ran full screen for several hours cruising sandboxes looking for problems to report...and I didn't have a single report failure...so much for my idea about full screen mode. I haven't had a single failure since. I gave support all the info they requested and they said there is absolutely no problem at my end.

However, I still get occasional indications that I have lost connection with SL. I will be having an IM conversation with someone and one message from them, right out of the middle of the conversation, will fail to come through. Instead it is sent to my e-mail as if I am off line.

The program has also suddenly quit on me several times since I have been running in a window. It was so abrupt that I wondered if I had somehow managed to hit ctrl-Q while typing. This evening I have been getting sudden lock ups that last for about five to ten seconds then recover. I went into the OSgrid yesterday and earlier today with a copy of the SL client and it somehow reset all my preferences and advanced menu settings back to the defaults. So now i am digging through all the settings trying to find my way back to what I had. but the lockups didn't start immediately after that so I have no idea what is causing them.

I did try the tool tips suggestion...it didn't change anything for me. I really wish I could give the programmers something more solid to work with. But this is really starting to seem totally random. I'm not even certain any of these issues are related in any way.

Now...Is it possible to be semi-crashed in SL? With no particular trigger at my end I find I cannot move from the spot I am standing on but I can turn 360s until the cows come home. And I still, IIRC, have some interaction with menus but cannot TP. Friends I am with at the time say my avatar has disappeared from the scene and the blue Friends on Line notification, bottom right, says I logged off. Not true, I am still there and I can see other avatars moving around. My friend simply says that I crashed, get over it and relog. LOL. Clearly, the client has lost contact with Second Life, but only partially. Amazingly, in all this I can still talk using Voice as if there was nothing wrong. Yes true, Voice is handled on separate servers to those running the rest of SL.

This used to happen a lot with older versions of the client. It still happens to me with 1.20.x but is now quite rare.

I am hoping that server 1.24.x will start to tackle some of these server<—>client failures, but I won't be holding my breath.

However I do have one major issue with TPing. Accuracy. I have two locations which I TP to several times per session.

Location A: I may be deposited anywhere within 100 metres of the where the LM is pointing to. I often have to reuse the LM up to four or five times before finally arriving at the LM's specified landing point. Those intervening landings might spot me at many strange places on the sim. The LM is one provided by the owner of the shop.

Location B: I always land at the correct horizontal coordinates, but often when I move, I'll fall through the floor. The only solution I have found is to TP out of there and try another TP to Location B when hopefully I will land on the floor and not slightly sunk into it. Perhaps the solution with this one is to fly first before TPing.

In both cases, I feel the sim is not handling TPs correctly.

So that is one issue out of the way...hopefully

It appears after a few days of testing that disabling tool tips reduces freezes at my end, but does not get rid of them.

I have also tried disabling the Output Debug Minidump option (which probably creates a log of problems when they are found while allowing continued operation of the viewer) and although it might deprive me and LL of some additional information in case of a crash, it DOES cause the freezing to disappear in the situations I have tested personally (walking with textured and scripted objects in the camera frame's foreground).

So perhaps we might have found YET another cause of this problem!!

For the sake of clarity, the Output Debug Minidump option is enabled by default in the current version of the browser.

To recap, at the moment the following workarounds seem to solve the problem for me, pending further testing on an iMac 2008 with a nVidia GForce 8800 GS card:

1. set graphics preferences to Mid but add water reflections (all avatars and objects) and 2x anti-aliasing. Leave the rest unchanged.
2. disable tool tips.
3. disable Output Debug Minidump.

I would like to thank Cotytto for his investigation.

As for the "stuck but able to communicate" problem, this is quite an old occurrence and it has nothing to do with the browser. It is a server problem. Perhaps not everyone knows that we are connected to several servers, and if one of them fails on us, the other ones might continue to be operational. Therefore, you might be unable to walk but able to talk and maybe text chat for a while but if you linger, each of the remaining servers will shut you down until you crash.

Sandor

I am a habitual sender of crash reports. Whenever my browser falls over (rare) or when it's necessary to do a Forced Quit (very often) I like to send a crash report with my own detailed comments about whatever I was doing at the time. Apart from my own comments, the browser sends the contents of one or more logs: SecondLife.log, debug_info.log, SecondLifeCrashReport.log. When a crash report is sent, it is my bet that the last two named (or perhaps all) are sent to Linden Lab along with any personal comments that might be added.

If "Output Debug Minidump" is disabled, I suspect that sending a crash report is no longer of any value because the logs were not updated to represent the latest client failure. I have therefore reenabled this menu choice. I have never noticed any negatives from leaving this option enabled, so I restore it to its default setting.

It bears repeating: Turning off Hover Tips in my setting gives temporary relief from heavy freezing immediately AFTER I clear cache. Once I get over that hump, Hover Tips can be reenabled, and my following experience is almost pause free.

So yes, I would like to see this server<->client issue fixed and that is a reason to remain involved here in VWR-7779. My freezes after clearing cache is the one and only reason I created this issue. It does seem to get sidetracked on some occasions and that is partly my fault. My issue has now become well defined and with the contributions of you guys, we are much closer to trapping the problem and getting LL to fix it. Or maybe it is just too hard for them. Thank you from the bottom of my heart for assisting me to tie down the cause of my freezes. It appears that some of you may well have exactly the same cause and I would like to read of your experiences following a freshly cleared cache.

Hugs and kisses,
Georgie

But overall my performance the past couple days has been horrid. Much of the time I am frozen more often than moving. I am not sure of anything any more, but my current thinking is that this has been happening since I started running in a window again. I even took the -purge out of the arguments.txt and relogged twice after the last cache clear...didn't help. The only plus side is that I now seem to recover from the really long freezes. In full screen mode, if I froze over 5 seconds it was usually permanent.

So I have turned the Debug Minidumps back on, because I also want to provide as much info as I possibly can on the crashes. I have also switched my crash report preference to always send.

Darnit...I was really enjoying the convenience of running in a window...but I think I'm going to test some in full screen today to see if this overwhelming freezing problem settles down.

I was experiencing constant freezes, crashes, graphics glitches, SL taking down my entire OS, SL mysteriously restarting my machine, etc. I'd read about all the mysterious hoodoo-voodoo tricks that shouldn't effect the problem, but people say do. I tried everything. I'd log in at different areas, I'd take off all clothes and attachments, etc.

SL was the ONLY program on my (professional-use) computer that I experienced any problems with.

I started uninstalling all utility programs on my machine (SnapzPro, Butler, etc) degrading functionality considerably in exchange for the hope of a performance improvement. At times it would seem better, and then the very next day - more problems.

I monitored memory usage, bandwidth, and connectivity. I did all the diagnostics, from repairing disk and disk permissions, and running hardware diagnostics looping for days on end with no reports of anything wrong.

Things got exponentially worse as time went by. Eventually I couldn't get SL to run for more than 2 minutes without crashing hard. Sometimes it failed to launch. Sometimes it would run for a while and crash for no reason, and other times it ran all night with no problems. I was confused about how it could be completely useless one day, and, without changing a single thing, it would run fine the next day. I figured it HAD to be a problem server-side, and not my machine.

Finally, I had to "retire" my brand new computer and pull an old one out of the closet. The old one had no problems, except it wasn't powerful enough to get over 1 FPS.

I took the computer to the shop, and they told me the graphics processor was fried, and since it's attached to the logic board, it was a monster cost to repair. Luckily, Apple is one of the only companies in the world these days that actually CARES about the user experience - they helped me out with the repairs so that it didn't leave me in the poor-house. YAY APPLE!!!

So far so good. SL is running somewhat reliably now with few graphics glitches, crashes, freeze-ups, etc. (well, so far, anyway). I don't know if my graphics processor slowly died on its own, if I had a faulty one that didn't show any symptoms until the warranty was up, if there was some cumulative effect suffered through the use of SL, or what. No idea. All I know is it's a darn expensive fix. One of those "might as well get a new computer for what it costs" repairs.

If you're experiencing lots of strange, non-reproducible bugs, crashes, freezes, etc. it might be in your best interest to take it to an authorized Apple repair center, and cross your fingers in hopes that you don't need to buy a whole new computer just to run SL reliably.

Oh, one strange after-effect to all this...

Now whenever I quit SL, I get a dialog that says "Second Life has unexpectedly quit..." I guess it's surprised that it actually managed to quit, and didn't crash hard like it's been used to doing. Haha.

I'm sure if I rebuild all preferences and application settings in Library, that dialog will probably go away. But it amuses me for now.

If you guys need a good Macintosh QA person, you can pass me over. Apparently my 20+ years of Mac tech experience, development, and beta-testing are of no help here.

I employed heaps of my evolved workarounds, turned off a heap of graphics and Advanced menu settings, varied a lot of settings. Oh boy! I would land at say Dore's landing point and find myself in a crowd of grey folks all seeming to suffer the same problems I had. I could not move any which way. My avatar would not finish rezzing including my HUD objects. Being immobile, I relogged. Back again, I had exactly the same experience. More relogs, moved elswhere. Stand for a few minutes at Waterhead, immobile coz I was considering my options.... clunk: Hard fatal hang with power-off to restart. I have not needed one of those power down recoveries for a long time but now these are back. Time and time again I saw the bottom LED of the lag meter (sim server slowdowns) go to red. So many freezes, so many Forced Quits. With nothing at my end done to make matters worse, this was Second Life at its worst. Not of my doing, this was the servers being absolutely cruel to residents. What kind of pleasant social experience is this that Second Life has become?

In my movements between sims I frequently saw the yellow dialog saying I had gone to a different server. I am convinced moving between sims using different servers is not being handled well by LL and is the cause of problems for a lot of people. Sheesh! Get us all on one server version!!! The current dog's breakfast is doing no-one any favours.

Yesterday's was the worst couple of hours in SL I have ever experienced. And not a word in the blogs.

Hardware Overview:

Machine Name: iMac
Machine Model: PowerMac6,1
CPU Type: PowerPC G4 (3.3)
Number Of CPUs: 1
CPU Speed: 1.25 GHz
L2 Cache (per CPU): 256 KB
Memory: 768 MB
Bus Speed: 167 MHz
Boot ROM Version: 4.6.8f4
Serial Number: W833584RPJH

GeForce FX 5200:

Chipset Model: GeForce FX 5200
Type: Display
Bus: AGP
VRAM (Total): 64 MB
Vendor: nVIDIA (0x10de)
Device ID: 0x0329
Revision ID: 0x00a2
ROM Revision: 2068

My computer meets the following min. requirements: Cable or DSL
Operating System: Mac OS X 10.4.11 or better
Computer Processor 1.25 GHz G4 or better
Computer Memory: 512 MB or more
Screen Resolution: 1024x768 pixels 1024x768 pixels or higher
Graphics Card**:
ATI Radeon 9200 and above
OR ATI Radeon X Series
OR NVIDIA GeForce 2, GeForce 4
OR NVIDIA GeForce 5000 Series and above

these min requirements do not seem to be enough to run SL effectively any more.

SL seems to tax the CPU/memory resources to much.

If this Mac is only used on a casual basis for SL and you are not too serious with it .... er, then methinks the best thing you could do for that Mac is at least double that RAM, even triple it. That clock speed is way slow, however. Otherwise, with no improvements.... SL won't ever be very enjoyable. However, I hesitate recommending any hardware improvements to your current Mac...........

..........Be careful of spending too much money on a computer that for SL, ought to be replaced. Upgrade costs might be better spent by putting the money towards say, a new iMac. The iMac looks to be the best bang for the buck choice. The Intel Macs are all far better for SL than those still using the PPC CPUs. I would caution you against an Intel MacBook or Intel MacMini though because they use shared RAM for VRAM and hence are a bit too sluggish. It does come down to what you are prepared to spend. And basically you get the grunt you are prepared to pay for.

Georgie, I am pretty sure the problems you experienced on August 25 (I believe that by "yesterday" you meant August 25) were due to the deployment of the new server code including Mono. If you go to the Grid Status Report of August 25 at 5:11 PM PDT (a few minutes after your post) you will notice that LL admits there have been a few crashes after this deployment. It is not the first time it happens, but they continue to implement codes which have been tested on the beta grid with no apparent problems only to find they are buggy when released to the public grid. And they also look surprised....DUH! I am really beginning to agree with those who say that SL has been beta since its inception.

Although I am quite happy I bought a new iMac, I suggest Rascal waits before spending between $1,200 and $2,200 US (or more if outside the US) to purchase a new iMac which would work miserably with SL. I have the highest-end model and I am pretty put off by the random problems generated by SL, which WORKED on my previous iMac (similar to Rascal's) before the client was "updated" to version 1.19. After the introduction of Windlight, hell broke loose.

Rascal, if you can live without Windlight, I would suggest you try the alternative browser called OnRez. Perhaps it would allow you a better experience in spite of the fewer bells and whistles until we DO have a stable official browser and LL stops using us as guinea pigs for their code deployments. Basic subscribers would not mind the crashes but premium subscribers and those who pay tier fees DO!

Sandor

It is so good to hear others with the same problems (if you know what I mean, hehe). One thing not mentioned here so far that I have experienced is a cache out of all proportion to what I've been doing. I can't pin it down to any one activity and it happens even when I haven't been in a texture-heavy environment or editing. It happens only rarely, but when it does I seem to crash pretty soon after logging on and my cache has well over 100 items in it. For only a few minutes in-world it's usually 10-15.

I have tried all the workarounds suggested without much success - except enabling cam restraints SEEMS to make things a little more stable (boo hoo). I was also a serial cache-clearer but have stopped doing it every time I quit after what I read here.

Sandor, I used OnRez and found the problems were SOMEWHAT fewer but I lost the ability to build above 768, and the improvement was so slight it hardly seemed worth it. The best solution I have found is the Cool SL Viewer: http://radio-boomslang.shacknet.nu/~bb/articles/cool-viewer-mac/ . It's based on 1.19.4 (there's a link to that version on the site). Old-style interface, which suits me fine, and, best of all, as far as I'm concerned, I can build all the way up to 4096. Some problems still - but hey who hasn't, irrespective of OS and computer? The freeze problem and the hang on quitting have almost disappeared. I'm going to disable cam restraints today and see how that works in Cool SL.

For what it's worth - and I don't think anyone has mentioned this yet - but apologies if you have - I turn my particles down to 2560. Oh and I always run in a window. Back in my early days when you could still talk to a Linden on Live Help I was told that Macs were better off running SL in a window.

I bought a new iMac in May. There was nothing wrong with my pre-Intel Mac, except my graphics card was below min spec for SL and I had only 64Mb of VRAM. Pretty galling to spend £1500 (about 3K USD) to find my SL experience was getting progressively worse. I hate Win DO'Hs and really don't want to run it but was seriously considering buying a cheap PC just for SL rather than sullying my iMac. Cool SL Viewer has saved my sanity (and is virtually fat-free LOL).

Question: If non-Lindens can patch the client so successfully - why can't LL? And why can't they build a proper Mac client from the ground up? Mac users are on the increase since the introduction of the Intel Mac. We're here to stay, guys, just like left-handers (of which I am also one).

Here are my specs:

Mac OSX (10.5.4)
Model Name: iMac
Model Identifier: iMac8,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.8 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 6 MB
Memory: 2 GB
Bus Speed: 1.07 GHz

NVIDIA GeForce 8800 GS:

Chipset Model: NVIDIA GeForce 8800 GS
Type: Display
Bus: PCIe
PCIe Lane Width: x16
VRAM (Total): 512 MB
Vendor: NVIDIA (0x10de)
Device ID: 0x0609
Revision ID: 0x00a2
ROM Revision: 3234

Displays:
iMac:
Display Type: LCD
Resolution: 1920 x 1200
Depth: 32-bit Color
Built-In: Yes
Core Image: Hardware Accelerated
Main Display: Yes
Mirror: Off
Online: Yes
Quartz Extreme: Supported

Hey Sandor. I agree.

Yep, after the last day or two with three different versions of the region servers floating around and the resulting mayhem, it seems to me that my long held view that sim server software was/is at the root of much of a Mac's SL troubles. What seems really troubling is that new modification to the servers is being done without fixing any of the long term region bugs. I would really really like LL to call a halt to server "improvements" and concentrate on the bugs. And some ways must be found to extend server compatibility beyond Windows/Linux, and make the software compatible with the Mac. Requiring Mac users to disable sections of their client is not the answer, except as a temporary troubleshooting test.

I sincerely ask a responsible Linden to come on here and explain LL's unwillingness to improve our experience. I feel we are just being strung along on a suggestion that things ARE being investigated. But we never see any fruits of this. Apart from Ramzi a while back, no-one talks to us. I guess LL has nothing to say.

Perhaps it would be better if MacOSX support is abandoned and Mac users all install Bootcamp/Windows. That could mean LL would not need to flounder around, bereft of MacOSX/Unix expertise, and concentrate all resources on Windows and Linux. Cynical tongue-in-cheak comment there but some kind of drastic attitude change is needed.

Happy Ess-Elling! (if you can ignore the frustrations)

Georgie G

What I am seeing - very frequently, in connection with the freezes - is a "NVChannel(GL): Graphics channel timeout!" error message in my macbook pro's system.log. Which does slightly incline me to believe the issue may relate to apple's half-assed nvidia graphic drivers, rather than anything on the LL side of things Do other people get this error message during freezes, or is it only me? Perhaps it would be useful to establish if this is the case.

For what it's worth, my problem is definitely related to another avatar being within sight. For example, I spent 3 or 4 hours working in my skybox a few days ago, without a single freeze. I then invited a friend over to chat, and within minutes of her arrival, I was getting a freeze every few minutes. At first, I wondered if it might be something to do with the tinyprims she had attached as jewellery, so asked if she could remove them ... the crashes still persisted. By this point, she was using a very plain avatar - the only attachment remaining was her hair. Sadly, she was reluctant to remove that, even in the name of science!

I did notice that a few of the crashes co-incided with her (not me) sitting down on an object ... insofar as I'd see the particle stream projecting from her hand towards an object, then I'd freeze - apparently at the very moment that she sat down (I didn't see the sit action on my screen, my display would be frozen at the point where she hit the sit command on her pie menu). Again, this may be co-incidental, but it's not the first time that I've noticed that my freeze seems to kick in when another avatar in the vicinity uses a scripted object that triggers a previously-unseen animation.

Sadly, I can no longer rely on the mac client for professional use; I'm now having to boot windows any time I need to do something important in SL that requires telepresence contact with other avatars. It would appear that the best/only way to upgrade your mac to run SL these days is to invest in a copy of windows for your bootcamp partition

At the time which the hang event begins and the seconds leading up to it, there are no entries of any relevence. The only items of significance are the recording of the hang start time, Process 352 being monitored, Process 352 being force quit; Process 352 being exited: killed.

Alas, one of the problems of a hung computer is that it is unable to continue recording events, because it has hung. So the important moments happen just prior to the hang. I have to go back many minutes to find only events related to Time Machine operation. Nothing on the graphics. Nothing which mentions SL viewer difficulties. It's quite likely that there are a large number of different triggers for client hangs. You may have found one of them.

Since I have no adverse events recorded, I fervently believe the sim server is what hangs my client by failing to talk to it. So we get back to the network question. How good is my internet service? I believe it to be very good very reliable. Almost zero packet loss, ping time to ISP <50ms. In game, my ping time IS a worry. It almost never drops below 300ms and averages 340 or so. Naturally, this high number tells me that sim servers have quite poor response times and this is probably part of my hangs. Of course, I am guessing. I am not technically savvy enough to be certain.

Every time I start client 1.20.15.x the console records these messages:

26/08/08 Tue, 26 Aug — 8:10:54 [0x0-0x5c05c].com.secondlife.indra.viewer[597] Can't find file

26/08/08 Tue, 26 Aug — 8:10:54 [0x0-0x5c05c].com.secondlife.indra.viewer[597] Can't find file /Users/<username>/Library/Application Support/SecondLife/logs/stack_trace.log

26/08/08 Tue, 26 Aug — 8:10:54 [0x0-0x5c05c].com.secondlife.indra.viewer[597] Can't find file /Users/<username>/Library/Application Support/SecondLife/logs/stats.log

I have never seen these files in the locations specified. Is this setting me up for a hang?

[EDIT] Oops. No this message only happens after a cache clean and relog. Hummph. That might be why I hang after a cache clean then. But if the files are found on the next restart where are they hiding? Are they hidden files? Stranger and stranger.

There are several Lindens who use Macs - Torley is perhaps the best-known, but Phoenix founded the Mac Users Group - his title is "Mac Zealot", and I THINK Pathfinder uses a Mac. It beats me why LL can't put more effort into it - would it cost that much?

Someone mentioned inventory: my inventory is below 10k, but I have an alt who has only about 2.5k in hers and she rarely suffers from problems, so perhaps that may have something to do with it. On the other hand she doesn't spend much time building and editing, and I do a lot of both. Besides, 9.2k is pretty reasonable - I've heard of people with over 30k.

As for Cool SL - it's a miracle. I road-tested it pretty thoroughly. I disabled cam restraints today. I rezzed a lot of stuff from inventory, edited objects, flew, tp'd sailed in a sim with a lot of scripted objects (usually the kiss of death), danced, and visited a texture heavy sim. I did all this in the company of another av. I have been logged in almost all morning with no freezes, no forced quits, no problems at all. On one occasion I logged off because I had some RL stuff to do and the viewer quit instantly - no hang.

AFAI am concerned this shows that the problem lies with the viewer and not with my machine. This afternoon I'm going to bite the bullet and log in with the RC.

(2) The biggest problem when switching between clients, specifically the current 1.20 and (say) the CoolSLViewer, is that preferences and menu settings all get screwed up and there's a need to run around every single setting. So I do not casually switch back and forth — it creates too much work. I'll be staying with 1.20 to chase these problems. It's becoming increasingly harder to find any solutions — there are a lot of time-wasting false trails to follow and lead us nowhere. Very frustrating.

(3) I have described my findings earlier regarding what leads my Mac to hang. For me, there is only one issue, the cache clearing, that leads to my hang. I have dug as deep into this as I can, mentioning a couple of avoidance tricks. It's now over to the programmers to test my hypothesis and fix the code.

I copied the following paragraph from the bottom of this page. Please note that "Fix Pending" is indeed the indicated status up the top. I did not notice when this condition changed. It might be reasonably safe to hope that the version not yet published (1.21) contains this fix. Are we about to receive some relief from freezes?

NOTE: The "Fix Pending" resolution status means that the fix has been applied to a Linden Lab internal version, but is NOT in a public release of Second Life yet. "Fixed" means that the fix is confirmed public. Please do not change an issue's status unless you know what you are doing.

I have tried Coolviewer too but although it is indeed stable, it lacks the voice feature, which I use extensively. So, it is not really suitable for my needs.

Sandor

I am testing whether my desktop clutter is an added workload for my graphics card. Spread over hundreds of desktop folders are tens of thousands of files. All are removed now to my documents folder. Already I see much faster booting. And I see already a slightly, only slightly, improved frame rate in Second Life. That could just be wishful thinking. Minimised desktop clutter certainly has not helped with my fatal hangs.

Re switching between viewers: I'm not sure I understand about changing menus and prefs. I just set them to what I want in each viewer I use and they remain unchanged in that viewer. What am I missing? LOL

Sandor, I don't use Voice so it didn't occur to me that it might not be suitable for anyone who does. That's a pity: I was on yesterday in my evening. That's usually when SL is at its worst for me because that's when the number of users really jumps. I was rezzing and editing and tp-ing all over the place. Additionally I had email and Safari open and was switching between all three programs. Not a single glitch. I'm not trying to rub salt in the wound, Sandor, I just hope if any Lindens are reading this, they are taking note.

oh, one other thing? Is anyone here using a custom port? I was told some time ago to set mine to 13009. That was on my old machine - I haven't bothered on this one yet. I can't say that it made much difference.

It is not as if CoolSLViewer has its own set of Application Support folders and Second Life 1.20, its own separate folders. Both viewers change stuff in the one ~/Library/Application Support/Second Life/ folders. The settings are shared between both applications. And there is no protected CoolSLViewer where it puts its own settings, logs and caches. All is shared.

I have to say Cool SL truly is the answer as far as I'm concerned - but it doesn't say much for LL that a third-party patch solves problems that it is, apparently, beyond them to solve. I'll keep watching this, and if it looks as if things are improving, I'll give the regular viewer another chance. In the meantime, I've decided to snail mail LL telling them of my experiences. I don't know if it will make much difference, but it'll make me feel better.

I logged in fresh with the new RC and cleared cache... then I went to some of my test sims to trial the viewer. Apart from some short-lived pauses (none of those repeated long ones with tiny breaks in between). I have seen no fatal hangs. On my hardware, fatal hangs are what I normally see with 1.20 after the cache clean. Also frame rates are still poor on the Mac but I did not expect any improvements there. Not yet any way.

Sure, it's early days with this issue and the new 1.21RC so I have more stuff to try. BTW, the release notes are still suggesting we use all the workarounds that were accummulated in 1.20. I am using none of them.

The release notes have been moved. Find them here:
http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release_Candidate/1.21

From Linden Lab's Release notes for RC 1.21(0):

On some Macs, there are reports of periodic and cyclic freezing of the computer when running this viewer, similar to Viewer 1.20.
WORKAROUND #1: One workaround that may help is to reduce the Draw Distance below 128m in Preferences > Graphics tab > Custom > Draw Distance (slider). Also, if you have Disabled Camera Constraints from the Advanced menu, behavior is improved if you do not Disable Camera Constraints.
WORKAROUND #2: Another workaround that may help is to use an additional argument "-set YieldTime 20" in the Arguments.txt:
To set this argument, right-click (or control-click) the Second Life Release Candidate application and choose "Show package contents".
In the resulting Finder window, open Resources and in there should be a file named "arguments.txt". Open in text edit, add the argument to the end of the line in there and Save.
Close the text edit and run Second Life Release Candidate application.
This causes the viewer to sleep for 20 milliseconds every frame. It will slow the frame rate down a little, but may help with freezing.
STATUS: We continue to investigate this issue on some Mac hardware. For problematic MB Pros w/ the 8600 graphics card, we have also disabled Object-Object Occlusion and Avatar Imposters in the 1.21 Release Candidate, which seems to help in some circumstances for that hardware.

Now there is a weekend conference ahead and I'm not confident I'll be able to sit through even the opening remarks without a lot of frustration.
How long do these 'fixes' take? Is there hope for Macs with SL?

For instance, you could tell us your current computer specifications (apart from the RAM which DID need upgrading anyway, believe me - so you cannot say you spent your money uselessly).

To give us an idea of your setups, go to SL, select About Second Life from the Help Menu, and copy and paste the hardware configuration information you will find there.

You are among friends, please remember we are not LL employees but users like you and it is more important to try to ask LL to fix issues after proving they really exist, may be reproduced on other similar computers and follow a pattern.

I guess you are using a final release at the moment, probably 1.20 or 1.19. They both do not work very well on a G5 Mac (personal experience) but you can follow the previous messages on this thread and try some of the workarounds.

The current Release Candidate, 1.21(0) seems to solve the freeze problem on Intel Macs but it crashes on G5s. You will have to wait until the next RC (Release Candidate) 1.21(1).

Sandor

This RC also continues to occasionally cause corruption to windows outside of the viewer window - I get multiple lines around other windows, the menu bar changes background color, the apple icon for the apple menu disappears. This generally gets worse with each freeze / force quit until it hangs the machine and I need to power off.

Trying to open the inventory of a box, trying to TP somewhere, talking to another avatar - all can be triggers sometimes, other times those things don't cause a freeze, other times the freeze just happens.

Also, the 20 second freeze detection doesn't work. The RC froze for 40 seconds and didn't crash.

On this machine, the freezes never recover, they need a force quit at best or a power off at worst every time.

Now, on a fast Mac Pro3,1, my average for a quiet sim with only a few or no other AVs, is 8-9fps, frequently slipping down to 3-4fps and freezing. It appears I need to disable a lot of graphics settings, stop wearing any prims and remove my scripted gadgets, if that is going to improve these matters. I have tested this somewhat. Since such actions appear to have negligable effect, I do not bother limiting my experience and prefer to push the graphics envelope and wear my prims and gadgets.

So, what the hell is wrong with Second Life frame rates? Is it deteriorated sim performance? Is it the lousy porting of these clients from Windows? Is it the lack of MacOS expertise at LL? Is it LL unwillingness to put some resources to work to fix the Mac experience? Is it Mac video drivers? Is it a policy to force all Mac users onto Intel Macs and then to install Bootcamp and Windoze, ie, phase out support of the Mac client? So many questions and so few answers. What does an owner of a fast Macintosh have to do to convince the Lindens that the Second Life experience for Mac owners is ABYSMAL. Since 1.21.(0) sucks so much and has basically ignored performance needs, I am going to revert to a long term use of CoolSL Viewer. BTW, why can't the Lindens achieve the same sorts of client speed improvements that an amateur-produced patch for 1.19.1(4) can provide?

I have already reported that I no longer have a fatal hang after a cache clean. That is still true. However, I have more lengthy pauses. These are one-offs with the beachball often appearing. If I change position with a major move to another part of a sim then more pauses will occur. I see no more "cyclic freezing". So, no more fatal beachball events at the moment, but plenty of pausing. And according to the Lag Meter, these slowdowns are the direct result of the slow response of the region servers. 1.24.3 appears to have fixed nothing. It is client<—>server communication which is the problem. Also on this, I am experiencing the most dreadfully slow rezzing of a new sim. It never used to be like this. I TP into a new location, EVERYTHING is grey, including any AVs present. Unless I zoom the camera directly to a tree, the ground, an object, a texture of any sort. Much of it simply will not rezz for perhaps up to 15 minutes. Some avs never rezz. Instead of messing about with client skins, voice, havok, and now mono, PLEASE PLEASE PLEASE, fix performance.

One thing I never reported before when using 1.20, was the frequent bugged log-off operation where, after a quit was performed, a force quit was necessary because the client, though gone from the desktop, was still running. This no longer happens. Well, I no longer see it because I have had no more force quits. I might hazzard a guess that the broken quit function was related to earlier force quits, meaning that when I was forced to employ a force quit, it automatically followed that I should reboot the Mac, because otherwise, every future quit would be broken and also had to be force quit. Clear as mud, I guess. So I need to wait until I need to perform some force quits to see if subsequent voluntary quits continue with this buggy need to follow with a force quit. Anyway, why the need to force quit? It is clear that the client is incapale of quitting cleanly under a lot of circumstances. Client code needs to be cleaned up so that force quits need never be necessary.

Is anyone listening? Is anyone actually working on these performance problems? Or are you just fiddling with features and eye candy? Lets get back to basics, please.

Me? I am ending use of 1.21(0). I am sick of it already. It's to be CoolSL Viewer until either SL fixes 1.2X.X performance, or bans the use of patched clients.

What I am seeing are several different kinds of freezes and I actually doubt they are related. The first is the almost steady pulse freeze that is like a limp. I see it in other avatars' movements as well. This is an intermittent problem and I haven't found any trigger for it.

Then I sometimes have random, intermittent freezes that are often less than a second apart and can last for one or two seconds each. This problem begins slowly and builds until I can barely function and am forced to relog. However re-logging doesn't always seem to help. I have found no consistent trigger or cure for these. However, I haven't seen a really bad case of this for several days. (about how long I have been using the 1.21 viewer).

The third type are sudden solid freezes out of nowhere that can last for seemingly up to 20 seconds, though I have never timed one and time guesstimates like that are often way off. I seldom had such a freeze recover in full screen mode. They almost always recover in window mode, although since I stated using the 1.21 viewer I have had several of these that have not recovered.

The final type is just a sudden closing of the viewer. I can be simply typing away in chat and POOF I'm looking at my desktop. SL is gone. This has become much more common in window mode.

I feel perhaps I have made an error in seeing all these as a single problem. What I mean is that, as I am testing, if I see any of these issues I assume the problem still exists. I would do wiser to watch for one issue at a time. I have been too general in my assumption of the problem as "freezing" and that may have led me to some false conclusions. I am still thinking, however, that much of this is related to communications problems with the various servers. I have run into other such communications problems that come and go such as the inability to file abuse reports. I tried that 6 times in two different regions recently and every attempt failed. Half the time it said I wasn't a valid avatar and the rest said internal server error. The behavior of that problem seems the same as type two freezes above...something that pops up from time to time to varying degrees.

As for the problem mentioned earlier here of settings reverting when changing viewers (or grids)...The settings are saved in an xml file. If you look at the arguments.txt file for the RC viewer you will see it declares a specific settings file - --settings settings_releasecandidate.xml. You can use this command line parameter to create a different settings file for each viewer. Just name it whatever you want and it will create it the next time you start that viewer.

RC1.20 and release 1.20; and now RC1.21(0) are broken as far as I am concerned. Severely crippled. I am using the patched 1.19.1(4) called CoolSL Viewer. It is like someone smashed me in the head with a sledgehammer: the performance difference is so profound. Staggering. The patched SL client shows that the new server software (1.24.3.x) is working just fine if you are using a decent viewer.

Gone are
(1) the constant slideshow animation and movement, replaced with smooth responsive motion;
(2) grey avies and textures, because I see true textures immediately I arrive;
(3) ultra-slow world responses replaced by SPEED in capital letters;
(4) no more pauses, freezes, or hangs.

YIPPEE! I can continue in SL. My frustrations are gone. All that remains now is for LL to talk to the bloke who made the CoolSL Viewer patch. Quite simply, it works and works very well.

I decided to dip my toe in the RC waters. I use the recommende settings except I turn my particles down to 2056. Cam restraints on. Same old, same old.

Georgie, I have the force quit problem in the regular viewer, but in the RC I found that was improved. Welcome to the wonderful world of Cool SL. I don't find the later version works as well - I'm sticking with the original for now. BTW the RC cache is in a different folder, so you CAN switch back and forth. It's in "user/name/Library/Caches" (which you've probably already discovered for yourself, LOL).

Thanks for starting this off, Georgie, and for putting in so much time and effort. LL take note. And watch out, LL: multiverse.net has Mac and Linux clients "on the road map". If they've learned anything from LL, it will be to offer a NATIVE Mac application instead of a port from WinD'OHs.

Model: iMac8,1, BootROM IM81.00C1.B00, 2 processors, Intel Core 2 Duo, 2.8 GHz, 2 GB
Graphics: kHW_NVidiaGeForce8800GSItem, NVIDIA GeForce 8800 GS, spdisplays_pcie_device, 512 MB
Memory Module: BANK 0/DIMM0, 1 GB, DDR2 SDRAM, 800 MHz
Memory Module: BANK 1/DIMM1, 1 GB, DDR2 SDRAM, 800 MHz

So I logged out and logged back in with the new RC. The problem was gone. So by mistake I actually got a comparison of the two viewers while one of the problems was happening. So the RC seems to have cleared up this part of the problem for me. I have seen some slow rezzing at times with the new RC and some freezing but i haven't seen this extreme sideshow effect like this with it. And this is the freeze type that has been causing me the most problems lately.

Let me start off by saying, very emotionally, PLEASE GEORGIE, DON'T GO! If it weren't for your efforts, some of us would not have a working RC now. I am one of them. RC 1.21(0) has been working seamlessly on my Intel ALU iMac ever since I installed it and I also have learned that the same should work on Power PC configurations now.

LL has deployed the server code during the last two days, and this deploy may have caused a few of the problems the latest posts describe. Please everyone, give the RC another chance.

In any case, please note that the RC 1.21(0) works very well on this configuration and with the following settings:

CPU: Dual i386 (Unknown) (3060 MHz)
Memory: 4096 MB (notice the size of physical RAM)
OS Version: Darwin 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8800 GS OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.17408 (Mozilla GRE version 1.8.1.13_0000000000)

Graphics settings are High with only one customized change: Water Reflections (all avatars and objects) on.
I have also set anti-aliasing to 2x.

Of course, I have no objections if Georgie wants to close this issue because it was originated by Georgie. But in my humble opinion, other residents might find a lot of very interesting information here and add their own. At least we could show LL we are here and they have to deal with us .

I have no objections to using alternative browsers either, but once we had a meeting in-world with Pastrami Linden and other head developers at LL and they told us that alternative browsers are not updated as regards security. Cool SL, for one, has no voice feature and I cannot use that because I DO use voice. But of course other people may not care.

Sandor

Personally, I'm being optimistic about the forthcoming release of Leopard 10.5.5 ... I've seen several references to bug fixes for the OpenGL Nvidia drivers in that release - maybe those bug fixes help ease our SL experience. (/me wonders if anybody at LL has a copy of the 10.5.5 developer seed....)

But before I begin, Shep I just saw your post. That kind of issue does bother me but not in regard to scripting. I don't script.

First and most important: It should not be my decision to close this issue as I am just one of the contributors and it would be most rude of me to leave you all dangling. As well, there are still problems of the like mentioned in the original complaint. Clearly, I cannot close it while there are so many concerns outstanding.

My apologies to Franscesca: You are quite correct. There is a settings file for each viewer we might use. I guess I may have forgotten to wear my spectacles the day I wrote about this.

Now to our viewer:
I have logged into my own home parcel. I have given time for things to settle, for everything to rezz etc. As a quiet sim, this one has been a good performer. I use it for comparing browsers because I spend a lot of time here. Currently, on the 1.21.RC(0) my frame rate is 10fps. This is a good day for frame rates. 10fps is a very good number here. Normally it is lower at around 6-9 maybe, and there are constant yellow or red Lag Meter warnings for all three of "Client", "Network", and "Server". I frequently see all three red on a quiet sim. Moving the avatar is a constant ordeal of hesitancy, choppy motion aand pauses. Those states are even worse when I travel to most sims. This is not how I remember SL to be a few months ago.

Contrasting the 1.21.RC(0) client, I used CoolSL Viewer, a patched version of 1.19.1.(4). This older version gives me in my own home parcel between 30 and 50fps. Sometimes the Lag Meter's "Network" shows yellow, telling me the ping time has become greater than 300ms for a short time. The other two values are almost always green. [BTW Sandor, if I may, CoolSL Viewer does do voice. I do not normally use voice so I have not tried it but the settings are all there in the Prefs to be enabled as needed. Perhaps there is something I do not know about CoolSL Viewer: Has the voice component been bugged by the patching? Or possibly, 1.19.1(4)'s voice is no longer compatible with SL.] Of course, CoolSL Viewer performs very well indeed in all other regions of SL, having frame rates which never seem to drop below about 20 on the busiest places.

-------------------------------------------------------------
It is time now to again indicate the SL settings I use.

Second Life 1.21.0 (95157) Aug 26 2008 17:42:11 (Second Life Release Candidate)

You are at 290205.7, 280018.1, 47.5 in Klaatu located at sim2421.agni.lindenlab.com (216.82.17.172:13000)
Second Life Server 1.24.3.95195

CPU: 8 x i386 (Unknown) (3200 MHz)
Memory: 16384 MB
OS Version: Darwin 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8800 GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28

libcurl Version: libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
J2C Decoder Version: KDU
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.17747 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 9/2916 (0.3%)
--------------
Preferences: Graphics

Windowed 2556x1556
Ultra and Custom
AF disabled
AA 2x
Enable VBO: yes
Texture Mem: 256/512
All shaders ON
Reflection detail: Everything
Avatar Impostors : Disabled
Hardware Skinning: Enabled
Draw Distance: 128m
Mac Particle Count: 2048
Post Process Qual: High
Mesh detail:
Objects and Avatars: High
The other four: Medium..
----------------------------------------------------------------
Advanced menu settings:
I have removed camera constraints
Object -Object Occlusion remains enabled
Fast Alpha and Run Multiple Thread are enabled.
------------------------------------------------------------------

I use these same settings for both CoolSL Viewer and 1.21.RC(0). None of the workarounds developed with the Release Candidate 1.20 have ever worked for me. CoolSL Viewer (1.19.1.(0)) lacks a setting for AA so it is obviously not enabled. Could this alone be the difference between this viewer and the RC? I doubt it.]]

In my last post I wrote that 1.21.RC(0) seemed to have resolved my fatal hangs after a cache cleaning. I wrote previously that CoolSL Viewer had this fatal hang. Now, CoolSL Viewer also does not give me my fatal hangs following a cache clean. What's changed? I am concluding that the one vital factor which has changed is the server software version. Sim server version 1.24.3 has overcome my fatal cleaned cache hangs.

Okies. For me the three remaining issues after using 1.21.RC(0) are (1) the continued excessive freezing, (2) the worsening frame rate, and (3) the extraordinarily long time for textures to rezz. I think the three are related. I am thankful that crashes and hangs seemed to be put to rest for a while. It is quite abnormal now to need a force quit.

I get a strong impression that most of you other contributors here have no problems with frame rates and general speed and response as you have never specifically mentioned them. Well, this and slow rezzing, are the areas that is killing SL for me. My lack of SL responsiveness or speed of SL interaction running at a crawl, is absolutely the pits.

Yes, I have tried crippling graphics settings: Draw, Windlight and sundry other values. None provide any improvement to performance. How can that be? I have no idea except to suggest that my problem is simply an inability of all these browsers, 1.20RC, 1.20, and now 1.21RC, to communicate speedily with SL and the sims, especially the sims. The sim software seems to be fine but either my clients have a problem asking the questions or the sim doesn't understand the questions. As I said, the CoolSLViewer communicates just fine with the new sims software and handles my high graphics settings just fine — the same browser settings are used for both the CoolSL Viewer and these various versions of 1.20 and 1.21.

What the heck is going on? I am FORCED to use CoolSL Viewer. It's that simple. It feels as if this VWR-7779 is no longer relevent. I have a different problem, the speed and communication issue, and a new topic needs to be started. I hinted in the earlier post that I am finished with VWR-7779. That feeling is still at the heart of my thinking. However, I still receive your input in emails so I am going to remain informed on this discussion. Also, I probably still have more to contribute and I remain interested. I do want to use the new browsers but may well be forced to if LL kills the use of old clients. I will resume using and testing new RCs and releases when the problems related to my usage are resolved. Just at the moment, apart from switching to CoolSL Viewer, I am undecided what to do.

My best,
Georgie

Great post there!

First, Thank you for your remark on my comment on CoolSL Voice. Perhaps I did something wrong but although it is true that all settings are there in the version I installed, in the Voice tab I get a warning: Voice is not supported.

As for the frame rate, I live in Italy and generally the quality of ADSL connection for home users is not great, and on top of that I live in a neighborhood in the city of Rome where the local phone wiring does not seem to allow for higher speeds than 5200 kbps. Therefore, I cannot be used as a reliable source of information.

However, I have always had a frame rate of 6 to 7 fps with ANY version of the browser (from 1.17) on two different Macs and I believe it has to do with the quality of my internet connection. When I tried CoolSL, there was no noticeable difference.

Using RC 1.21(0) my frame rate has jumped to 15-20 fps.

I am starting to believe LL has made a viewer that only works with my machine configuration .

Ah, I have a question: what is hardware skinning? It is disabled in my viewer because it tended to slow down EVERYTHING, so I thought it was not supported.

Sandor

Regarding Avatar Impostors: I used to leave this enabled. I did not know what it did. After being advised that it would be better for our freezes if it was disabled, I disabled it. It's a bit funny actually. I used Avatars Impostors enabled for a long time and never ever saw what it did. Once only once, I saw an avatar's rendering affected by this element. The avatar was quite close like about 8 metres away and was VERY coarsely pixilated with shades of grey and brown. As far as I know that was not supposed to happen because it's my understanding that this effect is applied for more distant avatars. Distant? This avatar was not distant. But if that is what Avatar Impostors does, its a useless effect and deserves to be disabled.

I have tried this feature on and off without much improvement for several months until LL decided to listen to most customers complaining about pixelated avies and...scraped the pixelated look, so now you cannot see an avatar AT ALL from a certain distance, unless you move the camera away from you and onto the avatar. This is very similar to the draw setting's effect. The resulting problem is that some avies which place themselves between the "no-avie" and "full-avie" zones appear incomplete: sometimes you see their hair and their shoes but not their bodies. LOL! But this is what happens when most users do not know what a feature is for. It leaves the vocal minority ranting forever until a solution is found which is worse than the problem. That is why I do believe in continued discussion on problems which may be considered minor by the largest possible number of users.

Sandor

Now for the skepticism:
--Are these perceived improvements temporary or permanent? Only time will tell.
--Is there some base level housecleaning that occurs when a new viewer is released that provides a squeaky clean, minty fresh viewer experience for the first X number of hours?
-Does viewer performance degrade over time from some natural (or unnatural) bloat and/or corruption problem? I remember hearing a famous Mac person talking about "bit rot" once-does this happen with SL over time? Does it accumulate more and more bit rot from version 1.21.A to version 1.21.Z, and if so, how can that be avoided?
--While the network stalling seems to be greatly reduced, it is still there. Why does the viewer temporarily lose its connection to the mother ship? What changed with this version to improve that? Will it return?

Finally a charge to LL: Look at this thread carefully, dear Lindens. You obviously have a group of passionate, dedicated Mac users who yearn for a great SL viewer experience and who are doing anything and everything to help quash this issue once and for all. Please continue to give us tasks to try out. Please continue to enlist Apple's support. Please keep communicating with us. Please keep working to make an "insanely great" Mac client. We are eager to help--please continue to keep us in the loop...

But in my neck of the woods, there is something devilish afoot.

It's got to be the hardware. And it seems that you can have too much of it. Yep, I would have thought that an 8-core Mac Pro loaded with a stack of RAM and the best graphics chipset that Apple supplies for it would eat SL client software for breakfast. However, it looks like the Mac Pro has choked and cannot take it any more.

From recent Mac users' reports, many are managing quite well with Core2 Duo CPUs and weaker graphics.

It just defies logic that this MP does not like any of the latest Release Candidates or Release versions.

Has anyone got any idea why? Maybe it's true that while Apple/nVidia has done some work with the graphics driver, there is a long way to go before the Mac Pro can perform right up to its potential. Unbelievable but possible I guess. That thought also seems to have no credibility because there are many other Intel Macs with the same graphics driver handling these browsers much better. There must be something strange happening with the Xeons.

I am very jealous.

Again, it defies logic that CoolSL Viewer is so good on the Mac Pro when the newer clients are all rubbish. It is very depressing. I think I will go and top myself.

AAAAARRRRGGGHHHGG

I have to say in busier laggier sims I get nothing like those figures, even in the Cool Viewer, but it's interesting that there's a difference.

Sunn, I've noticed that deterioration as well. I had been using OnRez or Nicholaz on my old Mac. When I got the new one in May I was able to download the latest client. At first it was wonderful - SL as it was meant to be seen. Then I started to experience all the old problems again.

Model: iMac8,1, BootROM IM81.00C1.B00, 2 processors, Intel Core 2 Duo, 2.8 GHz, 2 GB
Graphics: kHW_NVidiaGeForce8800GSItem, NVIDIA GeForce 8800 GS, spdisplays_pcie_device, 512 MB
Memory Module: BANK 0/DIMM0, 1 GB, DDR2 SDRAM, 800 MHz
Memory Module: BANK 1/DIMM1, 1 GB, DDR2 SDRAM, 800 MHz

It's a real shame, because aside from the freezes, RC0 has brought some of the best fixes I've seen for a long while. I'm still getting awfully low frame rates, but it seems I've gained a few frames per second.

My video memory slider still jumps back to 256 every time I log in. Under Windows it stays at 512.

Just to be more clear on my system specs from my above post, About Second Life... reports them as:

CPU: 8 x i386 (Unknown) (3200 MHz)
Memory: 6144 MB
OS Version: Darwin 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8800 GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.28

That is, of course, a Mac Pro. I'm running the latest version of Leopard too. 10.5.4.

I'm not sure if it makes any difference, but I run my SL window as large as it can go, with the dock auto hidden on the left of the screen (for more space), 1920x1200 desktop resolution. If I switch into or out of fullscreen mode, the screen turns black, though the UI remains visible. I can barely make out the reflection of the sun on the horizon. Then after I move around for a minute or two the black goes away. It's like no light gets rendered at all, so everything is pitch black. I'm not sure if that's at all related though.

at 3000 meters up, first glance I am hitting 15 to 20 FPS

Ground level is about the same. 20 fps

dropped the graphics settings down from mid with various custom settings to low. frame rate shot up to 45-60 fps.

back to 3000 meters up, moved my camera view outside so looking at clear sky...fps went up to 100-110 and stayed there

clicked the open office icon to bring up the Writer to draft this comment and the fps dropped down to 20.

switched back and forth a couple times. Frame rate 100 when the viewer is the active window...20 when it isn't

Reduced the SL window size so it is about 1/4 of my screen and the frame rate jumped up to 160 fps. That seems to be the top limit. I can sustain 145-160 fps under those conditions. But I would love to see faster rates under normal conditions.

speedtest.net shows my download speed @ 2823 kbps

using the 1.21 RC

Take the new RC and run it on my Mac Pro. But instead of using the full available screen area on windowed mode of 2560x1600, I shrunk the window to 1920x 1200*. This does help the frame rate generally by perhaps 15-20%. However, moving to a busy place like the Dore/Morris quadrangle after a cache clean, reveals that cyclic freezes are still the order of the day and the place is a total greyathon. After 10-15 minutes and most stuff is rezzed, my client settles for a framerate of ~ 6fps. I suppose that is better than 4. Whatever happened to the 20+fps of old?

This is still a total failure IMO. Because CoolSL Viewer can run at 2560x1600 at the same sim with a much higher frame rate, without a greyed out world where, on arrival, textures immediately snap into place.
I used to run the release SL browsers prior to 1.19.x at 2560x1600 without all this angst.

It all adds up to LL cramming more and more bells and whistle into SL without fine tuning its rendering performance to help us cope with the complexity.

I refuse to compromise with a small window into SL on my 30" screen so I must continue using the CoolSL Viewer. The Lindens have lost the plot.

Just like the login screen when set to using the full 30 inches and failing to show anything but a blackout graphic because LL removed support for the 30" (see the Jira), I suspect that LL removed support for 30" screens generally in its viewers. It has become very clear to me that 1920x1200 is as big as one should be running SL. How long will it be before LL forces us to reduce to smaller sizes again because of SL bloat? We might find ourselves running at the old gaming resolution of 640x480 again, just to keep the frame rates up. LOL!

So! 1920x1200 helps a little with my frame rates but nothing else. It's still a grey world for 15 minutes and my cyclic freezes have returned with a vengeance. That's it! Back to full 30" mode on CoolSL Viewer.

*What is going on with the Preferences/Graphics tab? The only available screen size settings in the dropdown are 640x480; 800x600; 720x480 (NTSC); 768x567 (PAL); 1024x768. All of these are totally useless. These are PC settings from that dark era of DOS, Win3.1 and Win98. Someone has to tell the Lindens that the world has moved on from there. Does anyone ever use any of those resolutions on a modern computer? Maybe they are intended for phones? And what of those two television sizes? Does any sane person run SL on a TV? Those are not even usable digital TV sizings. What does all of this have to do with Macs that can run LCDs up to 30 inch? All of the listed resolutions are smaller than any Mac with inbuilt panel that I am aware of. This is a prime example of how LL is failing to optimise the clients. How did I set my client to 1920x1200? By trial and error: drag-resize then open the Prefs/Graphics to see what the window size is; rinse and repeat ad nauseum until you get your desired size. This is a fine example of a much needed new Jira because I find it bothers me a great deal. Trust me: I'm gonna start one if there is not already a Jira running on this.

Georgie

Sticking with the recent official Release Clients and or the Release Candidates, means poor Georgie has a very slow, laggy, freezy, Second Life experience. There is one <apparent> common-sense solution immediately available.

Reduce window size from my huge 2560x1600 normally used on the 30" display to 1920x1200 or less. Shrinking the GPU's workload by about 1.9 million pixels is of some help with rendering but is not a total cure because 1.20 and 1.21 appear to have built-in rendering and network inefficiencies which continue to cause slowdowns. The freezes still occur and seem about as bad as ever. None of the officially suggested workarounds work and frame rates still fall to a standstill.

The best solution is to avoid the 1.20 or 1.21 clients. CoolSL Viewer is far more efficient but as it is based on 1.19.1.(4), Cool lacks the innovations included in the latest official clients and may indeed in the future become incompatible with updated server software. CoolSL Viewer offers an almost lag free, freeze-free, 2560x1600 fast-rendered experience. I'll make the best use I can of the patched client while it is still usable.

When old clients patched with 3rd-party fixes are disallowed and the use of the official client becomes obligatory, I guess I will walk away from Second Life. The Lindens know why. Slow rezzing, freezes, and commonplace frame rates of 3, 4, 5 fps are absolutely intolerable, and 8-10 fps barely tolerable.

According to Second Life's System Requirements my 2560x1600 resolution is an acceptible size (quote "1024x768 pixels or higher"), so it is beholden on the Lindens to match Second Life performance to these displays.

It looks like I am the first to report regarding the new Release Candidate, 1.21.RC1. I am trialling it on the Mac Pro1,1 to start with. I will be installing RC1 on the MP3,1 and the MBP3,1 as well.

It is a good deal better than RC0 in so far as rendering a new scene is far quicker. RC0 was a real pain for that alone. As for freezes, it's about the same as for 1.20 except that I no longer have a fatal beachball event soon after a cache clean. However, I did suffer the usual cyclic freezes after the cache clean and it took SL quite some time to let up on that as pauses continued everywhere I went. Nothing new about that, I suppose. Do I sense that pauses are shorter as the cache fills? I think so, yes.

What is new was after I returned to my quiet home parcel and was changing some settings on a scripted item, when a fatal beachball hang kicked in. This did not seem to be connected to my adjustments as I had been cycling through several other colours beforehand. This is the first time I have had one of these hangs at home with no-one else around. There might be a different cause for this event.

It's gonna take me longer to test other aspects of this RC like changing graphics setting, etc, but I guess I will be using this RC for a while as it is a lot more pleasant to use than RC0.

And yes, I do understand that no fixes for these hangs have been found yet so there is not much point to continued reports on them. Therefore, I will only mention them briefly to show that they are still occurring.

Later...
The Mac Pro3,1 gave a similar result to the MP1,1 but the MacBook Pro3,1 was interesting. It was interesting not because RC1 was different but because I am starting to realise that a utility which runs all the time may be causing interruptions to any SL viewer which I am using.

All my Macs run a utility called Hardware Monitor which keeps a realtime watch on temps, volts, revs and all that. There may be a possibility that HM's frequent polling of all these values is disturbing to the function of SL viewers. I am going to quit HM in future while logged in to SL. There was an instance on the MacBook Pro today when it had a fatal hang running this RC1. It appeared that HM was trying to flag a condition on the computer that it was worried about. Hmm...

Otherwise, the MBP managed fairly well, with not very many freezes. I must say that I would much rather be SLing on one of the Mac Pros because the tiny 17" 1920x1200 panel on the notebook is very much harder to get comfortable with than the MP's 30 inchers. It's a question of the suitability of one's glasses, I am afraid. So I probably won't be saying much about MBP perfomance here, with these viewers.

It is nice you continue to share your experiences with the RC.

I can tell you that the hangs I had (not anymore, but I still crash when toggling from windowed to full screen mode – but that is another glitch) were totally unrelated to anything else running in the background, so the fact you have Hardware Monitor running on your MacBook Pro may just be coincidental.

Please peruse the list of bugs in the release notes. The following bugs are present and acknowledged by LL:

VWR-8906[c]: Viewer crashes instantly when trying to open scripts or notecards in objects containing large amounts of inventory.
On some (but not all machines), attempting to look at an inventory list (or notecard or script) that contains large amounts of objects (eg, greater than 50 objects) either by double-clicking or right-clicking, will cause the viewer to lock then crash suddenly.
STATUS: We are investigating this serious bug. If you experience this behavior, please comment on the bug report VWR-8906[c] to let us know the type of machine & environment you are using.

VWR-8816[c]: Crash when attempting to edit scripts (by double-clicking quickly before the content tab fully loads)
STATUS: We are investigating this serious bug.

If you and others agree, I propose closing this ticket and focusing our attention on the bugs which still remain to be squashed .

Sandor

I pause when using a Windows client too but those pauses are always very brief and there are never all that many of them. Mac viewers still freeze excessively, a lot worse that Windows viewers. I use the Windows client example to show that the Mac clients can be better. And I also suspect that because Macs use a client ported from Windows clients, that it's evident more fine tuning of the Mac client ought to be considered.

My pauses are serious enough and frequent enough to constitute a need to continue investigations.

We know that this issue is still being worked on by the Lindens. We know that this is an unfinished work. So I have to disagree with closing VWR-7779. If a majority of voters and contributors to VWR-7779 agree to close, I will have to reconsider my position. Q: At what point does one accept these freezes as something Macs naturally do and simply tolerate them? Do we accept them like we have accepted a seriously degraded frame rate on Macs? I am not ready to capitulate yet.

I am sorry if you thought I was being pedantic, but I mentioned those two jiras because on a Mac, a crash or a hang which you can only fix by a forced quit or a restart are the same thing. And you mentioned something in the previous post which looked like the behavior described in those two jiras.

As for closing this ticket, I need to be more specific: I invited people to vote for its closure not because I think the Mac viewer problems are over, far from it, but only to verify whether you are the only one left with the cyclic freeze problem or not. Even I do not have cyclic freezes anymore, full screen or windowed mode. If you are the only one left with this problem and no-one else is, perhaps it is time for you to open a ticket with support because the problem is independent of the viewer.

But, no way I was suggesting we Mac users should simply shut up and gobble a bad browser. I was one of the first to mention that this is a Windows port that should be made Mac-friendly and I want to believe my accusation was proven right, since it now seems we have a team of more dedicated Mac developers at LL: just look at the quantity of Mac OS viewer bugs that have been fixed or acknowledged in the latest RC.

Sandor

Edit:

On further testing, cameraing around, focusing on things and rotating the camera for about 20-30 seconds seems to lead to an indefinite viewer hang. Repro seems to be just camera on random objects/ground, rotate it around a bit, camera elsewhere, then go to mouse over an object and click on it and the viewer hangs. For me, at least anyway.

Oops, now it is my turn to appear pedantic. It seems we have differing definitions of crashing. I have always recognised the kernel panic or the "unexpected quit" as a crash. A hang up with the usual accompanying beachball, I have felt, is the client waiting for data which sometimes never comes. The cause of that hang of course is most likely something that the client got confused about. I need to mention that I have indeed had a few Second Life beachball events that the Mac does recover from. To me those are not crashes. That's why I try to wait out a beachball to see if there will be a recovery.

No, this excessive freezing IS dependant on the viewer, at least in my case. I have had to conclude this because when I used 1.19.1.4 recently, it did pause, but far less than 1.20 and 1.21. Then when I use 1.19.1.4 (patched and called Cool SL Viewer), it does not freeze at all except for maybe a couple of momentary 1-2 sec holds, certainly none of these freeze cycles that go and on on and which can be reinitiated by moving to another populated sim and doing those camera moves which seem to start the rot. I must mention that often, I may be in a freeze, if I hold the ESC-key down, the current cyclic pauses sometimes ends. ESC of course returns the camera to the parking position behind the avatar.

In all my discussions, it is becoming apparent that some Mac hardware can use these clients with very little freezing and give really good frame rates, or so people claim. I wish I could get the owners of these Macs to explain what aspects of the client are crippled for them to obtain their superior performance. It is very frustrating that a Mac owner claims that they have very good performance but when the questions are asked, vagueness and Mac-newbieness seem to be the order of the day. I don't ask any more. I have begun to realise that what is acceptible (or rated as good performance) for some people, is for me quite bad performance. It appears that some newer SL residents using Macs consider that sub-10fps and freezes is good performance. They've always had poor performance and accept it as normal, whereas, I recall my own early Second Life as freeze-free and of very high frame rates. (Except of course, when in a shop or around a lot of other avatars. Lag has always been around but somehow a year ago it was never as bad or as prevalent.) Some people have lots of freezes only they do not know these are abnormal, they think it is normal and never mention it until someone like me comes along and asks. "Oh yes I get that too, I thought it was normal."

Hi Davey,

You have described my kinds of hangs. They follow random camera zooms and circling. The strange part about my events is that I may move to a new populated sim and swing that camera all over wihout problems, then a new sim and repeat - no problems. Then, at another sim, content that things are running smooth, a bunch of cyclic freezes (sometimes ending in the beachball hang and force quit, but rare in RC1). For me these freezes are not predictable in RC1. Unlike my lockup following every cache clean in the 1.20 RCs, these in RC1 are nowhere near as predictable or reproducable.