• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

CPU/memory usage measurement.

jlnunez89

a.k.a BurnMc
Premium User
Joined
Jul 5, 2007
Messages
177
Solutions
1
Reaction score
70
Location
Seattle, WA
Hi.

If anyone would be so kind as to measure their current CPU usage of a TFS (vanilla) distribution, single player, no movement at all. I want to compare it to the implementation I'm creating in C#.

If you happen to have the measument of this setup's memory using tibia map as well, that would be awesome.

I guess any tibia version works, but 7.7~ish is preferred.

Thanks!
 
Last edited:
Wouldn't CPU usage vary depending on the processor used?? If so it would be pretty pointless to compare with your own cpu:eek:
 
I could run some tests for you if you provide me with the datapack (real tibia map). But since you're using cipsoft's files my guess would be to compare against that first. Ohh, I can also only provide you benchmarks from linux systems.

Having in mind you want to compare statically compiled application with C# application running on top of .NET runtime I'm pretty sure you know your memory consumption will be higher - I won't guess here, but I'd bet 4 apples and 2 mangos at least. Getting to my point, I see no reason to do such comparison really. I think you'd be much better testing its performance.

But since you requested the measurements, if you provide me with datapack, I will be glad to provide these. I would also like to point out, that .NET (at least at the times I used to work with it) applications are consuming more and more memory after a while of running. One hint, if you haven't done that already: GC server mode (depending on your architecture).

I'm not mentioning CPU anywhere here - look the post above for the reason.
 
Wouldn't CPU usage vary depending on the processor used?? If so it would be pretty pointless to compare with your own cpu:eek:

I think you're right, I'll have to set up and run a distribution myself to keep that out of the variables :(
I guess a better question would be, what's the most resource intensive thread/calculations that the usual OTServ distributions have?

Right now, the thing I've built keeps my CPU's usage on 0% even with all monsters "thinking". I've been keeping a close eye for multithreaded programming antipatterns, but it seems too good to be true, hehe.

I could run some tests for you if you provide me with the datapack (real tibia map). But since you're using cipsoft's files my guess would be to compare against that first. Ohh, I can also only provide you benchmarks from linux systems.

Having in mind you want to compare statically compiled application with C# application running on top of .NET runtime I'm pretty sure you know your memory consumption will be higher - I won't guess here, but I'd bet 4 apples and 2 mangos at least. Getting to my point, I see no reason to do such comparison really. I think you'd be much better testing its performance.

But since you requested the measurements, if you provide me with datapack, I will be glad to provide these. I would also like to point out, that .NET (at least at the times I used to work with it) applications are consuming more and more memory after a while of running. One hint, if you haven't done that already: GC server mode (depending on your architecture).

I'm not mentioning CPU anywhere here - look the post above for the reason.

Memory, on the other hand, is soaring at 5.4+ gb. I'll soon do a refactor and see where I can save some of it. Also thanks for the tip! I didn't know about the different GC modes.

I grabbed this project to learn more on multithreaded programming and memory usage profiling / optimization ... not disappointed of the challenges so far, haha.
 
Last edited:
I think you're right, I'll have to set up and run a distribution myself to keep that out of the variables :(
I guess a better question would be, what's the most resource intensive thread/calculations that the usual OTServ distributions have?

Right now, the thing I've built keeps my CPU's usage on 0% even with all monsters "thinking". I've been keeping a close eye for multithreaded programming antipatterns, but it seems too good to be true, hehe.



Memory, on the other hand, is soaring at 5.4+ gb. I'll soon do a refactor and see where I can save some of it. Also thanks for the tip! I didn't know about the different GC modes.

I grabbed this project to learn more on multithreaded programming and memory usage profiling / optimization ... not disappointed of the challenges so far, haha.

I just launched a 10.98 Real Tibia Map TFS 1.2/1.3 today to see how it goes and it went up to 3GB, so I wouldn't say 5.4GB is anywhere down the limits. I have hard times comparing C++ vs C# memory consumption, but my guess would be you should reach 3GB~ for Tibia 7.7 (but don't really care about this, just keep it performant, memory is cheap).

As for the CPU, your monsters are not "thinking" if there's no player around, they should be idle. You will know what's the most CPU intensive when you start profiling it! :)
 
