Jump to content

Andrew Linden

Retired Linden
  • Content Count

    29
  • Joined

  • Last visited

Everything posted by Andrew Linden

  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
  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. Th
  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 t
  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
  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 t
  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
  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 b
  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 WARN
  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.
  16. @Triple -- Thanks for the update. I think the fix to the UDP packet acks would drop your bandwidth from the terrible 1GB/H back down to the normal 5MB/H. Improvements beyond that must be attributable to other changes. Some of the lower bandwidth you're seeing is the lack of packets updating the old cloud density layer (now gone), and a slower update for the wind layer, however I estimate the savings there to be only about 0.15 MB/H. A possible source of savings would be from the improved server-side culling of updates for objects that are not visible. If there are any objects that are mov
  17. Triple, with some details about the problem from Latif Khalifa I believe was able to find the real problem in the server that is sending so much data to libOpenMV bots, and probably too much data to regular viewers as well. The SL UDP protocol appends ACKs for recieved packets on the end of outgoing packets that have extra room. Meanwhile some of the UDP packets are "zero coded" which is a simple compression scheme sometimes applied to packets that have large blocks of zeros. The bug (if my understanding of the code is correct) affects ACKs on the end of zero coded packets -- those ACKs may
  18. I belive I've found the problem. There is a bug in our size calculation of the ObjectUpdate message that is causing us to send packets that are larger than an ethernet MTU (1500 bytes). So the current theory is that most network connections can handle such packets by breaking them up into smaller packets that fit their protocol and then reassemling them on the other side, however some connections must fail to do this. We're going to update some regions for test on the beta grid (aditi) with the new code. I believe Morris and Ahern will be included in this set.
  19. Sorry Jessica, I didn't mean "hack" in any pejorative way. I meant it as a "solution to a problem using unexpected methods or tools" -- I'm definitely not against such "hacks", and I was quite intrigued with this TPV innovation when I heard about it years ago. For some people "hack" has a negative connotation, so perhaps a better word would be "workaround" since the expanding draw distance feature is to reduce a "bug" that is external to the viewer, namely the poor near-to-far sorting by the server. Meanwhile, I've been thinking about the symptoms and also reviewing some of the changes in th
  20. Thanks for the info everybody. Firestorm is off the hook -- it has been tested and works for some people, so the source of the problems must lie elsewhere. I've got a theory about the bot problems and a corresponding fix lined up for next week. The problem is that the current simulator on Magnum will initialize the viewer's camera as having a zero draw distance when they first connect to the region. It expects the SL client to send a non-zero draw distance in the AgentUpdate messages, but some bot implementations may specify zero draw distances. One might expect that a zero draw distance
  21. We ran one test with Firestorm from a residential connection but were not able to reproduce the problem. The test involved teleporting from pointA to pointB and back to pointA to see if all the pile of scripted objects in pointA would all show up on return -- they did. We noticed that the content took longer to show up in Firestorm, whereas it shows up almost immediately in the official SL client. I wonder if Firestorm is using the a gradually increasing draw distance hack to help content get sorted near to far? I've heard rumors of this feature in TPV's but do not know if Firestorm is usin
  22. If someone could send me a landmark to a region or skybox where these problems are showing up I'd appreciate it. I'm going to check out Lusk to see if I can witness any of Ardy's reports. Tiple, I don't think Sky's problem is related to bots since that region is usually empty. Sky, your region on the Magnum channel is public, but you've got some parcel setting that prevents teleports. I'm going to temporarily add myself to the Estare access list so I can look around to try to reproduce the problems.
  23. Sky - I'll number your symptoms so we can specify: (1) Objects and avatars not showing up (2) Objects showing up but slowly (3) Slow fall through floor of skyboxes (this is about avatars specifically?) (4) Objects not updating position until they are back in camera view (5) Unable to open objects to view their contents Everything could be explained by a bad net connection except (4) which is known new behavior in the Mangum RC. I'm not positive that there was a network glitch, but some more info may be able to rule it out. Are symptoms (1)-(3) and (5) happening constantly or sometime
  24. Triple - I downloaded the LibOpenMetaverse code. It appears that libOpenMV's "bot" code is their "TestClient" program. I did some quick searches through the codebase for certain keywords and it appears that the TestClient does indeed support sending AgentUpdate messages, which makes sense since these messages must be sent if your bot is going to move around. However it is not clear whether a valid camera "Far" clip is sent in your case, or if it is sending zero. The values that are put into the AgentUpdate message depend on some config files. It makes sense to me that someone running a c
  25. Triple - I've been examining the code to figure out why the simulator might start sending lots of data to a bot. I think I identified one mode: if the bot never sends a valid AgentUpdate UDP message (which includes info about the camera's view angles and draw distance) then the server-side culling will be using some initialized values that might trigger resends of data. I'll change the initialized camera properties to be more sane defaults and try to get this out in an update, but if you happen to know if your bot implements the AgentUpdate message or not I'd love to hear back. At the mom
×
×
  • Create New...