Jump to content

Does anyone know the real truth behind Second Life Servers?


Lord Derryth
 Share

Recommended Posts

14 hours ago, bigmoe Whitfield said:

I'm not able to show the aws tool I use, but my backbone (I'm in a dc close to the aws site in oregon and inside aws site themselves with hosting)

but I'm seeing 3 links down right now, so there is some routing issues currently, but that changes day to day, hour to hour.

There isn't a routing issue on that trace it's just filtered once it goes to AWS and that is very common. 

Link to comment
Share on other sites

On 5/16/2022 at 6:12 PM, Lord Derryth said:

Misinformation, as I have run numerous tests on all viewers.  Alchemy was the preferred viewer for less lag.  Upon gathering information, it's been said; Alchemy utilizes the GPU more over CPU.  This is why the viewer offers more FPS and eliminates some of the lag.  Firestorm was by far the worst viewer when it came to lag despite the average FPS.  The Second Life viewer is literally nonexistent since textures take forever to load and lacks features that are QoL like Animation Overrider which is essential in eliminating extra huds that kill FPS and causes more lag.  

We were told that moving up to the cloud would make things easier, faster and more reliable.  Unfortunately, that has become false, and we are seeing far worse lag than we did before.  There needs to be an explanation as to why there will be days of perfection as if my sim server is in my home running on my network and then most of the time the server feels it's on planet Pluto.  One of my friends that worked as real estate agent said, "We received a memo stating prices may drop once we go to the cloud."  What happened, why didn't the prices drop?  Is it because of inflation and they are abusing the customer/user by keeping the prices high while paying less for servers?

Again, I appreciate the trolls not chiming in with comments about not getting a sim or leaving it for business.  I use a sim for pleasure, and I enjoy building urban city.  It's come to a point where $300 is not worth spending on a sim that is in constant lag and can barely hold more than 10 people with low script count.  In the end, it always comes down to "wow, you have a lot of scripts running, that's your problem."  Why can't it ever be, "Well, SL is old, the coding is old and nothing will ever work."?

I guess you did not endure mainland prior to the move to the cloud? Sim crossings were painful. They're still not seamless but gone are the days when you'd find yourself constantly flying uncontrollably across sims as soon as you cross a border. SL has come a long way since then, in part due to the move to the cloud. 

The hardware is better but that doesn't mean everything else stands still. We now have higher resolution textures, more complex avatars, more detailed mesh designs and that's just to name a few - oftentimes these are not optimised to meet end-user hardware limitations. 

Imo the weakest link is end-user hardware, more often than not. A lot of people still run SL on non-gaming spec computer hardware. Of course they're going to suffer with lag if they do not keep their settings low. I brought this up before only be told "SL is not a game!" -- try telling your computer that! I have a 2 year old mid-spec gaming laptop and I think it's fair to say SL gives it a good spanking. Even in the depths of winter, I can turn off my radiator because my laptop is sufficient to keep my room heated. The weakest link is probably not AWS infrastructure. 

Edited by Exavor Diesel
Link to comment
Share on other sites

19 hours ago, bigmoe Whitfield said:

I was showing a routing issue lol. 

There is always a "routing issue" somewhere.  It still amazes me how many changes a day our routers in the default-free zone see.

Trying to trace packet flows through the Internet is dangerous business.  Many transport networks consist of meshes of MPLS tag switches where there is no one best path from one point to another.

And remember, "traceroute" sends packets with the Time To Live IP header value set incrementally from 1 to 30 or more.  By plotting the locations of the routers that report "time-to-live expired in transit" we can get some clue about the path our packets are taking to a specified destination, however, it gives us no data about the return path, which is often more important to the user running traceroute utilities.

Link to comment
Share on other sites

On 5/19/2022 at 6:27 PM, Lord Derryth said:

That's why I said there needs to be an investigation.  I think they're scamming everyone.  A memo went out notifying the real estates that prices would drop by 50%.  They figured if they keep it in the dark, they make more money.  Something is not right with Second Life.

People are countering your argument and all you do is dismiss them. The comment i quoted makes me wonder if this is truly about the performance of your region or about the (supposed) drop in sim prices that did not go through. 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

On 5/19/2022 at 11:27 AM, Lord Derryth said:

A memo went out notifying the real estates that prices would drop by 50%.

Really?  I wanna see this memo!    Who received this memo?  Who sent it?

  • Like 3
Link to comment
Share on other sites

  • 1 year later...
On 5/16/2022 at 12:26 PM, Coffee Pancake said:

 

Also also .. All viewers, ALL VIEWERS are built upon the same code from LL and function fundamentally the same way. We fiddle around the edges and improve things we feel are important, but we can't stray too far from the Linden viewer .. or adding updates from LL becomes an impossible amount of work and stuff just breaks.

