• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-1844
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Darius Lehane
Votes: 10
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

High Framerates on Windows Vista causes very large network lags

Created: 20/Jul/07 08:07 PM   Updated: 11/Jul/09 06:20 AM
Component/s: Performance
Affects Version/s: 1.18.0, 1.21, 1.22, 1.23
Fix Version/s: None

File Attachments: 1. Text File SecondLifeLOG.txt (266 kB)
2. Text File VWR-1844.patch (6 kB)

Environment: Windows Vista Ultimate, Intel Dual Core 6600 with 2Gb RAM and an 8800 NVidia card and a 768kb DSL connection
Issue Links:
Relates

Last Triaged: 05/Nov/08 08:56 AM
Linden Lab Issue ID: DEV-23380


 Description  « Hide
On my land my framerate exceeds 100 fps, sometimes much higher. When I move at these framerates, the viewer will get network ping times in excess of 2 seconds.

The issue is blocking because Second Life is unplayable to anyone with a newer machine (I only managed because I have a PC at work which is much slower).

I would guess the issue is that some network work is performed every frame, and at higher framerates the network becomes saturated.

It would be great to enjoy SL at 100+ fps.

P.S.: I was able to validate this theory by running SL in XP compability mode, which slowed SL down to about 25 fps. Although the framerate was lower, there was no lag. Very reproducible.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Flennan Roffo added a comment - 25/Jul/07 09:14 PM
If it can be verified that this high framerates happens on all Viewers under Vista and that this is a blocking issue in all cases, this is important to solve since more and more users will start using Vista.

Torley Linden added a comment - 27/Jul/07 10:29 AM
I've moved this to Major pending more info from those who are affected. If this is a problem for you too, please provide system config and attach a SecondLife.log file.

» http://wiki.secondlife.com/wiki/Debug_Help


Kevin Susenko added a comment - 19/Aug/07 07:59 AM
This doesn't seem to happen to me. At 128m visibility my ping seems to stay around an average of 100-115ms ping even when my frame rate is 80-120fps

Intel Core 2 Duo E6400
XFX nVidia GeForce 8800 GTX
4gb DDR2 PC5300 Dual Channel
Windows Vista Ultimate 64-bit
1500/384kbps DSL


Wazza Mannonen added a comment - 27/Nov/07 03:23 AM
Second Life 1.18.4 (3) Nov 19 2007 15:02:01 (Second Life Release)

************************************************************************************
You are at 204693.8, 229510.3, 401.9 in Listavia located at sim4495.agni.lindenlab.com (63.210.158.145:13004)
Second Life Server 1.18.5.73200

CPU: Intel Core 2 Series Processor (2399 MHz)
Memory: 4095 MB
OS Version: Microsoft Windows Vista (Build 6000)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8600 GTS/PCI/SSE2
OpenGL Version: 2.1.1
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000)
Packets Lost: 1/1700 (0.1%)
Viewer Digest: 994fcc3a-2e0e-ddb8-a870-68b882421bfc
***********************************************************************************

Will start up normally, however after a few (10-30 seconds) it will freeze the sim I am in. I can IM for a further few moments and then that will freeze. I have uninstalled, reinstalled both drivers and viewer.


Wazza Mannonen added a comment - 27/Nov/07 03:28 AM
Wazza Mannonen - 27/Nov/07 03:23 AM comment.

Wazza Mannonen added a comment - 05/Jan/08 07:00 AM
Can't someone do something about this?

BETLOG Hax added a comment - 01/Oct/08 12:29 AM
This is a serious problem, it basically means we can't move by normal keyboard presses at all.
Personally I consider this a showstopper....Hence the sheer quantity of data I am providing below. If i can be of ANY assistance with providing testing/data to solve this just let me know.

