WolfBaginski Bearsfoot

48 hours since my original Abuse Report, which was before the weekend. The problem persists. The affected region has over 38000 scripts running and the sim is running at no more than 20% of normal speed. Scripted objects do eventually respond to triggers, but it takes over 30 seconds for a door to open. I very much fear that expressing my opinion on the Lindens responsible would trigger a pile-on by people with no obvious connection to the Labs, making some claim of being a moderator. But I find it difficult to avoid the conclusion that Linden Labs is run by a bunch of programming prima donnas who still haven't realised that Second Life is a 24/7 internet service. (I could replace everything after "is run by" with two simple words.)

Do Abuse Reports work? We get an automatic acknowledgement, which tells us that we will never be told of any action taken. The TOS is the same. I've seen one incident I reporting--replicating prims spewing particles, and dragging down sim/physics frame rates--carrying on for over 24 hours. Is it worth bothering making a report? All the evidence I have is that it's not worth the trouble. Nothing happens. And this is pretty clear evidence of nothing.

I am not sure what the time is between scans. for the map, the search, or anything else, but since there are always sims which never seen to get marked down on the map during a rollout, and some which are marked as down for hours, I figure there will always be places that will get missed for one cycle. I have sometimes wondered if these things should really run on a cycle which is effectively same-time-every-day. The sun-moon model has sunrises several times every real day, and always at the same RL times. I've never bothered to measure the cycle time, but if it ran seven hours it would go through a weekly cycle. Whether search or map scans are ever that predictable, I just don't know. For the search scan, and its interaction with roll-outs, I am not sure I can see how it would be predictable enough to be able to say whether somebody could be regularly afflicted. Would it be simplest, now the rollout-process is running faster, just to pause the scan as part of the roll-out process?

I can confirm that things have been bad this weekend, and not just over the Blake Sea. I have seen bursts of very high packet loss, but that could be a non-Linden problem. Whether this is soimething sapecific to sim crossing, or just another sign of a bollixed network, I cannot tell.

I don't see any obvious problems, looks to be standard Adobe Flash interface and I've not had to load any unusual drivers since I switched to 64-bit Windows. I have the basic Windows. and DivX. Maybe you should get the free DivX player.

I don't know how much of the mess I experienced can be blamed on the Beta-grid's Asset Servers, and how much on the SSB process. Most of the time, the shape-related changes were getting through, but the visible textures never changed. Going by what was being said, the current operation of the JIRA system is going to be a PITA for collecting bug reports.

There's no obvious sign of a change in the thread listing, it still shows the original posting date. No big deal, but I can imagine some confusion if something happens, and people don't check for changes. I can thing of a few people who post in these parts who might make that mistake.

nVidia, late Monday, released a new video driver. As usual, it may be wise to wait a few days before updating your system, so as to let other people discover what the Lindens didn't expect. I updated, and found a noticeable increase in frame rate. Though a better measure may be the Ktris per Second number. I was getting bursts of over 100fps in a simple high-altitude skybox. This was with upper range graphics settings, just not having shadows turned on. The KTris number was pretty consistent as I moved between locations of different scene complexity. The new version is 314.07 I also had a bunch of Windows patches this morning, including one of the nVidia ethernet controller on my machine. Looking good so far.

It's an old suggestion, but this last weekend I have run a few tests with movement interpolation off. This is found in the Network sub-menu of the Develop menu. It stops the wild rides, and you stop at the sim boundary until the crossing is complete. But I also see a lot of stalls and stutters within a region. But what is the cause? My guesses: The change in Physics needed to support pathfinding Bad communication between sim and viewer. I have certainly seen bursts of packet loss associated with the stuttering. Overloaded regions. I doubt there is a single cause. I have seeb this stuttering without another AV in sight. I have seen it happen over the Blake Sea and over complicated mainland regions.

The recent roll-out of threaded region crossing seems to allow a "bad" crossing to run for a long time before it fails, and when I did some testing earlier today, I tried switching of the interpolation that smooths physical movement: If you don't get position updates, you don't move. There were very frequent stalls and stutters, and some sim crossing was very prolonged. Whether the problem is with anything at LL's end of the link, I am inclined to doubt. I was getting odd results from tests of connection speed, such as the download speed being less than the upload speed. I was also seeing dropped packets. I would recommend that you check that your computer isn't running a download in the background. Streaming music can also be part of the problem. The basic problem can affect an unscripted AV just walking around, and since it isn't just a part of sim crossing there's something else not working properly. I sometimes wonder if the Lindens are testing against the same sort of internet connections we get, but what do I know? (Although I have had my domain name for longer than SL has existed.)

