Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by animats

  1. As I've suggested before for hardware problems seen only running Second Life, run the Unreal Engine 4 benchmark, "The Valley". This is a program to demo the features of the Unreal Engine game engine and exercise the CPU and GPU hard. It displays a large peaceful valley with trees and grasses. It will give you a tour of the valley, and it will run until stopped, reporting frame rate and GPU temperature. This will make your computer work much harder than SL does, and will run on most machines that can run SL. If The Valley will run for an hour, your machine should run SL without problems. If not, you have a hardware problem.
  2. Right. The sim code has a main loop - get info from viewers, do physics, do scripts, update world, tell viewers. Repeat. 45 times a second. That's currently single-thread, and if the sim is out of script time, it's using 100% of one CPU just to do that. When the sim runs out of CPU time, it first sacrifices pathfinding, then script time, then cuts the sim frame rate. Other stuff, such as rezzing, and (not sure about this) some of the bulk copying associated with teleports and region crossings, has been moved to other threads. Those need CPU time too. If there are other cores available in the same computer, that work can proceed in parallel with the main loop. A single sim can now use more than one core effectively. Under heavy load, a sim may now need more than one core. LL puts multiple sims on one computer. The usual allocation is supposedly 1 core for a full sim, less for homestead and open space sims. That may not be enough any more. LL really doesn't seem to have faced that. They're assuming that the sims on one computer will include some that need less resources than others, so that, across all the cores, there will be some spare CPU time. That assumption seems to have broken down. We've seen reports here of people restarting their estates repeatedly in hopes of being assigned to a computer with some spare time. That doesn't seem to work any more. The idle time just isn't there. This is a big problem for LL. Their business model has assumed that the compute load per sim will not increase. It's especially a problem with the planned move to AWS, where cost goes up linearly with the number of CPUs. Look at the "C5" instances, for heavy compute usage. If you buy your own machines, you get better price/performance if you buy more cores, but not on AWS. (AWS has to do this, or they'd get people buying big instances and subdividing them into little instances to undercut AWS's own pricing.) I wonder if LL management has thought this through. There are articles indicating that AWS is a huge financial lose for compute-bound services.
  3. Here's an experiment we might try to get LL to run. Find a region that's struggling with high script load. Copy the region to the beta grid, something which LL does for testing. Put it on a server with at least 2, preferably 4 CPUs, all by itself. Record load on that server. Invite people to visit the sim on the beta grid. Some tasks in the sim code, such as rezzing and sim to sim copy, have been moved off the main thread. That only helps if you have an additional CPU to run that stuff. It's entirely possible that a busy region now needs more than one CPU to run it properly. This needs to be tested and we users need to know. LL has sort of been assuming that one CPU per sim is a maximum, not a minimum.
  4. Yes. As you get the models close to realistic, other flaws become more obvious. Motion is next. SL could get photorealism easier than it could get better motion. Static photorealism is mostly rendering. That's pretty much figured out now. See "Principled BSDF", which is the Disney/Pixar standard for how to express surfaces. It basically has all the render layers you really need. They did this to simplify their in-house workflow, and it caught on. Blender supports it. High-end GPUs can now render it. All this stuff is viewer side. The server just has to tell the viewer, "render this in Principled BSDF mode, using these texture and mesh UUIDs." The viewer does all the rest. It's now mostly "how expensive a GPU do we require the user to get" and "how much bandwidth do they have for mesh and texture data"? The answer right now is "$500-$1000", and "Upwards of 100mb/s." Most SL users aren't there yet. The viewer has to do something reasonable when it doesn't have enough resources to render all that. That's a big headache in the viewer.
  5. Visit Crack Den or Hoodlum.
  6. I just discovered that, on Linux, the Firestorm viewer sends all its log message not only to "Firestorm.log", but to the system log. They accumulate in "/var/log/syslog", which many Linux systems keep for days to months. About 99% of the content of the system log is now Firestorm's routine logging. Syslog is supposed to be for major system problems. Is that on purpose?
  7. It's a known bug in the JIRA system that you can't comment on a JIRA entry by another person, even if you have "commentor" permission.
  8. Notes: In Firestorm 6.0.2 "Firestorm.log", during an upload, "WARNING #ColladaDom# llprimitive/lldaeloader.cpp(92) FSdaeErrorHandler::handleWarning : The DOM was unable to create an attribute xmlns:xsi = http://www.w3.org/2001/XMLSchema-instance at line 11. Probably a schema violation." WTF? The "_LOD2", etc. naming convention: This is apparently supposed to be for "Objects" in Collada files. "The viewer uses Name Based Matching to match objects from different LODs in the imported model files. The viewer looks for objects in your Mesh files ending with _LOD2, _LOD1, _LOD0, or _PHYS, and tries to match those object to Medium LOD, Low LOD, Lowest LOD and Physics respectively. If an object doesn't end in one of those, it will be considered for the High LOD. If the viewer cannot match the LODs this way it will resort to the old method of matching which is to rely on the order of the objects in the Mesh files." That's from this Linden Lab QA documentation, which may be a work of fiction. Looking in the Firestorm log, the names Firestorm's uploader uses for objects internally come from the name of the "Mesh" in the Blender sense (black and white inverted triangle in the hierarchy), not the name of the blender "Object" (orange inverted triangle in the hierarchy). Those seem to be the names that need the "_LODx" suffix. The Firestorm log has useful info for the infamous "Material of model is not a subset of reference" errors: isMaterialListSubset : Could not find material Step_top_matl-material in reference model Escalator_mesh matchMaterialOrder : Material of model is not a subset of reference. This would be much more useful if it was, like, shown to the user. Other good stuff in the Firestorm log: Importing Escalatorbodymesh_LOD2 model with 7 material references Escalatorbodymesh_LOD2 references Exterior-material Escalatorbodymesh_LOD2 references Footplates-material Escalatorbodymesh_LOD2 references glass-material Escalatorbodymesh_LOD2 references HandRail_000-material Escalatorbodymesh_LOD2 references Path_lights-material Escalatorbodymesh_LOD2 references Step_side_matl-material Escalatorbodymesh_LOD2 references Step_top_matl-material Importing Escalatorpartmesh_LOD2 model with 1 material references Escalatorpartmesh_LOD2 references Step_top_matl-material The uploader knows what it's uploading, which materials go with which meshes, and what's missing when it's unhappy. It even logs that info. It just won't tell the user. The pain for the user is designed in. Muahahaha!
  9. I'm thinking that, too. My home sim, Vallone, was restarted overnight, and performance has improved from 20% of scripts running to 60-90%. Pathfinding went up from 7% to 50%. Still at 4183 scripts. Too many sims on too few servers?
  10. The price increase on premium might be good for SL. Right now, you can do the land baron thing by buying premium memberships, cashing out the stipend, and using the tier to pay for land you rent out. You get 1024 m^2 of tier for about $6/year. This is not good for SL. With the price increase, the economics of that trick become much worse. We may see many of the marginal landlords drop out, and we may see less land hoarding of unrented land.
  11. It's not working right on the beta grid today. I uploaded the same .DAE files three times and got different link orders. Beq Janus, who's been working on the uploader in Firestorm, told me that there's a problem, and it's apparently upstream from her code. Apparently nobody does this much.
  12. The main conclusion from Server User Group today is that the developers have no idea what's gone wrong with SL performance.
  13. OK. How do I upload a linkset from Blender 2.79 using Firestorm 6.02 on Windows 7 and get the desired link order in Second Life? Looking around, I see bug reports, claims the bugs are fixed, and claims that the bugs aren't fixed despite what the Blender developers say. That's from 2016. What's the current situation? COLLADA export options The claim is that "Sort by object name" makes objects export in alphabetical order. But I've changed names to change the order and re-exported, and not had the link order change.
  14. It looks like you're running Firestorm in a virtual machine. Also, "OpenGL ... Mesa" means you're not using a GPU; the CPU is frantically trying to render the scene. And only 4MB on Windows Server 2016? What are you trying to do?
  15. Erected by the Vivid Route Initiative on Circuit de Corse. No idea who they are, or were. Anyone know? Circuit de Corse is one of the nicest drives in Second Life. This matters. Roads are important to SL. Go 100m inland from the road in Corsica and you're on abandoned land. Exactly. If you want isolation in SL, it's available. There are private landlords that will sell you a tiny island you can wall off from the world. If that's what you want, go there. The success of Bellesaria shows that many users want a social experience in SL. LL should encourage that on mainland. LL might offer a land swap for people who really, really want their ban line or giant backdrop. A free move to Outer Nowhere.
  16. That's a big problem in SL, and limits it as a social system. Multiple-size regions, as OpenSimulator has, would help. Sometimes you want smaller regions, so big events can distribute the load over multiple servers. I've been watching with interest the progress of the Spatial OS people, who claim to have a general solution to scaling a big simulated world. We'll see how that works out when Nostos, which is a big-world anime-like MMO, launches in China this fall.
  17. Yes. The original conception was brilliant. The things I want come under the heading of "making the existing features work right". Fix the sim side performance problems. Fix the region crossing problems. Fix the pathfinding problems. Fix the viewer side performance problems. Fix the shadow performance and accuracy problems. Fix the texture loading performance problems. Fix the level of detail system problems. Fix the "too many avatars in one region breaks the system" problems. Fix the mesh uploader problems. Fix the joystick/game controller interface. Every one of those is an open JIRA bug report, accepted by LL but not fixed.
  18. My test idle script is the one generated by the "New Script" button. Someone else tried the even simpler script with no "touch" event, with about the same results.
  19. One can hope LL has a handle on this. I'm focusing on this right now because 1) it's a big effect, 2) it's easy to measure, and 3) it happens even in sims where nothing scripted is happening. Personally, I'm annoyed because my animesh NPCs can no longer get anything done in my home sim, Vallone. Pathfinding breaks badly under script overload, because pathfinding has less priority than scripts. Only 5-7% of pathfinding steps are running. I've had my characters get stuck in walls, go off the parcel, go off the sim, and fall down the stairs. With enough recovery code, I can have them slow to a crawl, get out of the problems created by broken LL pathfinding, and eventually get where they are going. But at 1/20 of full speed. It takes them 10 minutes to cross my parcel. This is pathetic. A week ago, I could have 10 NPCs in the sim, all working at full speed. Then someone added about 1500 scripts in skyboxes. Just prefab houses with lots of stuff in them. Performance dropped way down. Trying very hard and getting there, by taking little steps very slowly. Looks awful. The hover text turns red and the "overload" message appears when pathfinding performance is below 25%, so people don't blame me for LL's problems. This recovery stuff was put there to handle temporary overloads, like many visiting avis with elaborate attachments. Not a permanently slow sim due to idle script overhead. This sucks. My animesh characters in Bellesaria and Animesh1 are doing fine. It's the sim that's broken. I just tried flying my helicopter. 2 second delays between pressing a key and the controls responding. Managed to land on the helipad OK, but it took quite a while. Worst it's ever been in over a year. This probably isn't the only bug in script scheduling, but it's one that's big, identifiable and should be fixable.
  20. Region name? And is this a full, homestead, or open space sim?
  21. From this testing in a sandbox. Controlled tests have been made. Each box has 10 scripts. Each is the default "New Script" script. Each column has 100 scripts. 10 columns, 1000 scripts here. 4.566ms script time / 1000 scripts = 0.0045 ms/script. We've tried with other numbers of scripts, too.
  22. The process of checking a script to see if it needs time takes about 0.004ms/frame. You can see this is if you look in "Area Search" in Firestorm, select something, and right-click for "Script Info". It's not much, but multiply it by 4000 or so scripts and almost all your script time is used up, doing nothing. We've been able to verify this by creating objects with large numbers of idle scripts in a completely script-free sandbox region. The script time goes up in proportion to the number of scripts. This is totally repeatable and easy to test. That's what got the Lindens' attention. There are other issues, but this one alone is eating up a lot of script time for no good reason.
  23. I asked Simon Linden that. He said that the test for "does script need to run" is not done inside the script VM. For now, perhaps the best we can do is follow a rule of "one script per 10 LI parcel capacity". 2250 scripts per full region. That's conservative, but sims below that limit usually have 100% scripts running. Useful info for landlords. That rule should apply for homestead and open space sims, too; they have less prim capacity and less available CPU time in proportion. That's only a temporary bug workaround. LL needs to fix this so that idle scripts don't drag the whole sim down, and we as users need to keep the pressure on LL to do that.
  24. Interestingly enough, multithread physics is a standard feature of the Havok physics engine. Objects are divided into groups close enough to be interacting, and groups are worked on in parallel, up to the limit of the number of scheduled threads. Firestorm does do texture decode in a separate thread. Several separate threads, in fact. I had to find a bug in there once and looked at the code. It's rather clever. Right now, I think the big performance problem in the script area is the overhead of idle scripts. That, all by itself, seems to be much of the routine overload. See this thread. The really bad thing about overhead from idle scripts is that it never goes away. It's always sucking CPU time. It's not a transient problem.
  • Create New...