but my guess would be you should reach 3GB~ for Tibia 7.7 (but don't really care about this, just keep it performant, memory is cheap).
with no players on server, his goal should be less than 10mb memory, 3gb of memory just to keep something up is a huge waste
I guess a better question would be, what's the most resource intensive thread/calculations that the usual OTServ distributions have?
last time i've checked, tfs 1.1:
Connection thread spends 95% of his time doing XTEA, game thread can't remember exactly numbers, but it was almost all the time doing these things, game->getSpectators, map->getTile, heap alloc/dealloc, game->getPathTo and looking up for item attributes
 
with no players on server, his goal should be less than 10mb memory, 3gb of memory just to keep something up is a huge waste

last time i've checked, tfs 1.1:
Connection thread spends 95% of his time doing XTEA, game thread can't remember exactly numbers, but it was almost all the time doing these things, game->getSpectators, map->getTile, heap alloc/dealloc, game->getPathTo and looking up for item attributes

I thought so about pathfinding on the game thread. Map getting tiles is constant in my implementation cause I use a 3 dimensional array, but because of this, all map tiles are in memory, hence the 4gb upon load, and why your 10 mb is impossible, hehe.

Thanks for the info!
 
I thought so about pathfinding on the game thread. Map getting tiles is constant in my implementation cause I use a 3 dimensional array, but because of this, all map tiles are in memory, hence the 4gb upon load, and why your 10 mb is impossible, hehe.
i've archived that in a old project, you only need tiles that are being used, if there is no player, there is no reason to keep it
 
Hi.

If anyone would be so kind as to measure their current CPU usage of a TFS (vanilla) distribution, single player, no movement at all. I want to compare it to the implementation I'm creating in C#.

If you happen to have the measument of this setup's memory using tibia map as well, that would be awesome.

I guess any tibia version works, but 7.7~ish is preferred.

Thanks!

You shouldn't have CPU usage when there is no movement at all, because the dispatcher thread is constantly in a waiting state for something to happen.
 
i've archived that in a old project, you only need tiles that are being used, if there is no player, there is no reason to keep it

Well yeah, sure, but you're talking about an optimization, in which only a certain window of size X,Y,Z is loaded into memory for each player there is on the map, in which case the worst case scenario is still that there are sufficient players (which is an unbounded variable) to be precisely at those positions in which the whole map is loaded; therefore the whole map is in memory and the size of that is... 3~4 gb in this case :p

but yeah, that is a nice optimization to have, did you stick to it in your current project(s) ?
 
Last edited:
You shouldn't have CPU usage when there is no movement at all, because the dispatcher thread is constantly in a waiting state for something to happen.

Yup, got a similar architecture in my implementation :) thanks!
 
Well yeah, sure, but you're talking about an optimization, in which only a certain window of size X,Y,Z is loaded into memory for each player there is on the map, in which case the worst case scenario is still that there are sufficient players (which is an unbounded variable) to be precisely at those positions in which the whole map is loaded; therefore the whole map is in memory and the size of that is... 3~4 gb in this case :p

but yeah, that is a nice optimization to have, did you stick to in in your current project(s) ?

Actually, let's elaborate on this. For Cip files, it would be easier to implement as you're already given sectors (a nice way to slice our map).

A) A player appears on a sector, lets load that and the 8 surrounding sectors as well.
B) A player moves to a diferent sector, load the N surrounding sectors that are not loaded yet, and unload the now-non-used sectors.

This of course assumes I got a data structure that can at least load/unload in NlogN time, and on it's own dedicated thread... further thoughts?
 
Actually, let's elaborate on this. For Cip files, it would be easier to implement as you're already given sectors (a nice way to slice our map).

