Why do objects take so long to detach from avatar, and why is the time so variable?

[Jennifer Boyle]

Sometimes, but not all the time, it takes a very long time to detach objects from my avatar, which is irritating when trying on clothes. It can vary from one minute to the next, from almost instantaneous to many seconds.  Today, I noticed that it was very slow, so I timed it. It was 18 seconds from my clicking on "detach" until the object detached. I was alone in the sim on a sky platform at 3,970 m. I have a 1,000 mbps connection and very few dropped packets. It was not laggy at all. When I attach objects, it only takes a second or two for it to happen. Frame rate was 41 fps.

Why does this happen? Why does it vary so much?

Edited March 17, 2022 by Jennifer Boyle

[Anna Nova]

and it's gotten a lot worse since SL moved to the AmazonWonkySytstem.

[Maitimo]

11 hours ago, Jennifer Boyle said:

 I have a 1,000 mbps connection

This.  This is the reason. 1,000mbps is tiny. You need 2,500 at an absolute minimum (and it will still be awful). 10,000 or more before it starts being a satisfactory experience.

[Wulfie Reanimator]

5 minutes ago, Maitimo said:

This.  This is the reason. 1,000mbps is tiny. You need 2,500 at an absolute minimum (and it will still be awful). 10,000 or more before it starts being a satisfactory experience.

You're thinking kbps. I can confirm that these detach (and it really feels like it's only detaching that's the issue) on a fast connection. I'm not sure if things have gotten worse over time though.

[Whirly Fizzle]

Attach & detach requests have to go through the region since the AIS3 inventory update, so on a very busy/laggy region, attach/detach can be slow.
Inventory issues/corruption can also slow down attach/detach requests.

[Anna Nova]

2 hours ago, Whirly Fizzle said:

Attach & detach requests have to go through the region since the AIS3 inventory update, so on a very busy/laggy region, attach/detach can be slow.
Inventory issues/corruption can also slow down attach/detach requests.

Like anywhere in Bellisaria (aka LagLand), where we might want to change...  Well done LL.

[Qie Niangao]

20 minutes ago, Anna Nova said:

Like anywhere in Bellisaria (aka LagLand), where we might want to change...  Well done LL.

Where is this "LagLand" to be found in Bellisseria? I'm seeing consistently between 75 and 80% Spare Time (17-18ms per frame). Obviously any region handling of attach/detach events would be solely sim-sided—mostly Network Time—where I'm seeing nothing but blue sky.

[Jennifer Boyle]

6 hours ago, Maitimo said:

This.  This is the reason. 1,000mbps is tiny. You need 2,500 at an absolute minimum (and it will still be awful). 10,000 or more before it starts being a satisfactory experience.

I meant Mbps. It's fiber to the house.

3 hours ago, Whirly Fizzle said:

Attach & detach requests have to go through the region since the AIS3 inventory update, so on a very busy/laggy region, attach/detach can be slow.
Inventory issues/corruption can also slow down attach/detach requests.

I was the only avatar in the region, and it did not seem to be laggy at all. The statistics bar said there was spare time, but I don't remember the number. If it had been laggy, I would have just chalked it up to that and not asked the question.

Is there anything I can do about the inventory issues?

[Echelon Alcott]

Hello Jennifer. Unfortunately I do not have an answer to your question, and the only contribution I can share at the moment is that I've been experiencing the same as you reported, very slow time to detach things from my avatar at times. I also have a 1 Gbps connection (although my actual bandwidth is around 940 Mbps), and experience it even when I'm by myself in my full region island with no packet loss.

[NeoBokrug Elytis]

Additionally, the more scripts an object has, the longer it takes a region to store the state of those scripts before detaching the item.

[Lucia Nightfire]

Detaching lately is delayed.

Even single prim and even unscripted, single prim objects take a long time to detach.

"Something" has changed.

[Ardy Lay]

Perhaps that something is additional checking to verify that an object being taken into inventory has indeed been properly serialized and stored within an asset prior to reaping it from the simulator.

[Lucia Nightfire]

2 hours ago, Ardy Lay said:

Perhaps that something is additional checking to verify that an object being taken into inventory has indeed been properly serialized and stored within an asset prior to reaping it from the simulator.

