MC-Server on Raspberry Pi

[xoft]

It depends on what you want to do on the server. The best option is hosting a creative-only server, where the world generation is really not a wanted feature - instead you want to generate as little world as possible and give the players the most space for building ("flat" level style in vanilla minecraft). That can be done by configuring the world.ini to use a constant biome, flat height and possibly even same block composition, with no generated structures and no finishers. This results in the world generation being almost instantenous, and should be perfectly usably on the RasPi.
If, on the other hand, you want to host a survival server with a wilderness world, then you're out of luck, the generator will be slow and there's not so much we can do about it. You can try disabling some parts of the generator that you can do without. From my measurements on the Win platform, the generator parts ordered from the most consuming to least consuming, is this:

Code:

31 %  | trees
20 %  | wormnestcaves
7.8 % | ravines
7.2 % | ditortedvoronoi biomes
3 %   | biomal terrain composition

The rest are under 1 % each. Note that the sum gives only about 65 %, because that's the part of MCServer run time that generator eats up. Also some algorithms are not included in this roundup (no need to have two different cave algorithms); as STR_Warrior already points out, MarbleCaves are notoriously slow (about 5 times slower than any other caves algorithms); DualRidge caves are somewhere in between IMHO (not measured)

For details on configuring the world.ini, have a look at the wiki page about world.ini, which I try to keep as much up-to-date as possible:
http://www.mc-server.org/wiki/doku.php?i...:world.ini

Thanks for the makefile modification, I'll try that at home on my RasPi and see if I can squeeze some more performance out of it.

[kfricke]

To speed the generation up change in the world.ini marblecaves to wormnestcaves

Yeah, did that and now the world generates at nearly double the speed. Considering the fact that chunks do get generated during the usual uptime of the server, this should also yield an average better performance, right?

Code:

[14:36:14] --- Started Log ---
[14:36:14] Error (2) opening directory "world/player/"

[14:36:14] Creating new server instance...
[14:36:14] cSocketThreads startup
[14:36:14] Starting server...
/============================\
|   Custom Minecraft Server  |
|  Created by Kevin Bansberg |
|       A.K.A. FakeTruth     |
| Monsters by Alex Sonek     |
|       A.K.A. Duralex       |
| Stuff by Mattes D          |
|       A.K.A. _Xoft(o)      |
\============================/
More info: WWW.MC-SERVER.ORG
           WWW.AE-C.NET
           WWW.RBTHINKTANK.COM
email: faketruth@gmail.com