If i am being pushed by another avatar/object this latency increase does not occur.
If I push any directional key (up, down, left, right, w,a,s,d) it happens most of the time (see below)
There seems to be a correlation between the framerate staying <50fps, and therefore within the limits of the ctrl-shift-1 status bar graph, and pings remaining normal.
If the fps goes outside this graph limit (>50fps) a 2200 ping rapidly accumulates.
PGUP/PGDN do produce the same effect, but seem to be less fast to accumulate a high ping, and only get to about 1500ms. (I haven't t tested this much)

I'm very pleased that recent RCs seem to have have increasing framerates.. i hope this possibly related ping issue can be resolved without adversely affecting these fps improvements.
//==================================
SL Video settings all on custom absolute maximum.
Desktop video settings on 'Quality' bias
AA*8x, VBO and AF on, 1024Mb assigned texture memory, and typically getting between 60-110 FPS in the sims i am usually working in.
512/128 DSL connection that produces a stable 420/115Kbps in every test i have done over the last year or two.
SL is bandwidth capped in preferences at 320kbps
//==================================
[Display]
Processor: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2405 MHz)
Operating System: Microsoft Windows Vista x64 (Service Pack 1)
DirectX version: 10.0
GPU processor: GeForce 8800 GT
ForceWare version: 175.16
Total available graphics memory: 2304 MB
Dedicated video memory: 512 MB
System video memory: 0 MB
Shared system memory: 1792 MB
Video BIOS version: 62.92.16.00.92
IRQ: 16
Bus: PCI Express x16

[Components]

nvCplUIR.dll 1.5.1200.00 NVIDIA Control Panel
nvCpl.cpl 1.5.2400.10 NVIDIA Control Panel Applet
nvExpBar.dll 1.5.2400.10 NVIDIA Control Panel
nvCplUI.exe 1.5.2400.10 NVIDIA Control Panel
nvViTvSR.dll 7.15.11.7120 NVIDIA Video and TV Server
nvViTvS.dll 7.15.11.7516 NVIDIA Video and TV Server
nvDispSR.dll 7.15.11.7120 NVIDIA Display Server
NVMCTRAY.DLL 7.15.11.7516 NVIDIA Media Center Library
nvDispS.dll 7.15.11.7516 NVIDIA Display Server
NVCPL.DLL 7.15.11.7516 NVIDIA Compatible Windows Vista Display driver, Version 175.16
nvGameSR.dll 7.15.11.7120 NVIDIA 3D Settings Server
nvGameS.dll 7.15.11.7516 NVIDIA 3D Settings Server
//==================================
Second Life 1.21.3 (97611) Sep 24 2008 17:11:26 (Second Life Release Candidate)
Release Notes

You are at 244817.1, 294041.9, 26.9 in Vox located at sim7306.agni.lindenlab.com (8.10.146.54:13002)
Second Life Server 1.24.6.97433
Release Notes

CPU: Intel Core 2 Series Processor (2405 MHz) <-- Quad core
Memory: 5375 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8800 GT/PCI/SSE2
OpenGL Version: 2.1.2

libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3
J2C Decoder Version: KDU
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.18488 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 288/288623 (0.1%)
//==================================


BETLOG Hax added a comment - 06/Oct/08 06:56 AM
This is still an issue in new server version.
Second Life 1.21.4 (98167) Sep 30 2008 15:28:25 (Second Life Release Candidate)
You are at 244755.9, 294126.0, 35.2 in Vox located at sim7306.agni.lindenlab.com (8.10.146.54:13002)
Second Life Server 1.24.9.98659

BETLOG Hax added a comment - 07/Oct/08 07:47 AM
Moy Loon pointed out that there is a way to slow the Sl clients framerate somewhat using debug setting:
yieldTime
Setting mine to 10 lowers my framerate enough to be tolerable, and makes the apparent latency from moving much more reasonable.

Also, Zwagoth Klaar pointed out the section of code that is likely responsible/involved... and suggested he would submit a patch for it once he has a change to investigate it further.

Hopefully this is useful to those afflicted, and will result in a more central fix.


mart ceriano added a comment - 31/Oct/08 03:27 AM - edited
ahh same here
Brand new computer - Asus core Duo T9300 Nvidia 9500M GS with latest driver, running Vista Ultimate on a 512/128 adsl .

even IM chat stops after about 4 sentences backwards and forwards.

I dont know how to log sl
Dont know how to change vista framerate so it will work .

So I am just logging back in every 2 minutes , its been like this for about 10 days since I joined second life. Freezes and chat stops.

Can usually turn avatar, but cant walk , within 1 minute. Then chat stops within 2 minutes,

