RaspberryPi?

[tbar]

Will MC-server be able to run on the RaspberryPi (www.raspberrypi.org) when it launches? The RPi has 256 MB RAM.

or: how should I configure MC-server to make it run under 256 MB Ram?

[FakeTruth]

MCServer will definitely be able to run on that.

How to limit the RAM usage to make sure it never exceeds 256MB RAM, I don't know...

[Lapayo]

Did already someone compiled MCServer under ARM?

[mtilden]

This isn't announced but ARM is going to provide JITs for all major languages to run existing apps on ARM chips to get people right into using it, although things have to be changed to work natively on ARM as the architecture is a lot different than x86, is a lot better, and focuses on using all available resources natively.

[tbar]

How to limit the RAM usage to make sure it never exceeds 256MB RAM, I don't know...

I'm not looking for a specifik way to limit RAM usage but more guidelines as to how the server is to be run. Eg. How many concurrent users should be allowed? How should I dimension the world?

[FakeTruth]

You can actually calculate that. The world data takes most of the RAM, so that's what you should use to calculate the max users.

Suppose the amount of chunks each user can see is an area of 16x16 chunks. Each chunk has 128x16x16 blocks, and each block is 2.5 bytes
16x16 x 128x16x16 x 2.5 = 20971520 bytes = 20MB

Just to make sure I'd add another 10MB to that per user so the server would take 30MB per user in a worst case scenario I think.

So with a max view range of 16x16 chunks, you should be able to host AT LEAST 8 players

[tbar]

Someone at the raspberrypi-forum has tried compiling mc-server for arm but seems to run into some minor issues: http://www.raspberrypi.org/forum/project...inecraft-2

He hasn't stated what the issues are just that they seem easy to fix...

[xoft]

Let me go over the calculations again. MC changed build height and until we get dynamic chunk height, that means double the chunk data size:
ChunkBytes = 16 * 16 * 256 * 2.5 = 160 KiB

By default, a player has ViewDistance of 9 (configurable in INI), which means they see (9 + 1 + 9) x (9 + 1 + 9) = 19 x 19 = 361 chunks.

This means that we have about 56.5 MiB per player. To be able to compress chunks and stuff like that, the server needs about 10 MB runtime RAM, independent on the number of players.

Also, from what I've heard, RasPi's RAM will be shared with the GFX chip, at least 32 MiB must be allocated to the gfx. That means 224 MiB RAM at most for the system. Let's assume generously that the OS will consume only 8 MiB itself. That leaves us with 216 MiB RAM for MC-Server, or three players.

Now, there's one more thing to consider. MCS currently unloads chunks very lazily, so it's perfectly normal for a single-player server to have more than 1000 chunks in memory. This further breaks our assumptions and brings RasPi next to unusable for MCS.
Sure, we can modify MCS to unload chunks immediately, but no-one has bothered so far

There's hope though. Since most chunks will be about 3/4 empty, RAM could be saved by simply not having those 3/4 air blocks in the memory. FakeTruth seemed to enjoy the idea of implementing this particular feature.

[tbar]

Let me go over the calculations again. MC changed build height and until we get dynamic chunk height, that means double the chunk data size:
ChunkBytes = 16 * 16 * 256 * 2.5 = 160 KiB

Thanks for your calculations! Could you explain what defines Chunk data in the equation above? 160 KB seems like a lot but I don't know what it covers...

[xoft]

Each chunk needs:
- 1 byte per each block to define the block type (dirt / grass / stone etc.)
- 0.5 byte per each block to define metadata (wool color, torch direction, planted sapling type)
- 0.5 byte per each block for skylight (how brightly lit the block is by the daylight)
- 0.5 byte per each block for blocklight (how brightly lit the block is by torches, lava etc. - at night)
This means 2.5 bytes per block. A chunk has 16 * 16 * 256 blocks. Hence the total size.