|
|
|
[
Permlink
| « Hide
]
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.
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.
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 Second Life 1.18.4 (3) Nov 19 2007 15:02:01 (Second Life Release)
************************************************************************************ CPU: Intel Core 2 Series Processor (2399 MHz) 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 - 27/Nov/07 03:23 AM comment.
Can't someone do something about this?
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. 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. [Components] nvCplUIR.dll 1.5.1200.00 NVIDIA Control Panel You are at 244817.1, 294041.9, 26.9 in Vox located at sim7306.agni.lindenlab.com (8.10.146.54:13002) CPU: Intel Core 2 Series Processor (2405 MHz) <-- Quad core libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 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 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. 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 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) 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
Knowledge Base > Second Life Info > Second Life Software Questions > How do I check for packet loss (network lag)? Topic #: 4051-4237 Knowledge Base > Second Life Info > Solution Finder > Technical Issue > Is my firewall responsible for problems with Second Life? Topic #: 4051-4353 Turn off WindLight rendering http://wiki.secondlife.com/wiki/Turn_off_WindLight_rendering If you still have this issue,
Knowledge Base > Second Life Info > Solution Finder > Technical Issue > Where do I find my Second Life diagnostic logs? Topic #: 4051-4209 Thank you : ) 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. 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. 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.
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 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.
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(); }........... ...Thanks Moy.. Zwagoth. Apologies for the edit & subsequent email respam. ok ,thanks to all
"Moy Loon pointed out that there is a way to slow the Sl clients framerate somewhat using debug setting: 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>
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? 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) 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 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> ): 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 majority of the problem is related to how controls are send and updated. In llagent.cpp we have the following.
//----------------------------------------------------------------------------- as well as 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; // When appropriate, update agent location to the simulator. 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. Viewer 1.22.11 and 1.23.4 and still got that problem.
Windows XP Pro SP3 Upload Bandwith (100-128kbits minimum) is used up completely due to those high frame rates and ugly programing. of that viewer. 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. IMO this issue should be closed, unless its resurfacing in newer versions. 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. 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. 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. Second Life 1.23.4 (123523) Jun 9 2009 08:32:14 (Second Life Release Candidate) 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) CPU: Intel Core 2 Series Processor (2405 MHz) libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
High Framerates on Windows Vista causes very large network lags