I thought it was just 512/128 was too slow, so I have applied to upgrade, but the deal I am on, in two locations, says I have to wait 3 weeks to upgrade (I know, its a pain)

So please tell me how to step by step alter the frame rate so its XP compatible or whatever will get me so I can play till 3 weeks are up.

Then should I try and make it vista compatible when I get 1500/256 in 3 weeks time?

Sorry, I dont know where to adjust frame rates (new to sl) Great game by the way!

ps I changed the properties in the programme ro XP SP 2 but didnt seemto change the way thegame plays for me - do I have to reload SL onto computer overthe top as well, and run in XP SP 2 mode?

IF so, does this mean thet if you are on 512/128 xp mode is the only solution for SL on a Vista Ultimate machine?

Will SL run on 1500/256 without having to go to all this trouble? Or will it still require XP SP 2 mode?

Couldnt a patch be made to change the mode it runs on (SPsp2 or Vista) on the fly in SL ?

Surely there are a lot of Vista machines on 512/128 by now, well, in Australia ther are, our Broadband plans are pretty slow compared to a lot of other countries

Also is the lag much more in countries like Australia?

Can you use load balancing servers in other countries to decrease ? (I am not a techo, so be gentle, its just something I heard of someone)

Cheers - Marty (Australia)


Ellla McMahon added a comment - 31/Oct/08 08:00 AM
Marty, for account-specific help please post a Ticket with Support http://secondlife.com/support/

Please see these articles in Knowledge Base

Knowledge Base > Second Life Info > Solution Finder > Technical Issue > I have a lot of lag. How can I improve performance ? Topic #: 4051-4207
http://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=4207

Take a look at the graphics settings in the Preferences window if you haven't already. Try moving the Quality and Performance slider to Low.

You might need to turn your bandwidth settings down in the Preferences window if your computer is receiving more network data than it can handle.

Knowledge Base > Second Life Info > Second Life Software Questions > How do I check for packet loss (network lag)? Topic #: 4051-4237
http://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=4237

Knowledge Base > Second Life Info > Solution Finder > Technical Issue > Is my firewall responsible for problems with Second Life? Topic #: 4051-4353
http://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=4353

Turn off WindLight rendering http://wiki.secondlife.com/wiki/Turn_off_WindLight_rendering


If you still have this issue,

  • please add your full computer environment Help > About Second Life
  • please close Second Life and before you restart, please attach your latest SecondLife log and Crash Report

Knowledge Base > Second Life Info > Solution Finder > Technical Issue > Where do I find my Second Life diagnostic logs? Topic #: 4051-4209
http://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=4209

Thank you : )


BETLOG Hax added a comment - 31/Oct/08 07:27 PM
No offence Ella, but I don't think you understand.
Mart: it appears this issue is caused by the fact that Sl has a chunk of code that bases its network transmission of avatar movement packets on the clients framerate. This means that although we all like high framerates, in this particular case its not a good thing. The combination of our relatively low bandwidth and higher pings means that increasing our framerates actually chokes the transmission of network data.
So while doing what Ella suggested IS a good idea, its also probably going to exacerbate this particular problem.

My previous post outlines a temporary fix for the problem, but you will need to experiment with the numbers that work best for you, and relog each time you try a new yieldTime setting. I'd suggest starting with the values i quote above.

I suspect this issue isnt being addressed because people with a little more bandwidth or in the US simply wouldnt trigger it, and the rest of us just think huge lag spikes are normal for SL. This isnt normal.
Iv'e seen the chunk of viewer code that seems to be the culprit, and everyone I know who has seen it has said words to the effect of: "WTF are they thinking?!"
There must be a good reason for it to be this way, and its probably tangled up with all kinds of other bits of voodoo code.

Many people would say "just get a bette internet connection"... but really, this chunk of code is absurd. And why do we need more than 128kbps just to move in SL?

BTW, using voice when you move will still trigger this problem, regardless of your yieldTime settings, but again... 32kbps for voice is fair, but that implies that movement in sl at fps higher than about 50 uses up more than 96kbps simply to tell the sim you are changing position or rotating. Thats ridiculous.