Some viewer projects really like to talk up the magic their project accomplishes ... don't buy the hype. Alchemy stomps on your CPU in all the same ways as every other viewer, maybe more! Always have the linden viewer in your arsenal of test viewers.

 

 

Hi all, I know this is an ancient post that I ran into but, being April 2024 I would like to comment, for anyone who might also land here, that at least for me, changing from FS to Alchemy made a HUGE difference, I was lagging badly at some places making it actually impossible to interact, all I can say, as hard facts, is that Alchemy literally doubled (x2) my FPS and made my Second Life much much happier! My PC is average btw and it does crash sometimes if I am doing too much other stuff while on SL. 

  • Like 1
Link to comment
Share on other sites

On 4/12/2024 at 4:37 PM, Hucasys Jacobus said:

at least for me, changing from FS to Alchemy made a HUGE difference

Coincidentally I too recently found Alchemy making a huge difference, discovering that it somehow cured a problem that has plagued me for months: very frequent system dialogs that "SLPlugin.exe has stopped working" that make both Firestorm and the Linden viewer unusable. (I reported it ages ago. No change through generations of updates including Friday's 7.1.6.8632452945.)

I realize it's not exactly the point of the thread (and nothing to do with framerate either); just another case of Alchemy unexpectedly coming to the rescue.

  • Like 3
Link to comment
Share on other sites

ok i just quickly scrolled through this thread.

LL's overhead cost is more then what they pay for AWS.
Theres employee's to pay that do all the techy work to improve and keep the regions online
other services like FreshDesk for support tickets, Canney for feedback
Im sure vivox is charging to use their voice system.

So their overhead is high im assuming so where else they going to get the money to cover costs?
Yes LL can cut down abit like make their own support ticket system, i'd write it all for just $500 USD
But FreshDesk is pretty awesome to use.
Not sure about Canney or what Microsoft is charging to use Github for bug reports but i know JIRA is expensive.

And as i always say about other games that has microtransaction stores. Dev's gotta eat too.

Hope that helps to understand why region rentals are expensive in SL compared to other virtual worlds.

In short, LL charges alot per region due to overhead costs including AWS fees.

Edited by VenKellie
  • Like 2
Link to comment
Share on other sites

  • 1 month later...

Just thought I'd weigh in a bit on server performance from a recent experience setting one up. My sim is now packed, at @ 27k objects (or LI rather) with lots of detail in lots of locations. EPS is generally high, over 1k most of the time.

That said, I am consistently getting compliments on how lag free or low lag the sim is, often under heavy load with 50+ avatars. Some things I have done that I think contribute to this:

1. Careful object selection: For the most part, everything I have rezzed is high quality and well made from a mesh perspective. I guess you would say efficient and clean. No sculpts, and very few singularly high LI objects.

2. Careful script selection: There are good scripts and there are bad scripts, and I'm very careful to ensure, when I can, that a script is efficient and in particular, not running constantly when it does not need to (some hover scripts, for example). I periodically monitor what is going on in the debug panel for the sim, looking for colliders and sorting running scripts by time and memory.

3. Texture efficiency: I inspect everything I put down and if it is mod and has stupidly high res textures for it's size/complexity, I'll replace them with something appropriate to the size. You would be SHOCKED at how many seemingly well made objects, when you lift the hood, have stupidly high res textures, particularly things made before a few years ago. Also, if an object has a texture applied to a face that is not visible, I set it to transparent and remove the texture from the face. I also re-use textures where I can in a given location; less textures to load is better, within the confines of things looking how you want them to.

4. Skyboxes: Obviously this depends on your build, but in my case I have a 10 floor club/hotel and each floor is it's own skybox, separated from each other by +300 meters where possible. Visitors are only rezzing what is in their immediate vicinity.

The point of saying all this is that you can't just dump a bunch of stuff in a sim, look at the statistics panel, and all it a day. There is more to controlling performance than that.

I would love to hear other tips that people have for squeezing the best performance out of their sims. It's an ongoing learning process for me.

 

  • Like 7
Link to comment
Share on other sites

  • Lindens
1 hour ago, Thecla said:

3. Texture efficiency: I inspect everything I put down and if it is mod and has stupidly high res textures for it's size/complexity, I'll replace them with something appropriate to the size. You would be SHOCKED at how many seemingly well made objects, when you lift the hood, have stupidly high res textures, particularly things made before a few years ago. Also, if an object has a texture applied to a face that is not visible, I set it to transparent and remove the texture from the face. I also re-use textures where I can in a given location; less textures to load is better, within the confines of things looking how you want them to.

I seriously want you to start a cult with this as the core tenet.  2kx2k linear ramps are going to crush my spirit.

  • Like 1
  • Thanks 1
  • Haha 2
Link to comment
Share on other sites

Posted (edited)
27 minutes ago, Monty Linden said:

I seriously want you to start a cult with this as the core tenet.  2kx2k linear ramps are going to crush my spirit.

I warned LL, several times (on github in the PR for 2K textures, on the feedback site, in meetings), about the upcoming 2K textures disaster... In a couple years from now, we will need 32GB VRAM video cards to fit all in !

On my side, I added a setting to the Cool VL Viewer (*) to limit the download and rendering size of textures (there are three setting values, one for 512x512 max, another for 1024x1024 max (default), and the last for 2048x2048 max), plus a special ”mega-texture” flag to set an exception on some textures and allow them to be rendered at full size (it currently only applies to terrain textures, since these are the only ones that do need a 2K bonus).

Surprisingly, the 512x512 limiting gives excellent results, both graphically (demonstrating how ridiculously high a texture resolution is used on most objects in SL) and for the VRAM consumption (easily halving it in scenic sims with 256m draw distance configured in the viewer). One of the reasons is that in textures-heavy places, your VRAM may quickly fill-up and then the viewer will use a ”discard bias” to reduce the resolution on the rendered textures to fit them in what little VRAM it can find, which results in a lower resolution applied to all textures, indistinctly of their actual size, meaning small textures that do not deserve a penalty still get it and appear blurry on the screen. With the size limiting, on the contrary, only large textures got the penalty, and in fact you mostly do not see any difference on the screen !

-------

(*) In the Cool VL Viewer experimental (2K-capable) branch. The setting can be toggled (in real time) via three entries in the ”Advanced” -> ”Rendering” -> ”Textures” menu.

Edited by Henri Beauchamp
  • Like 4
Link to comment
Share on other sites

21 hours ago, Monty Linden said:

I seriously want you to start a cult with this as the core tenet.  2kx2k linear ramps are going to crush my spirit.

I'll do that. "The Cult of Appropriate Resolution" lol. I've heard snippets about the 2x2 textures coming and for the life of me I cannot understand why this is necessary or being considered as an option. Seems akin to giving toddlers access to nuclear weapons if you ask me.

I suppose it has some utility in the case of very large buildings or surfaces. Would be nice if there was a way to constrain it to some minimum size. If there is a good description/rationale of this "feature" I'd love it if someone could link it here.

  • Like 2
Link to comment
Share on other sites

12 hours ago, Yorkie Bardeen said:

2k textures might actually be really nice for normal maps (or whatever the new thing is) on aircraft and the like. The existing texture limit makes them look a bit low detail.

I think there is likely an upside to 2k textures in many applications. Using one diffuse texture for multiple faces for example, and terrain maps are two examples and I'm sure there are more. The big question is how, and if it's even possible, to prevent them being abused.

I've encountered endless egregious examples of "texture abuse" over the years. The one that stands out in my memory is a pair of ornate asymmetrical hair pins from a very well known and well respected creator. They were about 8" long, relatively speaking. Not only did each pin have four 1024x1024 textures, but there were EIGHT in total because the creator flipped textures before uploading them instead of simply inverting one set in the texture editor.

They were mod so I fixed them, reducing them in size, and using four instead of eight.The change in sharpness was trivial.

If practiced professional creators do this kind of stuff, what is the rest of the population going to do with 2k textures? I shudder to think.

  • Like 1
Link to comment
Share on other sites

12 hours ago, Yorkie Bardeen said:

2k textures might actually be really nice for normal maps (or whatever the new thing is) on aircraft and the like. The existing texture limit makes them look a bit low detail.

2K won't be as bad as people think. It cost more to upload a single 2k than it does 4 1024s, and a 2k is 4x larger than a 1024. So on a large build it's not worth it. Supposedly (please fact check me), clients can request smaller image sizes than the default. So that tiny necklace from 25m away that is using nothing but 2k textures won't be rendered with 2k textures. Which means making everything needlessly 2k is going to cost a lot more. I.E. a product with 10 1024s haphazardly uploaded with 10 2ks because "muh resolution! it looks better at .5m away!" cost L$500 instead of L$100.

If used right it could make things faster. An optimized build would have 4 material slots in one slot at the same resolution of 1024 per slot. It's actually going to be huge for me. A massive cave or large build that I do needs to be split up into 8 texture slots. If I use 2Ks I can basically put 4 1024s in a single texture slot. That means effectively 32 (8x4) 1024 texture slots in a single mesh object now. Every time the client requests a texture, it has to make a network request. That's latency and bandwidth and all the memory optimizations and tricks in a viewer can never make up for the fact you need to download 32 1024s to view something and each texture takes 100ms round trip for the request and texture.

Yeah it's going to be used wrongly by people. Everything in SL is used wrongly at some point. There's a lot of people learning things. When I was learning I did a lot of things very wrong. But I kept at it and improved.

  • Like 1
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...