Sign up Calendar Latest Topics

  Author   Comment  

Posts: 7
Reply with quote  #1 
I am running the latest version of Artemis on a MacBook Pro Retina 2.7GHz, Core i5 with 8GB memory.  I am hosting the server and running a client during our play sessions.  I have 3-4 other clients connecting into my server using port forwarding on my home router.

So far, everything has been fine up until we increase the difficulty to level 6+ and start adding terrain, friendly ships, etc.  Once we go to this level of complexity, the server has started to lock up.  I am running this thru PlayOnMac (Wine) as well.  Lastly, we have had to lower the Network Update Speed setting to 50ms to make it run smoothly.  Is this common?

I assumed that if the app could be run as a server on an iPad, that my MacBook would have much issue.  

Any ideas?  

Avatar / Picture

Posts: 359
Reply with quote  #2 
actually 50ms (1/20th second) is faster then the default 250ms (1/4 second). Also the more active clients (so even if someone runs ENG and has a second window open for Main Screen) that count as 2 clients open. My server (internet speed combined with computer processor) could support almost 15 clients before bogging down (around level 5-6). As you increase level, your increasing the tax on the processor, so if we wanted to play level 7-8 I could host easily 1 full ship (online with everyone running a main screen too) or 2 full bridges (with only some clients having a main screen). You would need one Bad-Ass machine to run 8 bridges at level 8+ as there is just a horde of information coming at your server.

So check your internet speed, go back to default 250ms, and if people are logging in 2 (or more) clients per computer (SCI also is COMMS and wants Main Screen too all in separate windows= 3 clients) that may be bogging your system.

You can also make things more difficult, instead of increasing number of enemies (going up in level), just make them more difficult. increasing the enemy speed, shields, and weapons.....

PirateLord Eric Wethington:
Commander of the 1st CAP Light Recon Fleet stationed at ShoShuShen station, Eastern Front Sector
Captain of the Privateer Longbow "Jimi-Saru"
Captain of the Privateer Brigantine "Fulminate" and 59th Pirate Fighter wing "The Reapers"

Charter Member of the Eastern Front online group (PirateLord)


Posts: 7
Reply with quote  #3 
I have 125mb/s internet at my house.  I had to speed up the network response to 50ms to avoid lag on the clients on my team.  Do you think that each client's internet speed is a factor here?  

What kind of PC server are others using?  We may be looking into a Amazon Web Service to host a VM server and I'm curious what specs others are using at the higher difficulty levels.


Posts: 625
Reply with quote  #4 
Each client's network speed--actually, latency--could certainly contribute to the issue.

The network update speed, as I understand it, determines the delay between the server communicating with each client. The longer the delay, the less often the server sends data to each client. As the network update speed decreases, the CPU load on the server goes up because it has to generate updates more often.

Where I bet you could see trouble is if you set the network update speed to 50ms and one (or more) clients ping time is over 50ms. I'm not sure the Artemis networking method permits packets to just be dropped or delayed, mainly because it's using TCP connections. TCP strives for consistency, and packets are queued up in the operating system network stack to ensure they are delivered to the application in order. One slow client could start a cascade of lag and delay which causes the server to behave very badly.

In other words, the network update speed should not be less than the average ping of your most distant client. You can have the clients ping the server to check the ms delay time. A higher number in network update setting will cause lag and "sliding" of animations, but will probably stabilize the connection.

I suspect any lag you are seeing or spikes in CPU is actually "busy waiting" where one or more clients isn't acknowledging packets quickly enough, and the server is waiting to hear back from the network that the packet was received OK. The uber-geek way to find out is run WireShark on your server watching TCP port 2010 traffic and analyze the traffic before and after a game crash. You should be able to extrapolate latency and such.

Another diagnostic: have your PC-based clients run this in a command window:

ping -t

Where should be replaced by the IP address of the server. The pings should get through, and should not dramatically change in delay. Any dropped pings or timeouts are symptomatic of the client having trouble getting to the server in a timely manner. Press Ctrl-Break to see a summary of the stats thus far. Leave that running during a game test or two and see if there are any dropped packets. Could be enlightening!

Visit us at
Previous Topic | Next Topic

Quick Navigation:

Easily create a Forum Website with Website Toolbox.