RunUO Community
This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
Update...
- Thread starter Ryan
- Start date
If I am not mistaken, it would remove saving from the main RunUO execution thread meaning the main thread would not be interrupted during a save as it happens with version 1.0. Saves would happen in a seperate thread running along side the main thread making it appear as though saves were happening in the background.
madphatboy2
Wanderer
raulpica said:
That's fine with me. Normally I'm not that bugged by stupid posts, but for some reason that one really got to me. But thx for having the balls to let me know you reciprocated.
Cerberus said:
dual threaded saving, would mean that two different threads are being used to save the world. This would be used for instance shards the power of multiple cores or virtual cores.
parrel while similar is different. I believe this is the one he was going to work on and was dreding ( since its a pain to code something like this ) basicly two different threads saving the same file then you have to 'merge" the threads together at some point.
Dual threaded saving would not gain any real performance gain if a shard didn't have a dual core cpu. Parrel threading you might get a small performance gain, like always threading the saves then having a crash is a really bad idea.
So if your not experienced with running a shard that doesn't crash, I would advice using any sort of threaded saving.
I might have switched the two descriptions, as I am running on almost no sleep.
Phantom said:
Excellent .. that sounds as if its gonna be a great feature ( but a real pain in the ass to code so good luck with that Krrios ).. TY for that...Now im gonna have to convince my wife i need a dual cpu pc .. I'll use the fact that i dont want the devs time to be wasted by me not running it properly as the perfect excuse
.Courageous
Wanderer
It might not even if it did. No number of CPU's will make a hard drive faster. For it to improve the save rate, the serialization protocol would have to be sufficiently computationally intensive to create an observably slower time than the already ridiculously slow (comparatively speaking) disk system itself.
Has anyone performed this analysis?
C//
Isn't the idea of a seperate thread to handle saving designed to address precisely just what you're talking about? As it stands, the server must stop and wait while the world saves to the server's hard drive. Would it not be the case that saving would now be the task of a second thread thereby freeing up the main thread to continue execution without waiting for the disk subsystem? It would be the job of the second thread to wait for the disk subsystem, correct? In which case, it wouldn't matter how slow or fast the server's hard drive is because the main thread has nothing to do with saving anymore. Or is my understanding of the purpose of the second thread somewhat flawed?Courageous said:
Courageous
Wanderer
WeEzL said:
"It depends". Suppose the serialization protocol were very cheap. The main thread could quickly being serializing out the server to a separate region of memory (not disk). Once done, it would go back to the main, and the second thread would take over flushing the buffers. One problem, of course, is that one has to presume enough memory available to do this (which is actually doubtful on virtually every running RunUO server in existence, IMO).
Note that simply telling thread two to persist the world objects in the main thread could run into severe transactional integrity problems. One cannot persist the entire world at once, so objects that depend on the state of other objects could suddenly be out of sync with eachother. In the worst case.
There are probably a number of interesting hacks that could be made given the ability to find clever ways to ditch the shared state problem...
Which is to say, we can't rule anything out, but it's simply not as easy as you might think.
C//
Courageous
Wanderer
Interesting article. It was of course about using buffered io, probably on the grounds that it can collect atoms up into something resembling logical page writes. The article does mention that DOTNET does this under the hood anyway.
Thanks for the article. It was interesting.
C//
Thanks for the article. It was interesting.
C//
Courageous
Wanderer
And changing bufferSize from 4K to 64K could make a slight difference.
IO buffrering size, when implemented manually, should always be some positive integral value, at least 1, multiplied by the page size of the operating system.
Having the IO buffer match the page size is the low hanging fruit.
Isn't Windows page size 64K? I recall that it is.
C//
IO buffrering size, when implemented manually, should always be some positive integral value, at least 1, multiplied by the page size of the operating system.
Having the IO buffer match the page size is the low hanging fruit.
Isn't Windows page size 64K? I recall that it is.
C//
autumntwilight
Sorceror
Sorry to say but I think the lesson here can be summed up by make your own 2.0 by learning C# and making full ML & SE, & upgrading core etc. yourself, or wait on the pending release of RunUO 2.0. The reality sucks, but it's the bitter truth 
. I have some 2.0 features like a core that runs on MS Framework 2.0 instead of 1.1 or 1.0 myself, but I know what the RunUO dev team has locked up is far superior to what anyone can make. We're all just gonna have to wait or make our own. Sadly there is no other realistic way.
. I have some 2.0 features like a core that runs on MS Framework 2.0 instead of 1.1 or 1.0 myself, but I know what the RunUO dev team has locked up is far superior to what anyone can make. We're all just gonna have to wait or make our own. Sadly there is no other realistic way.