Jump to content

Andrew Linden

Retired Linden
  • Content Count

    29
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Andrew Linden

  • Rank
    Member
  1. Nalates is correct. The way I would put is this: The viewer measured ping time includes the time it takes for the viewer to get around to processing the network packets. Although a packet may have already arrived at the ethernet port and is sitting in the queue, its "arrival time" is measured when it is actually processed, which is done in the same thread as the render work.
  2. I just finished coding up a fix for this bug, and it should work for all ghosted region boundary objects. It will have to get tested and bundled into a server update so the earliest it could hit RC would be around 2013.10.09.
  3. I have a fix for this but it didn't make it in time for this week's update (for unrelated technical problems). It is currently deployed to the DRTSIM-208 channel on the beta grid (aditi) which includes the region "Gibson" if anyone wants to check it out. Antony Fairport, who first reported this problem in a jira issue, has tested it and has verified that it works.
  4. This is the first I've heard of an "invisible avatar" problem. We'll be needing some details to investigate, such as the region name, time of event, would couldn't see who and where they were standing when it happened. Ideally this info would be put into a jira issue where the investigation could be tracked (rather than putting it in this thread). BTW, it occurs to me that there is a feature where a parcel owner can specify that people outside the parcel cannot see people inside, and visa-versa. I wonder if one of the parcels in the club is misconfigured with this option. BTW, one way to test this is that when anyone driving a vehicle wanders into such a parcel the whole vehicle should disappear.
  5. Turns out my theoretical fix did not work, but I did get some clues today that I hope will help me figure it out.
  6. Yes, the problem only affects people with certain internet connections. In particular connections that suffer UDP packet loss at relatively low bandwidth settings. Doing a normal HTTP download speed test on such a connection may indicate a higher bandwidth than is supported for UDP traffic -- TCP traffic may be treated differently than UDP. The workaround is to lower you SL viewer bandwidth settings in the preferences. The one resident who tried this was able to make the scripts load at 350kbps or lower. This will not necessarily degrade your SL experience as much as you might expect. The bandwidth setting only applies to UDP traffic -- HTTP traffic (which includes texture downloads) automatically adjusts itself to shat your connection can handle and is not regulated by the setting. I've got a theoretical fix for the problem but am having trouble reproducing a UDP restricted environment to test it. I've temporarily deployed the experimental server to the Gibson region on the beta grid. If anyone would like to test it there I will help by getting your account imported to the beta grid.
  7. Yes Ciaran, that sounds like the same thing. To really see it in action you would crank your viewer bandwidth settings down to a few hundred kbps, then turn away from a big crowd of Dwarfins, wait several seconds for the Dwarfins to move around, then turn around very quickly so they are all in view. The low bandwidth settings will cause a significant amount of time to pass before all of the linked pieces to get updated correctly.
  8. I logged into to Ruiz/159/80/1502 as per the instructions in BUG-1779 and finally noticed what you're Levio is talking about. For me it was rather hard to see becuase most of the meeroos would snap together pretty fast, but I dropped my viewer bandwidth settings down to 300kbps (from 1Mbps) and could reproduce it much easier. Each visible part of a meeroo is a child-prim. The root is an invisible prim that typically doesn't actually move when the meeroo sits down or stands up -- each child prim moves to a new local transform to produce the effect of motion to a new stance. The problem is that each prim is being scheduled independently of the others so they arrive out of order, and may be incorrectly sorted so that some for one meeroo will arrive much later than others for the same animal. Hrm... I will ponder how to fix this.
  9. @Pierre - No, reducing your cache size will not help. That setting just controls how much hard drive space you are willing to devote to the cache, and in this context includes both the texture cache and the object cache which are stored in separate formats and different locations. It doesn't control how big each per-region object cache file will be, just how big of a filing cabinet you have for those files. A workaround was mentioned earlier in this thread. Something about "flipping alpha masks and atmospheric shaders settings". If that works then it seems like the best workaround that I know of. Another theoretical workaround (assuming that this really is a bug in the viewer cache retrieval system) would be to manually delete the object cache files before login. By deleting these files out from under the viewer you will force the server to re-send the cacheable data without clearing your texture cache, which is the real bandwidth saver. If the objects still don't show up right then the viewer bug isn't in the cache retrieval system, but is in the render code itself where it figures out what should be in the render pipeline. The object cache files live in different places depending on your operating system. For Windows XP I happen to know that they live in C:\Users\$USER\AppData\Local\SecondLife\objectcache\ and have names of the form: objects_1001_1200.slc.
  10. "But why is the client suddenly having a problem it didn't have two months ago? " What has changed is that the server is now treating much more content as "cacheable". The server's definition of cacheable used to be something like: "is static and does not have a script". The new definition of cacheable is: "has not changed position or appearance in the last couple minutes". The viewer bug must exist inside the code that retrieves object data from cache and is more noticeable now because the viewer-side object cache tends to be bigger. I've brought the problem to the attention of one of the developers who is working on some viewer-side changes that will compliment the next server-side interestlist changes (*), so we hope to figure it out soon. (*) The server will soon support two hints from the viewer: (1) "I don't have an object cache file for this region at all" --> the server will then be able to bypass some of the initial "cache probe" messages of the protocol which looks something like this: Viewer: Hello, I would like to connect. Server: You are connected. Server: Do you have cache for object 123 whose version is 456? Viewer: No, I do not have cache for object 123. Server: Here is the data for object 123. Under the new system: when visiting a region for the first time the conversation will look more like this: Viewer: Hello, I would like to connect, and BTW I can tell you right now that I have no cache. Server: You are connected. Server: Here is the data for object 123. (2) "I'm willing to cache ALL object data in the region, including stuff that is too far away or too small to see" --> the server will eventually stream all cacheable data to the viewer, including sky boxes far above. It sends the non-visible data with a delay so that if you're flying through the region on a jetpack and leave soon after arriving you won't get the extra data, and once it starts sending the non-visible objects it will be in a lazy fashion -- lower bandwidth than when sending what is in front of you.
  11. I can explain why the avatar bounces when you raise the terrain under its feet: The terrain info is stored in two formats: (1) a 2D array of floating point heights (a "heightfield") that is used for visualization and (2) a big list of triangles (a "mesh") which is used fo collision purposes. Whenever you modify the terrain you are actually changing the heightfield data (1), which then must be translated into mesh form (2) before you avatar can collide with it. The conversion to mesh is computationally expensive and can take a significant amount of time to complete. To reduce lag caused by the mesh calculation the simulator employs two strategies (a) it waits several seconds after the last terrain modification just in case the person editing it is going to make another change (no need to compute the mesh if it is about to change again) and (b) it performs the mesh calculation on a separate thread, which allows the simulator to continue moving things along in the meantime. The mesh format was added to help optimize the physics engine. It is faster than a heightfield shape for collisions in general and most ray-trace events, however the benefits of going to mesh did not outweigh the work required to get it done... until we added the pathfinding characters. The performance improvements for computing paths over a mesh shape is much much better than doing the same for a heightfield collision shape, hence the work was done. So, when you make a change to the terrain it can take several seconds for the collision shape to update, but why does the avatar bounce? There is special code in the simulator that checks to see if your avatar is under the terrain. If it finds this to be true then it will lift your avatar to the surface. Unfortunately the code that performs the underground check is still using the heightfield data rather than the mesh data. The way to fix it would probably be to perform a ray-trace up against the terrain mesh from the avatar's feet and then if the ray hits the terrain we'd know the avatar's feet were actually below the mesh. In the meantime... don't stand where you're raising the terrain.
  12. The problem was caused by the new interestlist code which tries to not subscribe to objects that are outside of the camera view. When crossing a region boundary your viewer would extrapolate your camera forward, the vehicle would be created behind the camera, and the server would not subscribe to it. The faster the vehicle the more likely this would happen. The solution was to special case interestlist subscription to whatever you're sitting on -- the server now ALWAYS subscribes to your seat. We already had some special case code for seats, but it needed a little more.
  13. Janet, you mention that your cache is maxed, which sounds like you're talking about the cache on your local filesystem (hard drive), which can be configured to be large or small. I was talking about storage in memory (RAM). The viewer will take a lot of RAM, but there are limits to what it can get -- the rest of your operating system and other applications also need RAM to function. Also, there is special RAM in your graphics card which is also limited. If you are in a texture-heavy region (many large unique textures) then it may be that the viewer cannot hold all those visible AND those behind you, so it will swap out non-visible textures behind you to make room for the stuff it is trying to show in front. Also, it probably doesn't do all of this switching at once because it takes time to sort through and move lots of data around and to do so in one solid chunk of work would cause your render frame rate to block for a significant fraction of a secondb -- a big lag event. The work is probably parceled out across multiple frames so the scene will update in a timely fashion -- less lag over a longer period. You might try reproducing the problem in a region with lots of objects but much fewer textures (a big build still in its plywood stage). You might also try to discover how much memory is on your video card and consider testing the texture-heavy scene on another system with a higher-grade graphics card (if you have access to such).
  14. After looking through the SL UDP packet code a bit more I have a little better understanding of how it works than last time I spoke about it. I learned that when we actually pack data for a UDP packet we limit the payload to 1200 bytes. We're aiming for a max of 1500 bytes for the entire packet, counting UDP header and some ACK information that we add to the end of the normal 1200 byte payload, so we leave 300 bytes for that stuff. Once the final payload is computed (including the initial data and postpended ACKs, but not including the UDP protocol header) we check the size and print a WARNING to logs if it exceeds 1500 bytes, but we send it anyway. This is a little bugged. We should be checking for "data_length > MTU - UDP_header_size" at this point. This wouldn't be hard to fix -- a little googling reveals that UDP_header_size = 64 bytes. However the question is: when aiming for 1200 byte payloads, what is the maximum size of the true packet? Most of SL's packet types easily fit into just a few hundred bytes, but the ones that stream object data are packed to the maximum -- if we're ever exceeding an MTU then it would occur when packing those. I suppose I should survey the maximum packet sizes of a typical connection to a very full and busy region to see how big they are getting and if we are exceeding 1492, or maybe 1456, then maybe we should aim lower than 1200 bytes. The UDP packet size bug that was affecting Magnum last week would cause payloads to go over 3000 bytes! Interestingly most network routing hardware would transparently split these packets and reassmble them before they arrived at the client computer but not all -- some people were seeing terrible packet loss. If we are occastionaly exceeding the true MTU of some connections then most people wouldn't be affected but it might show up as a steady background of packet loss for a few.
  15. Janet, what you're describing sounds like a behavior of the viewer. It is probably performing a lazy scan for textures that are not being rendered in view and slowly unloading those from memory -- in an effort to prepare the memory for any new textures that might show up, and to help keep your render frame rate high. This is definitely not related to the server delaying updates for objects behind you since these objects are not chaning and thus would not be getting updates anyway.
×
×
  • Create New...