Darius Lehane added a comment - 31/Oct/08 10:22 PM
Ella, to resolve this issue I tried every possible preference setting (and this originally occured before windlight). This issue is not a matter of changing some settings, it is a fundamental defect in the client. In fact when I use the identical computer on a higher bandwidth connection the problem does disappear, so I do think BETLOG Hax has some useful ideas. On a related note, resolving this problem may actually reduce overall congestion on the network, both for the client and for LL's servers.

Darius Lehane added a comment - 31/Oct/08 10:28 PM
Just to clarify the problem: low bandwidth connections on a faster machine will cause debilitating lag.

If you try and replicate the problem on a high-bandwidth connection it will not occur. Linden Labs engineers will not be able to replicate this at all locally unless they have a method of throttling bandwidth to simulate DSL.

Low bandwidth + fast framerate == bad lag.

P.S.: I'm a software engineer and work on systems like this, I'm quite thorough


Darius Lehane added a comment - 31/Oct/08 10:31 PM
P.P.S.: also no offence Ella, but asking people to try all these settings and send machine information is a waste of people's time and your time as it will not tell you anything. Just create a method of throttling bandwidth, get a fast machine, and you will replicate the problem.

BETLOG Hax added a comment - 01/Nov/08 12:38 AM - edited
When appropriate, update agent location to the simulator.
F32 agent_update_time = agent_update_timer.getElapsedTimeF32();
BOOL flags_changed = gAgent.controlFlagsDirty() || (last_control_flags != gAgent.getControlFlags());

if (flags_changed || (agent_update_time > (1.0f / (F32) AGENT_UPDATES_PER_SECOND)))

