Jump to content
luna Datura

Maitreya update

Recommended Posts

10 hours ago, BelindaN said:

I'm just not tuned in to the IT speak, I know people talk about FPS......which I assume is frames per second......where do I find this? is it in preferences???

In most viewers the shortcut is Ctrl-Shift-1 to open viewer stats. The viewer's FPS is near the top.

The Lindens consider 10 FPS useable ... eck. I think the bottom is more like 20. The SL system is designed to operate at 44 FPS, viewer and servers. Your viewer is not locked to the server speed nor is the server locked to the viewer. The servers will never exceed 44 FPS as the CPU moves on to process the next simulator. Viewers will, but they fake (duplicate) frames when they go over 44. 

My 3 yr old computer only uses about 25% to 50% of its capability when running SL. Depending on what I am doing I'll see FPS from 10 to 150. I average 30 to 40 FPS. Anything above 25FP provides smooth video and movement. Below that things start to get jerky...

The viewer stats panel is the panel you need to look at to see if the lag is you or the server. Look for Server FPS, Physics FPS, and Time Dilation. Ideally they are 44 - 44 - and 1.00. As the server gets behind these numbers get smaller. Anything lower indicates the server is starting to lag. Things REALLY suck at Server <20 FPS.

PING in the viewer is a combination of the viewer, servers, and network. In Windows and outside of SL PING is almost purely network. If you ever have to troubleshoot connection problems just remember viewer PING is not Network PING. So, you have to know if the server and/or viewer is lagging before you can trust the viewer's PING numbers.

 

  • Like 1

Share this post


Link to post
Share on other sites
22 hours ago, Nalates Urriah said:

The Lindens consider 10 FPS useable ... eck. I think the bottom is more like 20. The SL system is designed to operate at 44 FPS, viewer and servers. Your viewer is not locked to the server speed nor is the server locked to the viewer. The servers will never exceed 44 FPS as the CPU moves on to process the next simulator. Viewers will, but they fake (duplicate) frames when they go over 44. 

Not quite right.

According to this wiki page, "Generally, above 15 FPS is good. The higher it gets, the smoother." I haven't heard them give any specific number.

The servers operate at 45 FPS, meaning the sim will start a new round of calculations for everything (positions, rotations, scripts, etc) in a region every 1/45 (0.0222...) seconds. This is why the minimum event delay for scripts is 0.022 seconds for example. If all the calculations are finished faster than that, the sim will sleep until the next "frame."

What we call "viewer FPS" is completely different. Viewers don't depend on updates from the server and it will never "duplicate frames." Server FPS is basically how often the world is updated. Viewer FPS is how often a new image of the current world is rendered, and there are no relationships between the two.

This is most noticeable when you move your camera around. Even if you couldn't tell a visual difference between 15 FPS, 30 FPS, and 60 FPS, you can feel it. Let's imagine you orbit your camera around an object in one second. This is how many angles you would see the object from if your viewer was running at 15 FPS vs 60 FPS.
e601f53e8b.png

Here's a gif of the 15 FPS (slowed to half) version and 60 FPS version.

Or in the case of watching something else move while your camera is stationary, it doesn't matter how many keyframes are in an animation, the viewer will calculate create all the in-between positions. For example, your viewer will create this from a looping 2-frame animation (depending on FPS), regardless of whether it's a prim moving or an avatar waving their hand:
b8ccbd081c.png

22 hours ago, Nalates Urriah said:

PING in the viewer is a combination of the viewer, servers, and network. In Windows and outside of SL PING is almost purely network. If you ever have to troubleshoot connection problems just remember viewer PING is not Network PING. So, you have to know if the server and/or viewer is lagging before you can trust the viewer's PING numbers.

There doesn't seem to be any proof of this. Ping, aka latency, is just the round-trip time of a signal going from you to the server and back. It doesn't make any sense to combine that information with things like server FPS or especially viewer FPS.

Edited by Wulfie Reanimator
  • Like 1

Share this post


Link to post
Share on other sites
On 2/15/2020 at 8:45 AM, Wulfie Reanimator said:

There doesn't seem to be any proof of this. Ping, aka latency, is just the round-trip time of a signal going from you to the server and back. It doesn't make any sense to combine that information with things like server FPS or especially viewer FPS.

What you are defining is network PING. And it doesn't make sense to combine it if one is just testing the network. However, test it using the viewer in a laggy region with low server FPS and Time Dilation along with a viewer FPS of 10+/- while PINGing via the Windows command line PING. Do some experiments.

This has been discussed at the UG meetings several times.

Share this post