It could also be a new CDN vendor handling a % of the load which IIRC, has happened twice in the past.

[Monty Linden]

I'm curious about these events.  I'll happily listen to details on particularly awful instances of this problem.  Jira or here:  where, who, when (to the second, timezone), and what happened.  (Have looked at some bad rezzing/attachment events - this is a different problem, I think.)

[Jennifer Boyle]

5 hours ago, Monty Linden said:

I'm curious about these events.  I'll happily listen to details on particularly awful instances of this problem.  Jira or here:  where, who, when (to the second, timezone), and what happened.  (Have looked at some bad rezzing/attachment events - this is a different problem, I think.)

Wow!

Thanks!

I'll do some testing today and post results here.

Edited March 30, 2022 by Jennifer Boyle

[Jennifer Boyle]

5 hours ago, Monty Linden said:

I'm curious about these events.  I'll happily listen to details on particularly awful instances of this problem.  Jira or here:  where, who, when (to the second, timezone), and what happened.  (Have looked at some bad rezzing/attachment events - this is a different problem, I think.)

I logged on to try to reproduce it and was unable to now. I tried 12 times attaching and detaching a prim, and there were no long delays. I was in Danim at 104,107,64. It was between 11:45 and 11:55 am SLT. The object detached rapidly, One time, at 11:49:30, it took four seconds.

Most of my previous problems with this were at approximately the same location. I did try going to my sky platform to see it it helped, and it didn't. I was on this account all the times I saw it, as well as today.

I will report any further occurrences here.

Thank you for your interest.

[Jennifer Boyle]

It happened again just now. The firat time, I wasn't expecting it and didn't collect good data.

Then it happened again at 17:43:41 SLT. I was at Danim 103,106,65. I right-clicked on an attachment (a simple prim attached to a HUD attachment point) and clicked "Delete" at 19:43:41. It did not detach until 19:44:05.

Edited April 2, 2022 by Jennifer Boyle
typo

[Monty Linden]

12 hours ago, Jennifer Boyle said:

Then it happened again at 17:43:41 SLT. I was at Danim 103,106,65. I right-clicked on an attachment (a simple prim attached to a HUD attachment point) and clicked "Delete" at 19:43:41. It did not detach until 19:44:05.

From our side I see:

• 17:43:41 - Attachment removed to be returned to inventory
• 17:44:00 - Congestion declared while sending updates to your viewer
• 17:44:05 - Appearance requested and congestion declared cleared

So it appears like a stall in the network somewhere.  I'm curious just how awful the updates were but I don't have that here.  But there is a why to this event.

[Wulfie Reanimator]

3 hours ago, Monty Linden said:

From our side I see:

• 17:43:41 - Attachment removed to be returned to inventory
• 17:44:00 - Congestion declared while sending updates to your viewer
• 17:44:05 - Appearance requested and congestion declared cleared

So it appears like a stall in the network somewhere.  I'm curious just how awful the updates were but I don't have that here.  But there is a why to this event.

Do I understand correctly that the congestion is on the server-side?

Or does it get detected based on slow response(s) from the viewer?

Edited April 2, 2022 by Wulfie Reanimator

[Jennifer Boyle]

3 hours ago, Monty Linden said:

From our side I see:

• 17:43:41 - Attachment removed to be returned to inventory
• 17:44:00 - Congestion declared while sending updates to your viewer
• 17:44:05 - Appearance requested and congestion declared cleared

So it appears like a stall in the network somewhere.  I'm curious just how awful the updates were but I don't have that here.  But there is a why to this event.

I am ecstatic to see this progress in understanding the problem and the attention it is getting.

Is there any way that I can help further?

What are the prospects for getting it corrected?

[Monty Linden]

51 minutes ago, Wulfie Reanimator said:

Do I understand correctly that the congestion is on the server-side?

Or does it get detected based on slow response(s) from the viewer?

This is in the UDP system so it's based on slow acknowledgements from the viewer.  The problem can lie anywhere in the path.  From the socket held by the simulator to the OS scheduling the viewer and everything in between.

32 minutes ago, Jennifer Boyle said:

