Unseen Studios

Does anyone know anything about EJ's server hardware, or is knowledgeable enough to speculate? I can't imagine EJ using racks full of powerful new servers for Xenimus. If the servers are relatively low-end, then the bulk of the cost for such a game would be the bandwidth. I'm just curious as to the server hardware requirements.

they are low-tech, definitely not some rack server
i can dig up something about them if you want me to, I think i've got the specs somewhere
basically just a desktop computer with his server program running on it

If the servers can in fact be inexpensive computers, we could do away with a lot of the current arguments (magic bags for example), and run two servers: one classic server with hardcore rules, and another experimental server to test out these magic bag solutions.

or just test them out in the alpha

i think we should run with out bags to test how it works see if many people like it or if it turns out to be a problem.

ziggman wrote:i think we should run with out bags to test how it works see if many people like it or if it turns out to be a problem.

Thank you!

We have already settled this people! No bags! Drop 1 item when you die.

So here is what is happening. Prime is not changing, it has always had a good connection and been a good machine. The other servers will all be P4 1600s with 512 meg ram. The lines they are connected to are some of the fastest possible for me to get. The cost is more but I think it will be worth it.

http://www.xentales.com/wiki/index.php/ ... 12-29-2002

But i could have sworn that he asked the xen community at one point about updating the servers and what type of the 2 processors he should change to. I think it was a really basic question like, AMD or Intel. But this may have been when he hosted them still... or something.


Edit: In 2002 this was good equipment though. But im sure he hasnt changed it yet unless thats what all the isp changes are too.... im not sure of anything about it now.

The xenimus servers have never needed that much CPU power. Its always a bandwidth limitation.
At some point when the game is more complete it could be possible for us to release the server program to allow custom servers. But that wont be anytime soon. We still need models for players!

Clown Mage of X1 wrote:

So here is what is happening. Prime is not changing, it has always had a good connection and been a good machine. The other servers will all be P4 1600s with 512 meg ram. The lines they are connected to are some of the fastest possible for me to get. The cost is more but I think it will be worth it.

http://www.xentales.com/wiki/index.php/ ... 12-29-2002

But i could have sworn that he asked the xen community at one point about updating the servers and what type of the 2 processors he should change to. I think it was a really basic question like, AMD or Intel. But this may have been when he hosted them still... or something.


Edit: In 2002 this was good equipment though. But im sure he hasnt changed it yet unless thats what all the isp changes are too.... im not sure of anything about it now.

That is the exact post that came to mind when I read this topic.

Vitriol wrote:

ziggman wrote:i think we should run with out bags to test how it works see if many people like it or if it turns out to be a problem.

Thank you!

We have already settled this people! No bags! Drop 1 item when you die.

No we havent...

I think this question needs refinement.

How powerful would a server need to be to ensure that raw CPU power does not become a bottleneck? If Karl's server code can make use of SMP/NUMA systems with a non-negative scaling, then I would imagine that basically any dual-core processor should be more than sufficient. But really that is hardly the issue. If that is the question, the required processing power depends on the number of connected users and the efficiency of the code.


But what does it matter if the server is powerful enough for 500 users if it cannot maintain a connection to 100 users? The latency of communications, i.e. the Internet, is far more likely to be felt than latency of cache miss or page fault. Even with infinite bandwidth, the latency is likely to remain the same. However, with some simple calculations, I have to agree with Vitriol -- bandwidth will be a limitation.

I'm still a bit skeptical as to how this community is going to solve the bandwidth problems once a workable version of the server and client is produced. Has anyone thought about this yet? It's a real pitfall of a design issue that I haven't really seen addressed, and I know I have asked about it once. Maybe I just missed the response. Let's go ahead and make some simple estimates. I come from the FPS world, so these look rather conservative.

1) The client updates his/her status, say, 10 times per second. Effectively, 100 milliseconds. Change that to a more conservative 250 millseconds (4 updates/sec) if you would like.
2) The client's updates are close to 100 bytes. At 10 times/sec, that is almost 1KB (1024 bytes), and at 4 times/sec that is less than 1/2 KB.
3) The server updates approximately the same rate as the client, although just from experience, I would imagine that the updates sent are larger than the clients.
4) The server is likely to be run on consumer-level ISPs. I get 60-80KB/sec sustained on 15d/2u FIOS (Theoretically 250KB/sec maximum -- perhaps in burst). Your mileage (hopefully!) will vary. Using a cable modem is likely to have even worse ratings.