Link to post
Share on other sites
23 minutes ago, Nalates Urriah said:

What you are defining is network PING. And it doesn't make sense to combine it if one is just testing the network. However, test it using the viewer in a laggy region with low server FPS and Time Dilation along with a viewer FPS of 10+/- while PINGing via the Windows command line PING. Do some experiments.

This has been discussed at the UG meetings several times.

I'll do that. In the meantime, do you have any links to recordings of those meetings (assuming they're recorded either in text or video)?

Edit: Well, that was quick. I set my FPS to 3 (in a good sim) and the ping shot right up, and straight back to normal at 60 FPS. 🤔

I found another thread where it was discussed and I stand by my statement of this practice not making any sense.

Edited by Wulfie Reanimator

Share this post


Link to post
Share on other sites

Naming the number in the viewer "PING" is what doesn't make sense. The viewer doesn't do a PING as we normally think of it... but PING conveys the idea of what they were trying to get across.

SLPing1a.thumb.jpg.513637105f50e7d81b1d375daf386e81.jpg

People have talked about this disparity in the PING numbers for as long as I've been around SL. I got an answer from Andrew Linden in 2012, if you had bothered to Google...

Basically, Andrew Linden said, 

In response to my pointing out that when Physics FPS slows PING in the Viewer Stats goes up and pings from outside the viewer give different results Andrew replied:

What is happening there is that the incoming packets are processed in the main simulator loop. So if the physics engine is causing the main simulator loop to run slow, then network packets pile up and wait and their ping replies come back after a delay (after the physics frame is done). That is, the responder to the ping messages is not running on a separate thread.

I think there is a similar dependency of ping on the *viewer* fps.

If you ping the server from a terminal command line you’ll get a hardware accelerated response, which should be closer to the real network travel time between server and client.

Siana Gearz confirmed: “Andrew, yes, ping is dependent on viewer frame rate. Because it’s a processing roundtrip time of sorts and messages are only processed once a frame.”

Andrew Linden: “Yes, and that ping time is relevant to the UDP circuit code — it’s the effective ping it would want to use for delay interpolation (if it did any).”

I did some quick tests with Firestorm 6.3.2 and it is still true, Physics FPS drops and ping increases. Finding a laggy region when you want one is a PITA. The Sands is consistently laggy with SIM and Physics FPS bouncing between 30 and 44.x.

Once upon a time everything was dependent on a non-error-corrected UDP connection. The server adjusted UDP send rates according to the aggregate 'ping'... server, travel, and viewer ability to catch data. The point of an adjustable Max Bandwidth to improve or at least set a top or starting send rate to avoid wasted server effort.

  • Thanks 1

Share this post


Link to post
Share on other sites

I just noticed that with the update, my Omega layers won't apply to the hands anymore. I'm wearing all the layers and I also use the current version of the Omega relay HUD. The Tattoo applies everywhere but on the hands and feet. Am I missing something here? 😕

Share this post


Link to post
Share on other sites
1 hour ago, Chuckey Jigsaw said:

I just noticed that with the update, my Omega layers won't apply to the hands anymore. I'm wearing all the layers and I also use the current version of the Omega relay HUD. The Tattoo applies everywhere but on the hands and feet. Am I missing something here? 😕

Make sure you have the recent updated hotfixes (body is 5.02, HUD is 5.01).  Just have the body redelivered.  You can do that easily using the new HUD, on the Misc. tab. :)

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, Tarani Tempest said:

Make sure you have the recent updated hotfixes (body is 5.02, HUD is 5.01).  Just have the body redelivered.  You can do that easily using the new HUD, on the Misc. tab. :)

Okay, so I got the body update but it's still not working. Hands and feet are left out. Is there anything else I can try? It happens with every tattoo on the Omega layer. All Maitreya tattoos are working fine...

Share this post


Link to post
Share on other sites

OMG I derp'd hardcore..! I literally just figured out, that you are able to click on the relay HUD and re-apply your sh*t from there as well... *facepalms* 🤦‍♀️ 🤦‍♀️
So it worked now.. 🙈 Thanks for your advice, tho! I'm so sorry for the inconvenience I might have caused. 

giphy.gif

  • Like 3

Share this post


Link to post
Share on other sites
1 hour ago, Chuckey Jigsaw said:

literally just figured out, that you are able to click on the relay HUD and re-apply your sh*t from there as well.

Cool!  I did not know that.  Thanks

Share this post


Link to post
Share on other sites

Also, on some versions of the Omega Relay there were check boxes for different parts of the body and by default Hands/Gloves and Feet/Socks was left unchecked by default.

Worth looking at if you have that issue

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...