C:SI Now Using Monthly Payments!?

This has just been posted on the C:SI website. April Fools', right? That's what I thought, until my sword requested permission to take Lindens from my account. I choose "Deny" and it disappeared from my inventory! WTF? I hope the devs realize how many customers they are going to lose because of this.

Mono Listener Performance Update

Time for some updates about SVC-1862, which is the bug I reported concerning listeners performing worse in Mono compiled scripts.

• It has been marked as relating to SVC-1398, which is about link messages in Mono being 2 times slower. Link messages were something I was going to test myself until I saw that this bug had already been reported.
• Lee Ludd commented that it might be related to Mono using 16-bit characters instead of 8-bit characters. I ran the tests again using different string lengths to test this theory, and there wasn't any noticeable change.
• Gordon Wendt says he mentioned it during Linden Office Hours, so hopefully this is something they will look into soon. Still no comments from any Lindens on the Jira page, though.
  

Getting Back to Building

I haven't done much with my Go board recently. Mostly because I am once again trying to switch to using a Linux environment as much as possible, but have been discouraged from using Second Life because of sound problems.

However, I now have three people who have expressed interest in owning one, so that has encouraged me to try to get back to work.

I'm thinking about changing the way my board handles the stones. Right now, each time a stone is played it rezzes a prim for the stone. The other option is to have an invisible stone fixed at each location on the board, and then when a stone is played make it visible and set its color. The advantages to the second method are that now the players can just click on the board to place a stone instead of having to type in the coordinates. Also, the stones can be grouped with the board so that if the board is moved, they will move as well. It doesn't seem like there is a way to group prims through scripts, so some other method that would most likely be more complicated and not work as well would have to be used to get the same effect.

The obvious disadvantage, and the original reason I went with the first method, is that the board will require 368 prims at all times. Using the current method, it only needs 7 prims when not in use, and if the players are only using a 9x9 or 13x13 size board, they won't come near 368 prims. Even on a 19x19 board, not all games will use 368 prims. As I think about it more, though, is there really an advantage to having it only take 7 prims when not in use? They will still need 368 prims available when they want to use it, and I doubt many people will want to have to return all their furniture or something each time they want to use the board, then re-rez it when they are done.

I have come across two other Go boards in SL. One of them uses this method I'm describing of just having invisible prims for all the stones. The other had the user click the board which would rez a stone, then the user had to edit the stone and move it onto the correct board position. I'm not a big fan of that last method.

Any suggestions?

Enough with the Frequent Problems!

Second Life seems to have problems on a weekly (or daily?) basis. It wasn't always this way, although I think it's more that Linden Lab is being more public about the problems on the blog and SL isn't necessarily more unstable than it used to be (although that could still be the case). There have been announcements of problems today, yesterday, Saturday, Friday...I'm getting tired of linking, but there were also problems last Monday, Tuesday, and Wednesday. Along with many of these problems (including all of the ones I linked to) comes LL advising people not to make any transactions, which can significantly hurt business as some have pointed out.

This pattern has been going on for a while, and I'm starting to wonder how LL is responding to these problems. It almost seems like they are just working to get things back to normal as quickly as possible, but in the process are not making any attempt to actually figure out how to prevent the problem from happening again in the future. With the frequency of these problems, and the fact that they have been going on for months at this frequency, I find it very unlikely that all of these problems are caused by unique issues. Some of them must be recurring problems that we have had before.

Now, with all the linking I have done back to the official Second Life blog, it's very likely that a Linden Lab employee will end up reading this post. I understand that you want to fix these problems as quickly as possible, but I, for one, would prefer to have the problem persist for longer if it means that you can take the time to diagnose the cause and make adjustments so that the problem isn't likely to happen again. I think in the long run this will make the users of SL happier and increase the uptime of your services in the future.

Linux Client Sound FAIL!

