Update...

[Phantom]

Originally Posted by Burner

hey, id just like to say great job on the runuo project to all the dev team members, im sure you all keep updated on this update thread daily, lol, I hope the server repair is going ok. any ways, if possible could u give us another update on the status of things, set backs, or anything else that might help hold over a lot of peoples anticipations? if not thats fine, keep up the great work! ^_^

I know Krrios was working on dual and parrel threaded saving, couple days ago since he got his dev machine backup.

[Ravenal]

Originally Posted by Phantom

I know Krrios was working on dual and parrel threaded saving, couple days ago since he got his dev machine backup.

That seems like a nice feature

[Cerberus]

Originally Posted by Phantom

I know Krrios was working on dual and parrel threaded saving, couple days ago since he got his dev machine backup.

Im gonna show my ignorance here .. but what exactly is that ..... does that decrease the world saves time. ( Sorry for the dumb question but i gotta ask... )

[WeEzL]

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.

[raulpica]

Originally Posted by WeEzL

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.

That's really c00l so i want runuo2.0 for that.

madphatboy2 you're phat and bad, you got me negative karma and i got you

[madphatboy2]

Originally Posted by raulpica

madphatboy2 you're phat and bad, you got me negative karma and i got you

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. :P

[Phantom]

Originally Posted by Cerberus

Im gonna show my ignorance here .. but what exactly is that ..... does that decrease the world saves time. ( Sorry for the dumb question but i gotta ask... )

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.

[Anti-Basic]

Originally Posted by raulpica

That's really c00l so i want runuo2.0 for that.

madphatboy2 you're phat and bad, you got me negative karma and i got you

wow. The stupidity of that post makes me want to teabag a running garbage disposal.

[WarAngel]

Originally Posted by Anti-Basic

wow. The stupidity of that post makes me want to teabag a running garbage disposal.

I do that all the time. It's quite fun.

[Anti-Basic]

Originally Posted by WarAngel

I do that all the time. It's quite fun.

I bet you do.

[Sunshine]

Originally Posted by Anti-Basic

wow. The stupidity of that post makes me want to teabag a running garbage disposal.

Giggles you are soo funny

[Cerberus]

Originally Posted by Phantom

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.

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]

Dual threaded saving would not gain any real performance gain if a shard didn't have a dual core cpu.

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//

[WeEzL]

Originally Posted by Courageous

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.

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]

Originally Posted by WeEzL

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?

"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//

[noobie]

here is a great document for I/O benchmark results in NEt 2.0

dev team might want to look at it..

p.s unbuffered i/o seems interesting
any server using raid could gain incredible performans by that.

[Courageous]

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//

[noobie]

Buffer is implemented in RunUO manually since it doesnt use BinaryWriter class itself. Implementation seems fine but it might be better to use built-in classes to handle buffer. And changing bufferSize from 4K to 64K could make a slight difference.

[Courageous]

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//

[autumntwilight]

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.

[Courageous]

*shrug*

Some of us are software people. Regardless of the 2.0 release timing, we're interested in the technical topics.

C//

[WarAngel]

Originally Posted by autumntwilight

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.

As opposed to what other option...?

[Iron Soldier]

Why does things just happne every time the come close to releaseing just thinks its a joke oh well list i aint one of this poor childern waiting for it cause that would take rest of my life. and i got much more better things to do side spend all day indoors.

[raulpica]

Originally Posted by Anti-Basic

wow. The stupidity of that post makes me want to teabag a running garbage disposal.

Yeah, run it on ya OWN. So bad karma 4 ya!! Tea is good if with lemon! Expecially Lipton's Ice.


But the question is still one... Where'z Runuo2.0? Why there is not an update?
Where are youuuuuuu Scooby.... err.... Ryan?

[Anti-Basic]

Originally Posted by raulpica

Yeah, run it on ya OWN. So bad karma 4 ya!! Tea is good if with lemon! Expecially Lipton's Ice.


But the question is still one... Where'z Runuo2.0? Why there is not an update?
Where are youuuuuuu Scooby.... err.... Ryan?

#1 you have 0 reputation, therefore you cannot give anyone karma, good or bad. I got a message, but it didnt affect my kamra

#2 Tea is gross, thats my opinion, but either way, I was using it in a completely different context.

#3 Stop asking for 2.0 or I will hit you upside the head with a giant Watermelon

Mr. T says to shut the fuck up about 2.0