[14:36:14] Starting up server.
[14:36:14] Compatible clients: 1.2.4, 1.2.5, protocol version 29
[14:36:14] Port 25565 has been bound, server is open for connections
[14:36:14] Creating WebAdmin...
[14:36:14] Starting WebAdmin on port 8080
[14:36:14] Loading settings...
[14:36:14] -- Loading Groups --
[14:36:14] Loading group: Admins
[14:36:14] Permission: *
[14:36:14] Loading group: Mods
[14:36:14] Permission: core.time
[14:36:14] Permission: core.item
[14:36:14] Loading group: Vips
[14:36:14] Permission: core.teleport
[14:36:14] Loading group: Default
[14:36:14] Permission: core.build
[14:36:14] Permission: core.help
[14:36:14] Permission: core.playerlist
[14:36:14] Permission: core.pluginlist
[14:36:14] Permission: core.spawn
[14:36:14] -- Done Loading Groups --
[14:36:14] -- Loading crafting recipes from crafting.txt --
[14:36:15] -- 189 crafting recipes loaded from crafting.txt --
[14:36:15] -- Loading furnace recipes --
[14:36:15] Got 9 furnace recipes, and 11 fuels.
[14:36:15] -- Done loading furnace recipes --
[14:36:15] Loading worlds...
[14:36:15] cWorld::cWorld(world)
[14:36:15] [Generator]::BiomeGen value not found in world.ini, using "DistortedVoronoi".
[14:36:15] Using a cache for biomegen of size 64.
[14:36:15] [Generator]::HeightGen value not found in world.ini, using "Biomal".
[14:36:15] Using a cache for Heightgen of size 64.
[14:36:15] [Generator]::CompositionGen value not found in world.ini, using "Biomal".
[14:36:15] Loading plugin manager...
[14:36:15] Loading plugins
[14:36:15] Binding /mc (magiccarpet)
[14:36:15] Initialized MagicCarpet v.1
[14:36:15] Initialized ChatLog v.2
[14:36:16] Binding /help (core.help)
[14:36:16] Binding /pluginlist (core.pluginlist)
[14:36:16] Binding /tp (core.teleport)
[14:36:16] Binding /item (core.item)
[14:36:16] Binding /i (core.item)
[14:36:16] Binding /list (core.playerlist)
[14:36:16] Binding /who (core.playerlist)
[14:36:16] Binding /playerlist (core.playerlist)
[14:36:16] Binding /motd (core.motd)
[14:36:16] Binding /reload (core.reload)
[14:36:16] Binding /stop (core.stop)
[14:36:16] Binding /time (core.time)
[14:36:16] Binding /spawn (core.spawn)
[14:36:16] Binding /home (core.spawn)
[14:36:16] Binding /kick (core.kick)
[14:36:16] Binding /ban (core.ban)
[14:36:16] Binding /unban (core.unban)
[14:36:16] Binding /top (core.top)
[14:36:16] Binding /gm (core.changegm)
[14:36:16] Binding /gotoworld (core.gotoworld)
[14:36:16] Binding /coords (core.coords)
[14:36:16] Binding /viewdistance (core.viewdistance)
[14:36:16] Binding /regeneratechunk (core.regeneratechunk)
[14:36:17] Core: loaded 466 item names.
[14:36:17] Core: loaded 2 whitelisted players.
[14:36:17] cWebPlugin::cWebPlugin()
[14:36:17] Initialized Core v.8
[14:36:17] Loaded 3 plugin(s)
[14:36:17] Loading MonsterConfig...
[14:36:17] Starting Authenticator...
[14:36:17] Starting worlds...
[14:36:17] Preparing spawn area in world "world"...
[14:36:17] 39 chunks to load, 359 chunks to generate
[14:36:19] 0 chunks to load, 379 chunks to generate
[14:36:19] Chunk generator performance: 9.77 ch/s (21 ch total)
[14:36:21] 0 chunks to load, 360 chunks to generate
[14:36:22] Chunk generator performance: 10.55 ch/s (44 ch total)
[14:36:23] 0 chunks to load, 338 chunks to generate
[14:36:24] Chunk generator performance: 10.81 ch/s (67 ch total)
[14:36:25] 0 chunks to load, 317 chunks to generate
[14:36:26] Chunk generator performance: 10.80 ch/s (89 ch total)
[14:36:27] 0 chunks to load, 296 chunks to generate
[14:36:28] Chunk generator performance: 10.83 ch/s (111 ch total)
[14:36:29] 0 chunks to load, 273 chunks to generate
[14:36:30] Chunk generator performance: 10.85 ch/s (134 ch total)
[14:36:31] 0 chunks to load, 251 chunks to generate
[14:36:32] Chunk generator performance: 10.85 ch/s (156 ch total)
[14:36:33] 0 chunks to load, 229 chunks to generate
[14:36:34] Chunk generator performance: 10.86 ch/s (178 ch total)
[14:36:35] 0 chunks to load, 208 chunks to generate
[14:36:36] Chunk generator performance: 10.85 ch/s (200 ch total)
[14:36:37] 0 chunks to load, 186 chunks to generate
[14:36:38] Chunk generator performance: 10.89 ch/s (223 ch total)
[14:36:39] 0 chunks to load, 161 chunks to generate
[14:36:40] Chunk generator performance: 11.03 ch/s (248 ch total)
[14:36:41] 0 chunks to load, 138 chunks to generate
[14:36:42] Chunk generator performance: 11.06 ch/s (271 ch total)
[14:36:44] 0 chunks to load, 114 chunks to generate
[14:36:44] Chunk generator performance: 11.13 ch/s (295 ch total)
[14:36:46] 0 chunks to load, 90 chunks to generate
[14:36:47] Chunk generator performance: 11.21 ch/s (321 ch total)
[14:36:48] 0 chunks to load, 65 chunks to generate
[14:36:49] Chunk generator performance: 11.30 ch/s (347 ch total)
[14:36:50] 0 chunks to load, 41 chunks to generate
[14:36:51] Chunk generator performance: 11.30 ch/s (370 ch total)
[14:36:52] 0 chunks to load, 19 chunks to generate
[14:36:53] Chunk generator performance: 11.29 ch/s (393 ch total)
[14:36:54] Lighting spawn area in world "world"...
[14:36:54] 399 chunks remaining to light
[14:36:55] Chunk generator performance: 11.05 ch/s (407 ch total)
[14:36:56] 387 chunks remaining to light
[14:36:57] Chunk generator performance: 10.82 ch/s (421 ch total)
[14:36:58] 375 chunks remaining to light
[14:36:59] Chunk generator performance: 10.59 ch/s (434 ch total)
[14:37:00] 365 chunks remaining to light
[14:37:02] Chunk generator performance: 10.41 ch/s (448 ch total)
[14:37:02] 354 chunks remaining to light
[14:37:04] Chunk generator performance: 10.24 ch/s (463 ch total)
[14:37:04] 342 chunks remaining to light
[14:37:06] 330 chunks remaining to light
[14:37:06] Chunk generator performance: 10.05 ch/s (478 ch total)
[14:37:08] 312 chunks remaining to light
[14:37:10] 286 chunks remaining to light
[14:37:12] 260 chunks remaining to light
[14:37:14] 235 chunks remaining to light
[14:37:16] 210 chunks remaining to light
[14:37:18] 183 chunks remaining to light
[14:37:20] 155 chunks remaining to light
[14:37:22] 127 chunks remaining to light
[14:37:24] 100 chunks remaining to light
[14:37:26] 74 chunks remaining to light
[14:37:28] 50 chunks remaining to light
[14:37:30] 27 chunks remaining to light
[14:37:32] Starting server...
[14:37:32] ServerListenThread
[14:37:32] Starting InputThread...
[14:37:32] ServerTickThread
[14:37:32] Initialization done, server running now.

