Stonehearth game lagging drivers#
Stonehearth game lagging full#

I don't know that that is your full issue as there are also many VM issues that could be op[art of the problem.

If you do not have it in your Network.eco it is still enabled by default and you would need to add it and set it to false. We have resolved this by disabling the setting. In cases where a server is in a data center and there is not a router but as its enabled by default so it tries to do network mapping although there is not really a UPnP device to set it up to do so and there have been some vert odd networking connection issues. Enabling the UpnP device is to see if that helps servers that have been having connection issues by allowing it to do network mapping. If you have run any other game servers through that router since most disable UPnP you probably have it disabled if your router has the option. We have see the use of the UPnP device trying to run and creating a error state when it cant find an enabled UPnP device and its an issue especially if you are not behind a NAT or you do not have the UPnP device in the router or if you do its not enabled. Have you tried disabling 'UPnPEnabled' WM has always been a issue for Eco at least in my experience and peaking CPU is one of the many issues that we have seen over the years and why we don't offer VM servers for Eco.

Investigate process with process explorer to see if it's localised to one biome or many - When occurring over a dozen threads hit high utilisation so I'm assuming it's not localised to one biome ie.

Change WorldTickCPUMax all over the place - 0.50, 0.75, 0.25, 1.0 - No change.

Change WorldObjects.Parallel World Object Ticks from false to true - No change.

Change Network.Rate from 20 to 10 and then 35 - No change.

Change simulation.RecordEveryLayer from Interval to Every Change - No Change.

Adding CPU cores (up to 8 cores 12 threads) - No change.

Reducing save frequency from 60s to 10 minutes - No change.

Move VM from mag drives to storage array (2x NVMes in hardware RAID0 capable of 2.5GB/sec read/write and over 100k IOPS) - No change.

Very light load - Server was originally used by me to crunch numbers for a client of mine but they went out of business but is still under lease (I'm also using it for E-mail, Single-Sign-On and ownCloud for 4 of my employees).

Hosted in a datacenter in Montreal and has a gigabit connection essentially zero observable packetloss (and is about the same when checking domU or dom0).

IOMMU is used (obviously) and Xen is working with EPT.

Stonehearth game lagging drivers#

Paravirtualised Windows drivers (Switching to HVM made no difference).

The server has 8 GB of RAM without a pagefile and has never exceeded 6 GB of usage. The database is also fairly large (approaching a gig at this point).

Speaking of tick times, they're about 90 seconds (also in attached image).

Ticking times don't seem to increase significantly (other than a a slight increase possibly due to resource contention).

VM CPU utilization also increases to a high amount, and appears to 'plateau' at a point, but rarely hits 100%, often settling between 50-85%.

Getting a stack trace for these threads is tricky because process explorer has difficulty keeping up, but judging from the function names it seems to possibly be related to route probing in clr.dll?

As discovered through process explorer, several threads (up to 15 in the worst cases) spike to high utilization.

Players attempting to join the server are either met with a timeout or a load time in excess of several minutes.

As shown in the above screenshot, the 'CPU' for several players spikes to a high amount and stops 'updating' for a period of time (sometimes affects all players, sometimes does not).

When the server has more than a couple of people on it, dozens of times times per hour and for upwards of a minute each time in the worst case, the following symptoms are observed: This does not appear to increase in frequency while the server is going all apey. Maybe relevant Wireshark indicates about 10-15% of DIS packets are malformed (although apparently this is common as I guess Wireshark's DIS interpreter sucks). Observe (ignore the CPU usage graph as when I took the screen shot the VM was doing something else and is thus not representative of the issue):Д¬PU usage of Network threads (ignore task manager CPU graph the server was also doing something else): Posted this on #server-talk in Discord and had no response so I'm assuming it's not.

Not sure if it's a VM artifact or a legit known issue.