So the image in the Blog Post is nothing at all to do with what the Valentine's Gift is? And it's not a gift I can give to somebody else, it's a gift the Lindens give to me? I think I shall pass (not that the picture fives me any confidence in the good taste of any Lindens).

It's the third option. The packet gets split into two packets on a connection where the MTU is too small, and reassembled on the way. Which means that extra sets of packet headers have to be transmitted, and CPU cycles have to be spent on assembly and disassemby. I am not going to pretend to understand all the messy details, but in the old days, when people used dial-up modems, MTU really mattered. It took a second or so to send a 1500-byte packet over a modem link. 1500 bytes is the maximum for standard Ethernet, but if you're using a broadband connection over a telephone line, that almost certainly uses PPPoE, which has an MTU of 1492 bytes. There are a few other things which can reduce that further, such as VPNs, but I reckon the bandwith penalty for the 1492-byte MTU is insignignificant compared to the cost of splitting packets. (0.54% penalty) There's a strong argument for Linden Labs to use a 1492-byte MTU, which is only likely to affect object-rezzing. If automatic systems are used and working correctly, Linden Labs should only be sending 1492-byte packets anyway, but I think it is better to set this one explicitly. Packet size is always no bigger than the data needs. In fourteen hundred and ninety-two Columbus sailed the ocean blue. He wasn't the first, there was nothing surprising, Nut this is the number to set packet sizing.

That has been a common failure mode for as far back as I can recall. I think there's a bit more stutter, maybe a region crossing process taking several time-slices to complete (is that the right term) instead of locking up the servers until the process completes. The new method doesn't halt so easily. so there are fewer total failures. (I'll note that my comparisons are besed on using the same vehicle, before and after, but I don't guarantee that is was the best possible. My AV is not heavily scripted.)

I don't see any obvious reasons why such a mega-sim, or several in a group, couldn't be on LL servers and TP-connected to the rest of the Grid. I wouldn't be surprised if the server code is different enough from the OpenSim code that it isn't a practical option. I would suggest as a starting point for such a project those Premium Sandbox regions. Since there is a problem for region-crossing if the regions involved are different sizes, TP-only is the way to go. I can't see the Pirate Battle area of the Blake Sea becoming a 2x2 Mega Region, but I remember a group of pirate-themed private islands from my early days, and such a place is another obvious candidate. I think that a more likely answer will be a growth in the use of Micro/Petite AVs, and vehicles scaled to suit.

I canfirm that I get hit by Parcel Full travelling on the Linden road from Kuula to Uzume, left side of the road, where the road prims overlap a non-Kinden parcel. Travelling in the opposite direction isn't a problem, it seems to be the combination of Region Crossing and Full Parcel that does it. Kuula can be a bit busy, with the NCI site. NCI has a big rez zone between the castle and Uli region. There's a small one on the road to the west, at the T-junction by the bridge in Koleamoku region.

I was down in the Snowlands... I think it was the SW corner of Eagan region, which looks like a really bad arrangement of road and sim boundaries anyway. Uzume to Kuula was dodgy a few weeks ago, partly one of those spikes of land the Lindens sold.

It is possible that Mesh is a bigger load, more work for the region-crossing process, more data to be sent from one sim to the next. And good scripts beat bad scripts. I suspect Mesh can be part of a problem. Go to the right source, and you will get a good vehicle. With the changes in the Physics engines over the years, I'd be wary of old freebies. Cubey Terra made a good submarine and that script has been re-used by many, but some constants set in the program need adjusting. Ground vehicles can be tricky since the Pathfinding-linked changes. I kniw who I have had good results from, but I haven't tried every vehicle out there. Anyone reading this who makes and sells vehicles? Think about updating the scripts on some of your older vehicles.

I have no idea why my paragraphs have run together.

Sure, go ahead and re-publish.