I'm trying to use the Second Life client on Linux again, which I haven't done in a long time. I posted a while back about the differences between the clients, and in the last paragraph of that post I talk about the sound problems I have had in Linux. Well, the problems seem to have gotten worse. Now the sound stutters (like when you're trying to play a scratched DVD). Hopefully I will be able to find a way to fix it. At this point, I'm not even sure if it's a result of changes in the Second Life program or in Ubuntu.

Edit: The shell script that runs Second Life has some sound configuration options. After playing around with them, it looks like Second Life is using OSS instead of ALSA. This is probably the source of the problem, now I just need to figure out how to get it to use ALSA.

Second Life Command Line Options

There are some useful command line options for Second Life that I'm not sure many people know about. To add a command line option in Windows, you have to right-click on the Second Life shortcut, choose "Properties" and then add the options to the end of the "Target:" line. Mac users...you're on your own. Maybe someone who owns a Mac can post a comment explaining how to do it.

-multiple
This will stop Second Life from preventing you from running more than one viewer at a time, allowing you to log on to multiple accounts simultaneously on the same computer.

-autologin
Bypass the login screen and automatically log on with the name and password that is stored. You can also use "-login <first> <last> <password>" to log in as any account without the login screen.

-purge
Clears the cache when it runs. This is useful because normally if you want to clear the cache you have to log in, click "Clear Cache" in the options, then log out and log back in. There might also be a case where the cache is corrupted and you crash before you can even get to the "Clear Cache" button.

-safe
If you set some options that now cause your viewer to crash immediately, you can run with this parameter to reset your options.

-local
This didn't work for me when I tried it, but it's supposed to run the viewer without connecting to the simulator. I was interested in seeing what that was like, and what exactly you could do without a simulator.

There is a full list of command line options here.

Go Board Updates

I was glad to see that one of the changes for the new server code being updated this week is "Support for PRIM_GLOW in llSetPrimitiveParams - this will require a forthcoming viewer update to author and compile scripts that use this, however". I was looking for this feature a few days ago because I wanted to add a feature to my Go board that made the last move glow.

Speaking of that, I have been spending a lot of time working on it since my last post (though I've been focused on the Mono testing these past few days). Most of the work has been in things that aren't finished, aren't visible, or were dead ends (at least I was learning how NOT to do things). Here is a quick list:

• The board state is now stored (storing 19x19 integers comes very close to the memory limit for scripts, so I had to make a script that is basically a data server and other scripts query the data through link messages).
• With the board state stored, I can now report an invalid move if a stone has already been played there.
• I added the board's rotation into the stone placement, so it no longer has to be aligned along the world y-axis to place the stones in the right place :P
• I spent a TON of time fooling around with llSetCameraParams, trying to get the camera to face straight down on the board from above. This was in preparation for an idea for a HUD which would overlay things onto the board. Unfortunately, the camera controls don't really allow for precise placement. I was able to get the camera to face straight down on the board, but I could not control the "roll" of the camera (up vector in more technical terms). The SL camera always tries to keep its up vector as vertical as possible. When the camera is facing straight down -- so the up vector becomes completely horizontal -- it apparently always points along the positive x-axis. I could not find a way to change this after much tweaking of the llSetCameraParams arguments. I had to give up.
  
• I started looking at HTTP requests. I had code for a multi-threaded web server from a networks class I took, so I got that running and was able to send a message to it from SL and get a response. It shouldn't be too hard to have it run copies of GNU Go and pass GTP messages back and forth.
• I downloaded QAvimator and started learning how to make animations.

This Go board project is pushing me to learn a ton of different aspects of Second Life content creation. It's great.

LSL Listen Mono Testing

I just did some Mono testing specifically with listeners, and came up with some interesting results. First I did a basic ping test. One object would start a timer and say "ping" to another object which would then say "pingback", and the original object would report the time when it received the message back. Averaged over 200 tests, without Mono the ping time was 0.066478 seconds. With Mono, it was 0.088936 seconds. I ran the tests multiple times, switching back and forth between Mono and non-Mono to make sure this difference was caused by Mono and not by other changes in the sim.

Next I took Robby's idea and had one object say "start" then "junk" 500 times then "finish". Another object would start a timer when it got the "start" message and report the time when it got the "finish" message. First, I used an unfiltered listener, so any messages sent on that channel would be forwarded to the script. The sender reported that it sent "finish" 0.600243 seconds after it sent "start". The receiver reported 33.476112 seconds between hearing the "start" and "finish" messages. I then recompiled with Mono and ran the test again. This time all the messages were sent in 0.178058 and received in 44.580690. The sending was over 3 times faster, but the receiving was slower with Mono.

Now I modified the script to only set up listeners specifically for "start" and "finish" messages. Without Mono, they were sent in 0.600193 seconds and received in 0.644574. With Mono, 0.133408 and 0.133169. All these numbers have taught me two important things: 1) USE FILTERED LISTENERS!!! 2) ESPECIALLY USE FILTERED LISTENERS WITH MONO!!!!!