I am ecstatic to see this progress in understanding the problem and the attention it is getting.

Is there any way that I can help further?

What are the prospects for getting it corrected?

A bit more data from this one event first:  the simulator was very quiet, one avatar (yours), a few on neighboring regions.  Scripts using email for communication (grrr).  But metrics and logging all very quiet, nothing exceptional happening in the region or on its simhost.  In this scenario, the likely cause is elsewhere.  I.e. "the Internet did it."  I can also look at the viewer log from your session to confirm what happened from its point-of-view.  You can email it to monty @ you-know-where or we can arrange other means.

We can't make the internet (or cable ISPs or home operating system) behave but I'm interested in a few more events to see if any pattern emerges.  If so, we can turn this into a visible Jira.  Also inviting events from others here.

[Jennifer Boyle]

4 hours ago, Monty Linden said:

This is in the UDP system so it's based on slow acknowledgements from the viewer.  The problem can lie anywhere in the path.  From the socket held by the simulator to the OS scheduling the viewer and everything in between.

A bit more data from this one event first:  the simulator was very quiet, one avatar (yours), a few on neighboring regions.  Scripts using email for communication (grrr).  But metrics and logging all very quiet, nothing exceptional happening in the region or on its simhost.  In this scenario, the likely cause is elsewhere.  I.e. "the Internet did it."  I can also look at the viewer log from your session to confirm what happened from its point-of-view.  You can email it to monty @ you-know-where or we can arrange other means.

We can't make the internet (or cable ISPs or home operating system) behave but I'm interested in a few more events to see if any pattern emerges.  If so, we can turn this into a visible Jira.  Also inviting events from others here.

As best I can tell, the log from that session has been overwritten, so I'll have to save one from next time I can document an occurrence.

I have fiber to the house, and, as far as I can tell, it works flawlessly unless it doesn't work at all because somebody cut a cable. Would it help if I set up something to log the status of my internet connection, like a Windows batch file that constantly pinged google and sent the output to a text file?

[Monty Linden]

10 minutes ago, Jennifer Boyle said:

I have fiber to the house, and, as far as I can tell, it works flawlessly unless it doesn't work at all because somebody cut a cable. Would it help if I set up something to log the status of my internet connection, like a Windows batch file that constantly pinged google and sent the output to a text file?

Usually, that's not useful.  There may be 50 hops between your computer and SL servers and very little overlap with a path to google.  You can catch a problem with your ISP or modem/router or a firewall/AV being really awful.  So it may eliminate those possibilities but doesn't help beyond that.

[bigmoe Whitfield]

5 minutes ago, Monty Linden said:

Usually, that's not useful.  There may be 50 hops between your computer and SL servers and very little overlap with a path to google.  You can catch a problem with your ISP or modem/router or a firewall/AV being really awful.  So it may eliminate those possibilities but doesn't help beyond that.

I find lots of users are running double nat,  aka they go from their isp equipment that has a router built in and then into their own router. 

[Henri Beauchamp]

1 hour ago, Jennifer Boyle said:

I have fiber to the house

The question being: what is your computer connected through to your ISP router ?... If it's WiFi or PLC, then you loose a lot of the reliability (and bandwidth) brought by the FTTH link between your ISP and your home... Nothing can replace a good old Ethernet (cat 6 for 1Gbps FTTH) cable link between your ISP router and your computer !

45 minutes ago, bigmoe Whitfield said:

I find lots of users are running double nat,  aka they go from their isp equipment that has a router built in and then into their own router. 

Indeed, at least for IPv4 (more and more ISPs provide IPv6+IPv4 links). Some ISP routers can be switched to a (pseudo) bridge mode however, removing one (useless) NAT step to keep only the one in your router or firewall (I am personally using such a solution, with a small Linux PC as a firewall between my ISP router configured in bridge mode, and my local network).

Then, there is the question of the router in use by the end user. Some cheap so-called WiFi ”routers”, for example, are incapable of providing enough simultaneous connections (not enough ports) for SL viewers (that can use a lot of ports, for HTTP textures, meshes and assets fetches, plus UDP sim messaging)...

Edited April 2, 2022 by Henri Beauchamp