With the threaded code now running on all regions, we can now properly see what it does. Over the last weekend, which is never a good time, I've managed to make some lengthy journeys over the Grid. Some aspects have improved, some things are different. 1: The quality of region crossings is not the best I have seen. I infer, from past efforts, their results, and those improvements eroding as time passed, that the distance between servers on the LL network still has significant effect. The reduction of three co-locations to two has made things significantly worse. 2: For vehicles, the new Threaded Code has made the best crossings a little worse, but crossings that would once have failed are now, eventually, completed. Wait long enough, and the wild uncontrolled rides will end in a jump back to a stable state in roughly the intended place. But there are more crossings that show brief glitches. 3: Foot crossings seem to be about the same as they were. 4: We're told that the big effect of the threaded code is on other users. It means the sim doesn't stall while handling a crossing. I wouldn't be surprised if this is why the wild rides can eventually end without crashing. But I cannot easily test this. I'd expect to see signs of this improving to be visible to the sailing community, whose races involve multiple region crossings. A bunch of AVs in vehicle will cross the boundary, with observers on both sides. 5: The old bugs are still there, such as the parcel-full problem for vehicles when they cross a region boundary. Vehicles in a region should be using a separate pool of prims, so they don't crash out with full-parcel errors, but there has always been something about the region-crossing process that breaks this. And the typical camera position for driving a vehicle is still bad for detecting ban-lines before you hit them. These effects, and occasional no-warning security orbs, have been the primary cause of disrupted journeys in my tests. 6: Before the threaded code rolled out, the best I ever did was a trip of about 50 region crossings, usually ending in the vehicle vanishing and being dumped at (0,0,0) with the AV in an uncontrollable state. Often a logout was the only cure. The new system seems to make 80 crossings attainable, and the main cause of problems are those listed in para 5. There is room for improvement, and there may be some effects attributable to particular RC code which leads to lag. Magnum is a bit dodgy, and I have a vague unease about the Le Tigre code. Anything which slows down the process lag in a server or a sluggish network, is still going to be a problem. Thanks, guys. There's still work to do, but the new code is a big improvement.

A lot of people have tablets and smartphones now, and there are some good apps to give a picture of the local wifi environment. I'm lucky, I'm not in an area with a high density of wi-fi networks, but I can see that three of my neighbours use the same channel. I can see the drop in the S/N ratio when the microwave is running. I've been able to put my own wifi on the best available channel, so that the things I have which need wifi will work more reliably. If you have the hardware, get the App. I know there are free wifi analyzer apps for Android, It is worth making these basic checks. And if you can run off a wired connection, do so. Wifi is used by so many things that the bandwidth available is becoming saturated.

May I refer you to RFC1918, Address Allocation for Private Internets. Or just try a traceroute to the IP address I quoted, which I obtained by the procedure you specified.

Is that info current? I think LL stopped using one of those three locations kast year.

Going by my home network, the information you get by those methods may be less useful than you expect. I use a modem/router with NAT between my computer and my ISP. The router provides the DNS for my LAN, so the methods you describe return an IP address of 192.168.1.1 for the DNS server my computer uses. My ISP uses DHCP to inform my router of the IPv4 addresses of its DNS servers, but I am manually set up to use the Google DNS servers. And I don't have the problems. The country, and the name of the customer's ISP, could be a useful addition to the information requested. You can work back from the IP address of the DNS server to get that, but it is something that isn't such an intimidatingly techie thing to find out. Here in the UK, ISPs are supplying customers with modem/router hardware that is set up, with DHCP and NAT, to do all this as if by magic. Maybe things are done differently in the USA, but, viewed from here, I'm not sure you'll get enough useful data.

I think the Leap Motion devide has more potential than most new-UI gadgets. With Windows 8 having a UI redesigned to work well with a touch screen, this has the potential to add a touch screen to an exiting monitor. But I am, right now, looking at the old USB-connected game controller I have, and thinking of my experience of getting it to work with SL (it is a very unadventurous device, very like an Xbox or Playstation controller, two sticks and a set of buttons), and what LL have done for such gadgets is, I think, woefully incomplete. Windows makes the control signals available. The SL viewer does not use them well. I am not expecting any better for this. And the SL viewer, like most of the other desktop software out there, would need a big redesign to work well with a touch screen. It's a much bigger change than just interpreting the movements of the joysticks on a game controller in an SL-useful way. I like the idea. I can see what the Leap Motion could do. But I am not confident about what Linden Labs would be able to do with it.