Jerking, Stuttering Movement

Tonight SL is presenting a problem that hasn't occurred for a while, but which I used to see fairly often.

As I fly along, the motion through the world is halting and stuttering, as if I was running into sheets of glass and having to punch through, sometimes rebounding from the thicker sheets.

My computer and video card are well up to and above specs, my internet connection is the same good quality as always. The stats that I associate with good versus bad behavior are all fine. Ping times are normal, TD & SFPS are perfect. Bandwidth use is normal, packet loss is normal - zero when bandwidth use is not strained.

Preferences are my normal 128 draw, no anisotropic filtering, no local lights, no shadows, no ripple water , Far Clip is disabled, Shiny is On (of course) , AV render is bump mapped, terrain detail is medium,

None of the settings make any difference at all so far as this problem goes.

Suezanne, I'm getting it too, and I can reproduce it in many areas. One spot that comes to mind is the GNUbie store. I went there to grab some stuff for a friend and while flying around the outside and walking around inside I kept getting hit with horrible stuttering, immobility, just as you describe -- like hitting an invisible wall or something.

"I can reproduce it in many areas." does it change by sim or by parcel? Is it dependent on local object density?

Is the problem still occurring?

If you turn on the Debug Console option do get any messages that might provide a clue as to what the problem is?

Can you derive any useful info from the Fast Timers psychedelic rounded corner graph display?

I am also getting this effect in a lot of sims in the main grid. I do not get it at all at Cosy Home, so I do not suppose my HW to be the problem (7800 GTX by the way).

I have to admit that I have not yet tried to find out which preference option could eventually change this. Most of the time I am so frustrated that I just tp out of the sim.

Mel

I was getting the same movement issues after the 1.8 upgrade. I thought it was just the grid being slow untill I decided to clear the cache.. problem solved. Movement is once again normal.

What you guys are describing is rubber banding, which is often caused by intermittent Packet Loss. It can also be caused client side if your 'puter is thrashing the hard drive rummaging through the cache. If clearing the cache doesn't stop the problem from being persistant regardless of what Sim you're in, it's Packet Loss...file a bug report.

Rubber banding was an overwhelming problem in 1.6 and 1.7 Previews, but 1.8 Preview was pretty smooth. Packet Loss is almost always a server side problem (the proof being that it affects a large number of users), but is always blamed on the user's ISP or firewall or router. What you can do about it, other than filing bug reports, is precisely nothing at all.

Clearing the cache didn't make any difference for me. Back a year or so ago when I had the same problem it lasted for weeks. No idea what made it go away.

The current jerkiness and stuttering seems to have gone away for me for reasons unknown.

This is an extremely debilitating problem which pretty much makes SL zero fun when it occurs, so it's a good one to file bug reports on, post about when it happens in the technical forums, call the support number about, etc., in hopes of preventing its reoccurrence.

Thank you - quite thought I was going mad, but your post perfectly and succinctly sums up what I've experienced recently. And you say there's nothing I can do to resolve it?

I'm getting rubber banding, but it's associated with time dilation droping to ludicrous levels (0.08!). That's not packet-loss!

There is zero packet loss associated with the phenomena I described, so far as SL's packet loss detection system is concerned. I have filed dozens of bug reports about this problem when it happened a year or so ago. Philip Rosedale had me send diagnostic info to him for review. No solution resulted. The problem went away for no apparent reason.

Packet loss that occurs without any evidence of packet loss in the stats display or the cumulative report that appears in the Help About Second Life display must be an especially sneaky sort of packet loss.

In my case this jerky stuttering occurs with an abnormally high client FPS - like the video card is loafing because it's not getting asked to update the picture enough, as if not just packets were being lost, but numerous frames, something so big the error detection scheme is not designed to deal with it.

That last paragraph is a great description of the typical SL lag at it's worst...precisely what I experienced heavily and increasingly in 1.6/1.7 Preview; and it's kept me off the main grid since the end of 1.5.

Even going all the way back to Beta I've hardly ever seen sustained, measurable Packet Loss. And I've often had that feeling you describe...that the server is not just dropping a couple of packets here and there, but is skipping such huge pieces of data that it's flying "above the radar." Not good.

But at least we get to keep filing our friendly, helpful bug reports.

Yuppers. My lag-related bug reports in recent Previews were all about the drop in time dilation and local fps associated with the new 45fps cap on sim fps, and with the changes in prioritization of Inventory and scripts.

We can't fix the client for them, but at least we can suffer.

First the bad news...you are going crazy.

The good news, sort of, it's not true that there's absolutely nothing that helps. But what helps on the client side is mostly upgrading hardware. Add more memory, and yet more after that, as well as faster memory. Secondly, a faster CPU and a motherboard with faster Front Side Bus speed would help. And, of course, a faster hard drive helps since SL is quite hard drive dependent because of it's constant caching. A faster internet connection doesn't hurt either. Did I mention more memory???

Other than hardware: don't run any other programs in the background, not even anti-virus. I used to always delete the cache after every session, but these days I find it more helpful to just defrag the hard drive. And, obviously, turn graphics rendering options in Preferences down to almost nothing (actually...less than nothing).