A) A player appears on a sector, lets load that and the 8 surrounding sectors as well.
B) A player moves to a diferent sector, load the N surrounding sectors that are not loaded yet, and unload the now-non-used sectors.

This of course assumes I got a data structure that can at least load/unload in NlogN time, and on it's own dedicated thread... further thoughts?

You should unload sectors on specified intervals, not after each player move, rather like every 30 minutes or so, simply unload sectors with a very old timestamp, and update this timestamp whenever a player is seen on sight (e.g; sending tile structure).
 
with no players on server, his goal should be less than 10mb memory, 3gb of memory just to keep something up is a huge waste

last time i've checked, tfs 1.1:
Connection thread spends 95% of his time doing XTEA, game thread can't remember exactly numbers, but it was almost all the time doing these things, game->getSpectators, map->getTile, heap alloc/dealloc, game->getPathTo and looking up for item attributes

Well, you may be right on the memory usage, although it's usually memory vs performance (and CPU utilization) if you dynamically load and unload map fragments. But I agree that it should at least be tried out to see how performant this may be. I'm not sure if this is something that has been tested by TFS dev team, but at this time I think TFS loads the whole map (hence 3GB on "idle" server with real tibia map).

As for most intensive tasks it was my guess that encryption / decryption would be among these with the "area" scanning algorithms.

Actually, let's elaborate on this. For Cip files, it would be easier to implement as you're already given sectors (a nice way to slice our map).

A) A player appears on a sector, lets load that and the 8 surrounding sectors as well.
B) A player moves to a diferent sector, load the N surrounding sectors that are not loaded yet, and unload the now-non-used sectors.

This of course assumes I got a data structure that can at least load/unload in NlogN time, and on it's own dedicated thread... further thoughts?

It would be easier as long as you can also keep all changes done to these somewhere, so basically just like cip files do (keeping the "live" map dumps). Correct me if I'm wrong, but using a hashmap to store sector ID => sector file name you should be able to load in O(1) time (assuming you have your map file split into sectors), calculating surrounding sector IDs is not a problem if you know width and height of your map (in sectors).
 
Memory = cheap and you can get almost unlimited amount in every datacenter
CPU power on single core = expensive and it's very limited, fastest CPU that is available in datacenters is intel 7700k overclocked to 4.7GHz

Picking tile from memory cost should be O(1) [big array?], so it's good to keep it all in RAM. If you want to load it from HDD remember that access to HDD is around 1000x slower.

You should also remember that there are scripts that affect areas without players (magic effects on teleports etc.) and it would require a lot of work (rewrite scripts) to make it work only when player see that tile.

I think that final TFS version should load everything (players, items, depots, houses) from database at start (and serialize it all to Item*, Container* etc. objects) and save everything when admin close server.
Loading things from database is second thing (after all network attacks) that can make your ots lag.

It's hard to compare simple C# server with TFS as TFS offers much more that requires 'real map tibia' server.


---------------------------------------------------
If you got some time for programming try to make multi-threaded OTS and check if it's possible to make some important calculations parallel.
On old RL tibia there were movies from wars where people heal dead body on floor and player get up. Maybe because of multicore programming and compromise between synchronization and maximum number of players online tibia.com servers?
 
I think that final TFS version should load everything (players, items, depots, houses) from database at start (and serialize it all to Item*, Container* etc. objects) and save everything when admin close server.
Loading things from database is second thing (after all network attacks) that can make your ots lag.
And how to handle crashs? rollbacks? I think the solution for database "lag" is asynchronous queries. Ask the database for the character database data and while the answer is not there the server do something else.
 
did you stick to it in your current project(s) ?
i will try to dig out from old svn backups that i have, that was really nasty, map was hard coded
This of course assumes I got a data structure that can at least load/unload in NlogN time, and on it's own dedicated thread... further thoughts?
you can also set a flag to force some sectors to keep around, for cities for example, where almost all the time someone will be around
Memory = cheap and you can get almost unlimited amount in every datacenter
CPU power on single core = expensive and it's very limited, fastest CPU that is available in datacenters is intel 7700k overclocked to 4.7GHz