There are 336 users on this forum. I'll assume that at any given time, less than 1/3 could be playing. Say, 100 users. In real life, traffic is a function of the time -- few on at early hours in the morning, perhaps 75% on during peak.

Assuming that server packets are slightly larger than client packets, say 128 bytes, that is about 512 bytes/sec for the 4 updates/sec, and just over 1.25KB/sec for 10 updates/sec. This is very little communication. When it comes to downstream, the server is set. But what about upstream, where it sends data to the clients?

Now, let's take that 100 clients. At 512 bytes/sec, you are gold: 50KB/sec sustained should be easily done. You will max out at approximately 160 clients @ 512 bytes/sec = 80KB/sec. This represents less than 1/2 of the number of registered users, and probably wouldn't work well for peak. This also assumes that packets have exactly no overhead and never require a resend -- both aren't safe assumptions. UDP, the most lightweight (and error prone) protocol has around 16 bytes/packet of overhead. That represents about a 12.5% increase in our 128 byte server packet size and 16% on the client packet. Resends half the instantenous bandwidth by requiring the same amount of information to sent using twice the bandwidth. Luckily, resends aren't always required, and aren't too horribly common.

Now, let's take that 100 clients again, but at a more responsive 10 updates/sec resulting in 1.25KB/sec. This gives us 125KB/sec -- too much to support assuming the poor figures cited. Again, no overhead and no resends assumed.


If a test version of PV is released however, I would imagine that it would attract much more than 100 players online. It is likely that the forum will become much more active and so forth.

you said a mouth-full, I understood 17% of that maybe lol, from what I understand bandwith is the problem?

you seem to know what ur talking about. what type of solution would you lean tward? if the bandwidth can only support 100 or so players?

9sam1 wrote:

Vitriol wrote:

ziggman wrote:i think we should run with out bags to test how it works see if many people like it or if it turns out to be a problem.

Thank you!

We have already settled this people! No bags! Drop 1 item when you die.

No we havent...

nothing is 100% set. its possible there may be 2 servers (in time) one with bags (anti pvp) and one with out (full pvp)

I believe that was the reason behind DS.
You all seem to think it was cause ej didnt have room to make a large enough map.
I think it was to distribute players so that he could solve bandwidth limitations.
I mean sure, you could keep everyone on one server all the time, but you might hit a bottleneck.
If you make the good hunting spots on another server, (lets say) half the players would go to that server, while the other half stay in town/chatting/hunting on server. This reduces bandwidth to each server, and problems are solved.

I dont see the bandwidth being THAT much of a problem. Hell, im on a 5Mbit pipe and ROUTINELY download at speeds of 600KB/s or more. Of course, in this case the server is uploading a lot more data than downloading. But some solution will be found. (I cant upload more than 35KB/s without choking my connection)
And these problems wont appear at first. Any client released in the next month or so will certainly not be a general release. itll be a private release to the active members of this forum. We are talking 20 people at MOST. Later in development these concerns can be addressed. Its not like there will be much to do in the initial release anyway...

And look, Im really sick and tired of the magic bag crap. Old xen didnt have magic bags and people loved it. I think the fact that we have conceded not to make the players drop the entire inventory is unacceptable by itself. You newbs are completely ignoring the concept and you are going to ruin it.

Vitriol wrote:And look, Im really sick and tired of the magic bag crap. Old xen didnt have magic bags and people loved it. I think the fact that we have conceded not to make the players drop the entire inventory is unacceptable by itself. You newbs are completely ignoring the concept and you are going to ruin it.

im done discussing this issue as well, i think the majority of people have agreed on dropping 1 item with the 10 level mass pk buffer.

jsunjshiner, bags are highly unlikely to make it in the game, because early xen never had them... use redos if its a concern

even though its not ideal, I can completely accept the 1 item drop, 10 lvl buffer.
Reditus Amulets im sure will become the standard way for higher levels (20 and up) to protect their equipment. (although I think they should be a bit more rare than in current xenimus.)

definitely more rare