Turning the monitor off elimates all visible symptoms in a highly efficient manner which also reduces one's power bill.

The problem seems to want to linger now, varying in intensity, but not really wanting to go away entirely.

As has been noted elsewhere, if you read the SecondLife.log file you can see that SL has implemented a "reliable" transport for things like textures over the unreliable datagram (UDP) that SL uses for most of its comms.

Unfortunately, they sorta-almost-tried to reinvent TCP but left out all the hard parts. For example, if you get packets 1-199 of a 200 packet texture and don't get #200, it just throws away 1-199. Even more fun is if packet 112 gets lost, SL will send you maybe the next 80 packets before deciding to trash it and start over again. Good stuff, that - kind of reminds me of bogosort.

Holy mother of Turing! No wonder we have texture download problems. Why not have a separate TCP connection for non-real-time data alongside the UDP channel for real-time events?

First guess? Lack of competence.

I tend to think that a person in 2002 reinventing a wheel made in 1977 without bothering to pay any attention to prior art to be a bit of a dolt. You don't even have to read the ARPANET RFCs to understand sliding-window protocols, selective retransmission, SDU reassembly and so on. An afternoon spent with Tannenbaum will tell you how all that works.

But as you said, why not have a separate channel and use TCP and not have to reinvent the wheel at all? My guess is that it never occured to them.

Well it seems after a good bit of badgering for really botching the reliable stream over UDP protocol, someone got a clue:However, where there used to be a stream of "missed packet 4, ignoring packets 5-152" they've either removed the log message or more likely, are ACKing each packet. If it is the latter then I must use big letters.

Sending an ACK for each packet will do terrible things for performance and intensify the Grey Life® experience probably in the same way that is being widely reported. You see, with a ping user time of 125ms, the round trip time for packet and ACK would be 250ms which means that you'll be sending an astounding 4 packets per second. Since the average size of SL packets is 256 bytes this translates to a blinding 8kbps of asset transfer. I haven't seen communications this zippy since like 1984! Good work guys, glad to be of assistance.

I've had those error messages for ages.

I remember asking for a guide to meaning and import of the various messages one finds is a log file or in the debug console display and was told that they don't have a guide to what the error messages mean. This seems kind of odd to me.

I have been reading up on this thread as it has progressed, I must say your findings are amazing, I just finished college, my major being computer systems and networks, everything I see here makes perfect sense. Now that we see there IS a problem and have the proof, will the Lindens do anything about it?

Yeah, so why am I shelling out every month for a T-1 line??? May as well dig out my old 2400 baud dialup. Hey, it was good enough for Beta testing the very first MMO virtual world...Compuserve's WorldsAway. It was 2D of course, and I got about the same performance I'm getting in SL these days.

BTW, fantastic bit of detective work. I've been looking at that stuff for nearly three years and never noticed that 'playing back delayed packet' message. Either it wasn't there or I just never paid attention to it. But it sure would explain a whole lot. If they're really doing 100% ACK how could they ever have imagined that the service would scale up?

Hopefully SL2 will make the big leap to the TTCPS protocol (Two Tin Cans and a Piece of String).

- "Pardon me, do you have any Grey Poupon?"

- "No, but I have grey textures."

Huh. I wonder why they didn't just use tcp.

Nope, 'fraid not.


-- "Of course, it's a terribly attractive sort of grey grid, don't you think?"

-- "Oh yes, so much nicer than that awful smoke texture!"

Nope, as of 1.7 the protocol was even worse; this message is new to 1.8 and was possibly an undocumented fix for the protocol defect noted here.

In short, in the old "reliable" texture transfer protocol, a dropped packet would not cause a source quench for 50+ packets even though the whole SDU had to be thrown away. Although this change certainly reduces the amount of junk data sent (and logged) it pays for reliabilty with a huge performance cost.

Please note that given the new message, I cannot be positive that they are doing a dumb Send-ACK-Send-ACK... but it seems consistent with the observed behavior.

OK, it's making sense then. I know I took a good hard look at the messages in 1.7 Preview to see why sim fps and time dilation sucked so badly (turned out to be the new 45fps cap of course...funny they never mentioned that as a new feature, eh?). But 1.8 Preview was smoother, probably due to the re-prioritizations, so I've never looked at Debug or Log for 1.8. I will now of course...

In all fairness, I have to admit that for me 1.8 has hugely outperformed 1.7, both on the Preview and Main grids. Even texture rendering happens significantly faster. But I realize it's gotten much worse for many people. On my antique box, most lag I see really is going to be local hardware bottlenecks, so I'm not getting the 'typical user' experience.

Historically, transfer reliability really has been an issue, probably even more so when LL re-enabled p2p. But if that truly was the trade-off, it would effectively bring the average experience down to the level which is the norm for me...decidedly not a good thing. None of this surprises me. I've known for a long time that LL is going kludge-wild, trying to scale up for the growth that's probably been a hundred times what they ever imagined.