[xoft]

I still can't get MC-Server to run successfully in Release mode. It keeps crashing as soon as the generator kicks in (the first "N chunks to load, M chunks to generate" line), with a message that an exception was thrown in vector::reserve. I tried compiling with the makefile modification you provided and no luck yet. Is there any other modification you've made? Some linker options, perhaps?

With 10 chunks per second generator performance, I'd say your RasPi can support 2, maybe 3 players, if they don't move around too much. The bottleneck now probably is the zlib compression that's needed for the chunks to be sent over the network; we can't do much about it.

[FakeTruth]

The bottleneck now probably is the zlib compression that's needed for the chunks to be sent over the network; we can't do much about it.

Keep a compressed version of each chunk in memory?

[kfricke]

I still can't get MC-Server to run successfully in Release mode. It keeps crashing as soon as the generator kicks in (the first "N chunks to load, M chunks to generate" line), with a message that an exception was thrown in vector::reserve. I tried compiling with the makefile modification you provided and no luck yet. Is there any other modification you've made? Some linker options, perhaps?

Nope, sorry!

With 10 chunks per second generator performance, I'd say your RasPi can support 2, maybe 3 players, if they don't move around too much. The bottleneck now probably is the zlib compression that's needed for the chunks to be sent over the network; we can't do much about it.

Ok, i will keep you updated on my tests.

[xoft]

Keep a compressed version of each chunk in memory?

Nay. Blockticking would invalidate most chunks pretty soon. And RAM is a very limited resource on the RasPi.

[FakeTruth]

Oh, right.. blockticking.
Forgot about that

[xoft]

This is totally weird. I pinpointed the culprit to be the cStructGenRavines::cRavine::RefineDefPoints() function. It assumes that the vector size is at least 2, which is a valid assumption, because it is called after the ravine defpoints are initialized by at least 4 points. But at the first entry to that function for chunk [18, 12] the a_Src vector reports having 2.5 billion items (2^31 - 1). I have no idea how that happens.

kfricke, can you please try deleting the contents of your "world/region" folder, then changing the [seed].seed value in "world/world.ini" file to "2" and finally running the server? Will it crash?

[xoft]

kfricke, another thought, did you enable ravines? If you didn't that might be the cause why it's not crashing on your Pi. It crashes only in the ravine generator.

And it's driving me crazy - when I compile with -O1, it crashes. If I replace -O1 with all the optimization flags that it should be equivalent to, it doesn't crash. But still it's slow.

[xoft]

I figured out what the problem was. Well, that is unbelievable!
Both Caves.cpp and Ravines.cpp define a structure that is used for temporary point storage, cDefPoint. That structure was used only inside each module respectively. But for some reason, gcc joined the handling of those two structures together when optimizing, although one structure is 20 bytes and the other is only 16 bytes. And that's why getting the vector's size failed - it was dividing by the incorrect amount of bytes. Unfortunately that coupled with another gcc optimization that replaces division with multiplication and some binary magic, so the final numbers were so off that one couldn't recognize the problem.
Fixed in rev 714 (we have "Raspberry Pi" in the commit messages, yay!