Picking tile from memory cost should be O(1) [big array?], so it's good to keep it all in RAM. If you want to load it from HDD remember that access to HDD is around 1000x slower.

You should also remember that there are scripts that affect areas without players (magic effects on teleports etc.) and it would require a lot of work (rewrite scripts) to make it work only when player see that tile.

I think that final TFS version should load everything (players, items, depots, houses) from database at start (and serialize it all to Item*, Container* etc. objects) and save everything when admin close server.
Loading things from database is second thing (after all network attacks) that can make your ots lag.

It's hard to compare simple C# server with TFS as TFS offers much more that requires 'real map tibia' server.
your statement ignores completely that the highest bottleneck on hardware nowadays is that memory is overwhelmingly slow, most optimistic statics says that cpu is 50~60% of its uptime waiting for data from memory, if you load everything from memory, basically you'll need a giants linked lists, which is the worse way to get performance from cpu, because cpu will need go to memory all the time it needs a data, if you're looking for cpu performance, avoid as much as you can make cpu go get things in main memory, because any 1ghz cpu is much faster than memory can feed it, there is some techniques recommended by intel on his dev manual, mainly it's use smaller data types, keep your data organized to avoid alignment holes this means to avoid dynamic allocation, at runtime it may introduce holes and spread data around, avoid data structures that exhibit irregular access patterns, and favor linear data structures, and your design proposed go completely against proposed by intel manual.
11.6.13
https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
 
And how to handle crashs? rollbacks? I think the solution for database "lag" is asynchronous queries. Ask the database for the character database data and while the answer is not there the server do something else.

What is the problem with rollbacks? Every server has this, otherwise you'd have duplicate items going on everywhere. About crashes, you make sure you don't crash, like Gesior stated for example, arrays of objects, also known as object slots, I'm making a C++ game server for educational purposes only, and I've made it that way, including better find spectators compared to TFS current architecture, I use a big array for storing the game map like CipSoft, they use a QTree
 
i will try to dig out from old svn backups that i have, that was really nasty, map was hard coded

you can also set a flag to force some sectors to keep around, for cities for example, where almost all the time someone will be around

your statement ignores completely that the highest bottleneck on hardware nowadays is that memory is overwhelmingly slow, most optimistic statics says that cpu is 50~60% of its uptime waiting for data from memory, if you load everything from memory, basically you'll need a giants linked lists, which is the worse way to get performance from cpu, because cpu will need go to memory all the time it needs a data, if you're looking for cpu performance, avoid as much as you can make cpu go get things in main memory, because any 1ghz cpu is much faster than memory can feed it, there is some techniques recommended by intel on his dev manual, mainly it's use smaller data types, keep your data organized to avoid alignment holes this means to avoid dynamic allocation, at runtime it may introduce holes and spread data around, avoid data structures that exhibit irregular access patterns, and favor linear data structures, and your design proposed go completely against proposed by intel manual.
11.6.13
https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
" because cpu will need go to memory all the time it needs a data" - and where should it go to get data? got any faster source of data? if you program GOT TO process some data, it must use RAM! If you make it load data from HDD to RAM every request it will be much slower, because it will spend time to load from HDD to RAM and then it will have to load it from RAM to CPU anyway.

Linked list? for what? Linked list is good when you need FIFO/LIFO -read of random element from linked list is super slow. Any reason to use linked list, not binary tree/array to keep tiles and items?? If you use offset of 30000 (empty space on RL map) you can even keep that 5000x5000x15 map in one big table - it's just ~2.4GB of tile 'pointers' (on x64).

"keep your data organized to avoid alignment holes this means to avoid dynamic allocation" - that's what I said, load all at start, put it slowly in best data structure to make it accessible in O(1) time.
Never heard about relation between memory useage (1 or 50GB) and program speed (except case when you try to allocate big blocks of memory when memory is almost full, BUT I DONT WANT TO ALLOCATE ANYTHING! :) )
 
Back
Top