I spoke with a couple people and it seems its not just me, but there is heavy amounts of lag hitting lately, usually on the ticks. Is it because you guys are coding and testing away on some secret project, or is it hosting issues again? It's been pretty bad lately, even for me, and Im packing a 36.50 mbps internet speed.

Couple thoughts:

1. Zulg added code a while back to monitor when certain functions run longer than expected.

2. AFAIK the way this code is written it won't catch situations where functions run long because of system load external to the process in which CF is running.

3. CF runs on a shared system. It's very likely the lag is due to some other user on the system. Short of moving to dedicated hardware (or get some sort of resource guarantee on the shared system) there's probably not much that can be done. It might be helpful to add an additional batch of monitoring code that looks at wall-clock time instead of process time.

4. The bandwidth of your internet connection is pretty meaningless with respect to perceived "lag" on CF. What you care about is latency, i.e. "ping time".

I am periodically lagged while editing files on the server, so it is not specifically a CF issue.

It's not the CF server's network connection either. I can have ping running non-stop and it never stutters even when the game seems to be lagging. So it's just that the box is cpu or i/o starved.

If a process is hogging the resources, there isn't a form of ps that would help identify that is there? Tracking CPU usage may or may not be useful.

Depends. If the greedy process is running in the same VM as CF then it should be possible to identify. If not then it's pretty much impossible from CF's point of view. Someone with access to the host OS could, of course, figure it out, but that would have to be someone from the hosting company.

That said, someone could extend the monitoring code currently in place to check "wall clock" time in addition to process CPU time. The latter is good for identifying poorly performing sections of code. The former is good for catching two other issues:

1. delays due to I/O contention, and
2. delays due to CPU contention.

Problem is, even if such monitoring existed it wouldn't tell us which of the above scenarios is happening. And in the case of #2 there's probably nothing we can do about it besides getting dedicated hardware (or possibly complaining to the hosting company about intermittent CPU shortages).

Using top, it looks like CF takes ~5-9% CPU usage; 2.6% memory usage. When the lag spikes hit in CF, top continues to function (I assume that is a priority issue), but I haven't seen a pattern in what hits the top of the chart at those times.

That suggests it's either 1) something outside CF's virtual machine that's sucking up all the available CPU resources or 2) CF stuck waiting on some I/O resource.

Seriously.