{ // Send avatar and camera info last_control_flags = gAgent.getControlFlags(); send_agent_update(TRUE); agent_update_timer.reset(); }

...........
if (force_send ||
(cam_center_chg.magVec() > TRANSLATE_THRESHOLD) ||
(head_rot_chg < THRESHOLD_HEAD_ROT_QDOT) ||
(last_render_state != render_state) ||
(cam_rot_chg.magVec() > ROTATION_THRESHOLD) ||
control_flag_change != 0 ||
flag_change != 0)
{
[7:32] Zwagoth Klaar: the keyboard dirty flag is set whenever a key is pressed
[7:32] Zwagoth Klaar: regardless of if it changes anything or not
[7:32] Zwagoth Klaar: another bug
[7:32] Zwagoth Klaar: but thats the true cause
[7:32] Zwagoth Klaar: void LLAgent::setControlFlags(U32 mask)
{
mControlFlags |= mask;
mbFlagsDirty = TRUE;
}
[7:32] Zwagoth Klaar: That code is faulty

...Thanks Moy.. Zwagoth.

Apologies for the edit & subsequent email respam.


mart ceriano added a comment - 01/Nov/08 06:08 AM - edited
ok ,thanks to all

"Moy Loon pointed out that there is a way to slow the Sl clients framerate somewhat using debug setting:
yieldTime
Setting mine to 10 lowers my framerate enough to be tolerable, and makes the apparent latency from moving much more reasonable"

How do I do that - seems like a good temp fix till SL gets a patch or fix or option going.

I would love to do that and set it to 10 if I just knew how. .

where do I find the Debug Yieldtime

Then is it in code I can see, and how do I set it to 10 (I can change a code setting if Iknow where to look)

Ella: This seems to be more helpful than login a ticket, and will also serve a purpose for anyone else with a replica problem , as a public record for people to google and find the fix. After all, the problem has been around for a long time. So far I implemented your changes , and even removes second life altogether , reloaded as in XP compatibility mode etc and all to no avail - so I will do as the others suggest and will post result when I know how to change the setting to 10

Thank ..Marty

somewhere here mabe ? C:\Program Files\SecondLife\app_settings

how about here;

<key>YieldTime</key>

  • <map>
    <key>Comment</key>
    <string>Yield some time to the local host.</string>
    <key>Persist</key>
    <integer>1</integer>
    <key>Type</key>
    <string>S32</string>
    <key>Value</key>
    <integer>-1</integer>
    </map>

am I figuring the <string>s32</string> should become s10? Is this correct ? lower case s

Can I do this edit in Notepad , and do you change the setting to Unicode or UTF-8 instead of Ansi?


BETLOG Hax added a comment - 01/Nov/08 09:11 AM
The code i pasted in my last post is just to show where in the client code the problem probably lies...
The post where i mention yieldTime is a debug setting... accessible in the SL client, via the 'Advanced' menu
(the 'Advanced' menu can be toggled on and off with ctrl-alt-d ...if i remember correctly)

mart ceriano added a comment - 02/Nov/08 10:56 PM
Hi Betlog Hax

Thanks - It was Ctrl-Alt-D

1st log in to Second Life, then Ctrl-alt -d

Then the advanced pops up at the top click onto advanced and near the bottom is Debug settings look for Yield time.

Default was -1

Changed it from -1 to 10 in the Debug / yieldTime and seems a little better. Still get kicked off regularly, but sometimes now can go for 10 minutes instead of 90 seconds.

Still get freezes when in a house with two people but its better than what it was.

Haveapplied to upgrade from 512/128 broadbandto 1500/256 so taht will happen in two weeks time an we will see what else needs to be done if anything after that.

So far have had to update 9500M gs Nvidia driver as only other issue.

Thanks for your help so far and will post back when I get results of Bband upgrade

Cheers - Marty


Steve Brumer added a comment - 17/Nov/08 04:53 AM
Hi all !

I did not notice the high bandwith usage of the SL viewer with high frame rates, but I also want to add a FPS limiter to avoid GPU heat and noise for useless frames, so just avoid waste. Graphic driver VSync is not enough since you can only limit the framerates to the screen refresh rate: 60Hz/60FPS for example. So I also use the yieldtime but with the command line parameter (--cooperative <ms to yield> ):
https://jira.secondlife.com/browse/VWR-10077 (thank you for your votes !)

The problem with the yield is that it always reduces the framerate, even when the framerate is already low. I just don't want to worry about this depending on what I am doing... visiting a popular and heavy sim or building in a skybox. That's why I asked for a limiter (a maximum), to keep the performance high when needed and only avoid the rendering of useless frames. I think such a limiter would be much easier to use than the yieldtime or a driver VSync option. In fact, a FPS limiter can be made by calculating a new yieldtime each second. If FPS is high, the function would increase the yieldtime. If FPS is low (under the limit), it would remove the yieldtime. It's just an idea for the viewer dev team.

Cheers


Zwagoth Klaar added a comment - 21/Nov/08 06:02 PM
majority of the problem is related to how controls are send and updated. In llagent.cpp we have the following.

//-----------------------------------------------------------------------------
// setControlFlags()
//-----------------------------------------------------------------------------
void LLAgent::setControlFlags(U32 mask)
{
mControlFlags |= mask;
mbFlagsDirty = TRUE;
}

as well as
//-----------------------------------------------------------------------------
// moveAt()
//-----------------------------------------------------------------------------
void LLAgent::moveAt(S32 direction, bool reset)
{
// age chat timer so it fades more quickly when you are intentionally moving
ageChat();

setKey(direction, mAtKey);

if (direction > 0)

{ setControlFlags(AGENT_CONTROL_AT_POS | AGENT_CONTROL_FAST_AT); }

else if (direction < 0)

{ setControlFlags(AGENT_CONTROL_AT_NEG | AGENT_CONTROL_FAST_AT); }

if (reset)

{ resetView(); }

}

moveAt() is run when you move forwards. Here is our logic problem. setControlFlags sets the control flags as dirty regardless of if they change, and the movement functions always use the function setControlFlags.

in llappviewer.cpp we have

static LLFrameTimer agent_update_timer;
static U32 last_control_flags;

// When appropriate, update agent location to the simulator.
F32 agent_update_time = agent_update_timer.getElapsedTimeF32();
BOOL flags_changed = gAgent.controlFlagsDirty() || (last_control_flags != gAgent.getControlFlags()); <-- this is ALWAYS true if you are pressing any movement key.

if (flags_changed || (agent_update_time > (1.0f / (F32) AGENT_UPDATES_PER_SECOND)))

{ // Send avatar and camera info last_control_flags = gAgent.getControlFlags(); send_agent_update(TRUE); <-- This true forces an update to be send even if nothing has changed, even past the number of packets to send per second. agent_update_timer.reset(); }

So, here is the cause of our flooding bandwidth when moving at high framerates.

fix? easy.

Turns out there are quite a few broken functions here contributing to this bug. (Not to mention that the control flag change test is run 3 times, but never is it useful due to some poor planning.


Zwagoth Klaar added a comment - 21/Nov/08 06:13 PM
Added patch.

shirlee iuga added a comment - 10/Jul/09 09:01 PM
Viewer 1.22.11 and 1.23.4 and still got that problem.

Windows XP Pro SP3
3.2 GHz Athlon X2, 4GB 1066 DDR2 RAM, Geforce 9800GT.
FPS from 40 to 80, depending on rendered Szene.

Upload Bandwith (100-128kbits minimum) is used up completely due to those high frame rates and ugly programing. of that viewer.


BETLOG Hax added a comment - 11/Jul/09 01:09 AM
I haven't had this problem for months. Still don't.

Enable the texture load debugger with ctrl-shift-3 and make sure you arent just seeing bandwidth due to loading images.
...or maybe some moving physical butterflies/birds or stupidly scripted object... or any one of a million other evil things SL users make which eat bandwidth.
eg: http://www.sluniverse.com/pics/AlbumView.aspx?id=2226

IMO this issue should be closed, unless its resurfacing in newer versions.
But considering I'm using current RC 1.23.4.57987 and 1.23.4.123908, and 1.24.4.126103 trunk... I 'm pretty sure it's gone in these releases.


shirlee iuga added a comment - 11/Jul/09 05:24 AM
This is not a download bandwith problem, if you have really high fps (way above 50 fps) it is your upload bandwidth that becomes saturated.

You can have download bandwidth usage as low as 100 kbit/s, and you may initially be able to move a little bit without lag. But if you do press down "forward button" for more than just a few seconds, you still get serious lag and up to 192 kbits upload bandwith usage within seconds.

This problem shows up on a 2MBit down / 192 kbit upstream internet connection (standard ADSL internet connection in Germany) , but same computer on a 2Mbit down/ 2 Mbit upstream connection (SDSL Business connection in Germany) does not have any problems. Setting "yield time" to 10 or 15 also does help.

Try using 1.23.4.123908 on a high performance WindowsXP SP3 or Windows Vista machine in an empty water sim (like Leipzig) with high framerates on a bare avatar (no attachments at all, no scripts running etc.). I can still reproduce that problem here: Everyting is fine until you start moving around.


BETLOG Hax added a comment - 11/Jul/09 06:18 AM - edited
With SL windowed, but maximized, graphics set to minimum, AA and AF off, FPS maxed at 60. (A limitation of my screen's max refresh rate)
.....Moving makes no real difference to my bandwidth at this FPS.
I get identical FPS results with graphics settings on Ultra (and a 64m drawdistance just to keep it simple)

With screen resolution lowered and refresh rate thereby increased to 75 Hz I see a few very momentary spikes in bandwidth, up to about 120kbps... and running on the ground with FWD and RIGHT or LEFT pressed consistently shows about 20kbps.
Flying straight up or down does not seem to show even the momentary bandwidth spikes at all.

With SL in fullscreen mode I don't see the momentary 120kbps spikes whatsoever.

This monitor can't produce more than 75Hz, so i am unable to fully confirm your observations.

So like you said: only exceptionally high FPS seem to be affected.
...I'm thinking that will mean it's 'fixed' for the 99th percentile of users.

Second Life 1.23.4 (123523) Jun 9 2009 08:32:14 (Second Life Release Candidate)
Release Notes

Built with MSVC version 1400

You are at 260479.9, 256640.0, 35.2 in Leipzig located at sim4609.agni.lindenlab.com (216.82.55.5:13002)
Second Life Server 1.26.4.120562
Release Notes

CPU: Intel Core 2 Series Processor (2405 MHz)
Memory: 6143 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8800 GT/PCI/SSE2
Windows Graphics Driver Version: 8.15.0011.8585
OpenGL Version: 3.0.0

libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.25286 (Mozilla GRE version 1.8.1.21_0000000000)
Packets Lost: 378/6083 (6.2%)