.NET 4.0 Standard - VS 2010 Solution

[Pure Insanity]

You haven't programmed any specific .net 4.0 features...the features you quoted me on are specific features programmed into RunUO that uses the .net 4.0 framework. Bit different...doesn't matter for your project.

 

[ASayre]

I have no idea why this was locked, and this is valid community input.

These are the only known 'compatibility' issues with .NET 2.0 -> 4.0:

http://msdn.microsoft.com/en-us/library/ee941656.aspx

None of these apply towards RunUO.

 

[Pure Insanity]

Meh, don't get yourself banned too ASayre.

It was locked because this place is ran like North Korea lately.

 

[mumuboy]

The only thing I would ask, is if someone could make an automated way to detect Assemblies.cfg for 4.0, versus Assemblies.cfg for 2.0. I bring this up since System.Core.dll is needed to compile in .NET Framework 4.0.
Of course a Visual Studio solution would solve this too.

 

[Vorspire]

ASayre has posted VS files in Releases forum.

**
ASayre our results on the Dynamic Save Strategy are in;

Based on 200 average active players on a shard with a couple million items and a few tens of thousands of mobiles;
We cut world saves down to 10 seconds from an average of 20 - 30 seconds.
We're running on a high-end server so hardware makes the results more accurate.
Would you recommend Unit Testing on the system somehow for even more accurate results?

There has been one issue though that may need to be addressed quickly;
After a period of 4 hours, the saves start gaining time, the amount of time is not equivalent to the increase in mobiles and items to be saved during that time.
The amount of time gained is an average of 1 to 3 seconds on each consecutive save.
Eventually this time will reach a point where it matches the old save times, at this critical point, the shard starts hanging and won't accept connections.
Although this does not happen every time, it has happened twice as far as I know.

However, the positives have surely outweighed the negatives with the system and we are very impressed with the results.
We had forked out in the past for super-fast SSD drives for the server to decrease the save times, but that only made a 5 second difference!

Thanks for the Dynamic Save Strategy, well worth the time and effort put in

 

[Zagros]

I have to say vorspire is right and adding support to compile under 4.0 is a good idea, we run our own fork for RunUO and I'll have to say that the move from 2.0 to 4.0 has been nothing but beneficial. Don't quote me but from paradyme told me awhile back. It's as simple as afew edits in every script which doesn't take alot; and the notice in compile times dropped by almost half, aswell as our saves.


*I came back to download our server for backup and noticed that he took the time to backup and edit every single file by hand musta took him awhile.*

 

[aralith]

I'm glad this was reopened. It broke my heart to see it had been locked.

 

[Kraz]

Good to hear ASayre still alive.

 

[fwiffo]

There has been one issue though that may need to be addressed quickly;
After a period of 4 hours, the saves start gaining time, the amount of time is not equivalent to the increase in mobiles and items to be saved during that time.
The amount of time gained is an average of 1 to 3 seconds on each consecutive save.
Eventually this time will reach a point where it matches the old save times, at this critical point, the shard starts hanging and won't accept connections.
Although this does not happen every time, it has happened twice as far as I know.

Same with us, but we didn't notice locks correlated with saves, since our server saves once every 2 hours.
The only thing I noticed, after attaching a debugger and let the server run normally, is that it locks in the try{}catch{} trap recently inserted by mark in the map.cs into SVN, why this is happing is obscure to me. Removing the trap removes the issue, at least onto our server, that doesn't have the numbers of players like yours, but at least has from 50 to 100 player average.

 

[Vorspire]

We solved the problem by disabling the networking portion of the Framework_4_0 preprocessor symbol - effectively split it into two symbols so we could alternate the systems for testing.

It seems that when the advanced 4.0 sockets are being used, NetStates become unstable to a degree, we saw an increase in caught exceptions thrown by NetStates in the console.

I have to correct the info I posted though, as our server hasn't actually tested the Dynamic Save Strategy - we don't have 16 cores on the server - which is the point at which the DSS would be called into action.

So, here's the latest result:

Compile the core with .NET 4.0
Enable the new Framework_4_0 save strategy code
Disable the new Framework_4_0 networking/sockets

With this set-up, we have still achieved reducing the save times by up to 30 seconds.
Average players online is almost peaking 300 now - the average save time is 10 seconds, there are over 6 million items in the world.
The server has been running without a single crash, glitch, exception or fail for two weeks now and the save times remain consistent.

 

[Pure Insanity]

The Dynamic Save Strategy has shown improvements for me, even on just a quad core. I believe ASayre set it to 16 to keep it from being used unless someone wanted to use it. Really it would work with anything more than one processor. 16 would be lovely though, would love to see results on something like that.

 

[Vorspire]

We could have tested it with 4 cores, but because the server is a production shard, we can't take further risk after the previous glitches and since it's running great right now, we don't see any reason to change it just yet - maybe in the future we can test it again

 

[ASayre]

Should check the latest SVN: Just pulled out the networking stuff into it's own preprocessor. The dynamic save strategy really should be enabled for anything > 2 cores (With 2 cores, easiest to just split it into Mobile/Items, and not have to worry about the parallelization overhead. Though empirical evidence may prove me wrong )

But, correct, it was originally set at 16 back under the old save strategy as THAT had issues, and we didn't want anyone to use it. I was just waiting on some production-level shards to confirm that the dynamic has been without problems before dropping the count down

 

[Pure Insanity]

Hard to check the latest svn, as the web svn gets broke about every other day...

I wish to god that they'd move the damn svn to something that they don't have to constantly fix.

But nice to see you still sticking around and getting stuff done ASayre. =D

 

[ASayre]

SVN back up. Give me a heads up on time differences and stats between old save strategy and new on a production server

 

[ASayre]

Also, I refute any claims that I am actually here and, y'know, doing stuff. All rumors.

 

[Vorspire]

Here or not Asayre, this community will always have well-placed respect for you and the work you've done and are trying to do now, without obligation - The very fact that you post now and again keeps the faith in the community going imo

 

[Foul]

We solved the problem by disabling the networking portion of the Framework_4_0 preprocessor symbol - effectively split it into two symbols so we could alternate the systems for testing.

It seems that when the advanced 4.0 sockets are being used, NetStates become unstable to a degree, we saw an increase in caught exceptions thrown by NetStates in the console.

I have to correct the info I posted though, as our server hasn't actually tested the Dynamic Save Strategy - we don't have 16 cores on the server - which is the point at which the DSS would be called into action.

So, here's the latest result:

Compile the core with .NET 4.0
Enable the new Framework_4_0 save strategy code
Disable the new Framework_4_0 networking/sockets

With this set-up, we have still achieved reducing the save times by up to 30 seconds.
Average players online is almost peaking 300 now - the average save time is 10 seconds, there are over 6 million items in the world.
The server has been running without a single crash, glitch, exception or fail for two weeks now and the save times remain consistent.

sorry to dig this up once more, but this issue has been resolved in the latest SVN correct?

 

[ASayre]

Don't use the new networking code. That's been separated out into a different preprocessor directive, so the Framework_4_0 directive should be fine now, in theory.

 

[mumuboy]

What is wrong with the new networking code?