Now comes the fun part. I copied the unfiltered listener so that there were 25 of them. Each of them ran at about the same time as the single listener. With 100, they still ran about the same. With 1000, still the same. With 10000 (I'm serious...screenshot below) it was finally a different story. First, the time the sender reported to send the messages shot up to 1.916057 seconds. From that number, I estimated it would take 10 minutes for the listeners to finish. I waited for 15 minutes, expecting a Linden to show up and wonder what the hell I was doing, and still there was no response from the listeners.Notice "Script perf" is 0 ips. I'm guessing they just haven't updated that to count Mono instructions.

With the filters, there wasn't much of a change until 400 prims (I increased the number of prims differently). At that level, the listeners finished between .133783 and .201377 seconds, but one of them took 45.042740 seconds, which is so close to the time for the unfiltered listeners it almost makes me think the server panicked and just started handing that one script all the messages. I doubt that's the case, though, because then scripts which used filters and as a result didn't have to check the incoming message would experience errors if they started getting unfiltered messages. At 800 prims, the range was .156157 - .224534, again with a single script reporting at 46.228270. At this point, I didn't go further because looking through a log of 800 messages was getting difficult. Looking back at the data from the unfiltered runs, there was similar variance in the times as seen here, but when it is taking 45 seconds it is much less significant.

One final weird behavior that I noticed while recreating these tests for the Jira issue (see below). I went back to the ping test and added filters for "ping" and "pingback". I didn't expect to see any difference, since all the messages sent are "ping" and "pingback" (on different channels, so that is already filtered). Indeed, there was no difference when not using Mono. But with Mono, it took longer! The time increased to 0.101741, which is an increase of about .02 seconds or a 25% increase.

In conclusion, I am definitely going to use filters all the time now. I have created a Jira issue about the performance decreases with Mono. Now what can I test!? :P

Benchmarking Mono-Compiled LSL

After Robby's response to my post about listener lag, I had the idea to see just what sort of speed improvements Mono will bring. I made a fairly simple benchmarking script that does the following tasks:

• Integer addition (7000 times)


• Float addition (7000 times)


• Integer multiplication (7000 times)


• Float multiplication (7000 times)


• Integer division (7000 times)


• Float division (7000 times)


• Grow a list by repeatedly inserting [0] (300 times)


• Randomize a list and sort it (100 times, list size 300)


• Break a string into a list of words and check whether each word is equal to "hello" or "world" (200 times)

The tasks are pretty basic. That last one is generally what a listener would do. I chose the number of times each would be repeated so that every task would take about 10 seconds.

In doing this, I discovered that the performance of standard LSL scripts is extremely variable. I configured the numbers so that each task would take 10 about seconds; at this point I was at my house on the normal grid. But when I logged into the beta grid and ran the script in a Mono sim (without compiling to Mono), the arithmetic tasks each took about 3 seconds. Thinking maybe for some reason normal LSL scripts also ran faster on Mono sims, I tried running it at various other sims on the Beta grid. In some it ran at 10 seconds, others 3 seconds, others 17 seconds. I couldn't really see a pattern (Havok1 vs. Havok4, Mono vs. non-Mono), although it was always 3 seconds on the Mono sims, but I did get 3 seconds once on a non-Mono Havok4 sim. The numbers fluctuated between sims, but if I ran it multiple times on the same sim, I would get about the same results. Are all the sims on the beta grid Tier 5? It probably just comes down to how much other stuff is going on in the sim. But the last 3 tasks were always about the same time...very strange.

Anyway, here are the results. For the non-Mono numbers, I chose the ones closest to 10 seconds.

Task	Non-Mono	Mono	% Increase	Times faster
Adding integers	12.356465	0.133350	9166%	92.662
Adding floats	12.643500	0.066761	18838%	189.385
Multiplying integers	12.310993	0.066601	18385%	184.847
Multiplying floats	12.556296	0.044415	28170%	282.704
Dividing integers	12.355354	0.066727	18416%	185.163
Dividing floats	12.555955	0.044925	27848%	279.487
List insertion	10.018719	0.000000	N/A	N/A
List randomize/sort	8.905011	0.000000	N/A	N/A
String tokenize	9.640886	0.138814	6845%	69.452
Total	103.343179	0.561593	18302%	184.018

So the claims that Mono is over 1000 times faster don't seem to hold up. But still...this is just amazing. I laughed out loud when the benchmark finished in under a second when I had just waited over a minute and a half for the previous one to finish. I especially like how the list operations were too fast to measure. I am going to make some changes tomorrow so that I can actually get some numbers that I can analyze. I also want to add some more tests that better simulate "real-world usage". If you have any ideas, please tell me.

Goban v0.1

Back in November I wrote about building a Go board. This past week I actually started building and scripting it, and without too much trouble it now has the basic functionality.There are still a lot of things I need and/or want to add. The biggest thing is probably that when a move is made that would capture stones, the board does not automatically remove them (the prims have to be deleted manually). Adding this feature is going to require me to store the board's state, which means more use of LSL lists, which have a strange and not very elegant set of utility functions.I also need to figure out how to attach the stones to the board after I rez them. If the board is moved, the stones will just stay there and be floating in space. Also, does anyone if there is a way to prevent those particle effects when something is rezzed or an object says something?There are two "modes". Two avatars can click on the board and join the game, and then the board will have them take turns placing stones. There is also a "Free Mode" where stones can be freely placed. Stones have to be placed by typing a command on chat channel 1. In game mode, you can just type "/1 d12" when it is your turn. In free mode, placing stones resembles the GTP protocol (e.g., "/1 play black d12" or "/1 play w k4), but you can specify more than one vertex in a single command and it will place them all. I'd like to allow placing stones by clicking, but I'm not sure if that's possible. I would have to put an invisible prim at each vertex to detect the click.

The board can be changed to 9x9 and 13x13 as well as the normal 19x19 size.Feel free to drop by my house and try it out, or IM me if you want someone to play against or to teach the rules (despite my interest in Go, I have not played many actual games and am not very good). Any suggestions or bugs reports are welcome.

Why Do Listeners Cause Lag?

This is something that I have never understood, and have always been a little skeptical about. I have heard many people saying that scripts which listen, especially on channel 0, are one of the biggest contributors to sim lag. Of course, anything that requires processing power is going to contribute to lag, but are listeners really one of the biggest contributors?

Even when there are tons of people around talking, the number of chat messages per second probably doesn't go above 5 on average. So each listen script would have the listen event triggered 5 times a second. For a computer that can process billions of instructions per second, I don't really see how that can have any significant impact.

Is there something I'm missing?

Update:
I just did a small test. I figure that most listen event handlers will tokenize the string and then check each token to see if it is a known command (probably will only check the first token, actually). Since in most circumstances, the message is not a command to that script, that is as much as it needs to do.

I wrote a program that tokenizes the string "This is a test message that will be processed by this program." and then checks whether each token is equal to "command", and reports how many times per second it is able to do that. Averaging over 120 seconds, it did it 101963 times per second. This is running on a machine here at school, and I'm not sure of the CPU speed. The OS is Solaris and the CPU type is Sparc. Also, my process was only getting 20% of the CPU.

Granted, this wasn't a very good test since there are so many unknowns, but at least it shows that there would have to be a lot of listeners to slow down the CPU.

Network Neutrality

This is an excellent video about the issue of network neutrality. I didn't realize that basically the same thing happened with printing and radio, which makes me even more scared about the possibility of this actually happening. If the internet loses network neutrality, it will most likely spell the end of Second Life (among many other things), as I'm pretty sure Linden Lab doesn't have the money to pay the telephone companies.

p.s. (What? I'm just stating facts, I'm not pushing a specific candidate :P)
Obama is for network neutrality and has promised to make it a priority for his first year in office.
Clinton has said she is for network neutrality, but it is not something she has mentioned as part of her campaign.
McCain is either genuinely undecided, or doesn't want to publicly say he's against it. He has been quoted as saying, "When you control the pipe you should be able to get profit from your investment."
Sources: 1,2,3,4,5