|
|
Murphy | Fri 13-Jan-17 11:06 PM |
Member since 30th Dec 2010
1639 posts
|    |
|
#66346, "The game lags."
Edited on Fri 13-Jan-17 11:11 PM
|
I walk down a road and the game output freezes up, unfreezing a second later and "catching up" with my input (assuming I keep pressing the direction hotkey).
It looks like my input goes through on time, I just get the response text a bit late occasionally (1-1.5 seconds).
It's subtle and not big enough to notice if you're walking in mountains, but noticeable on a road, or in spammy battles such as vs a necro with full army. Seems to key off the amount of text the mud returns.
It's been like that consistently for weeks now. I thought the problem was with my internet provider, but...
--- 162.249.126.23 ping statistics ---
209 packets transmitted, 209 received, 0% packet loss, time 208210ms
rtt min/avg/max/mdev = 199.908/200.343/209.495/1.095 ms
I tried it with 1024 byte packets too. No loss.
It really drives me nuts. What do I do?
UPD: I did a traceroute to CF address and port, then ping to every intermediate host. None showed any faults in response time.
|
|
|
|
|
|
-flso | Sat 14-Jan-17 12:04 AM |
Member since 02nd Oct 2007
296 posts
|  |
|
#66348, "Here is what you can do"
In response to Reply #0
Edited on Sat 14-Jan-17 12:08 AM
|
open a terminal and have ping to the CF IP running constantly.
Script your mud client so that it captures the time difference for every
send/receive it does, where send is you sending a command to the mud
and receive is the mud client receiving CF server output for that command.
Collect all those time deltas, deduct the AVG ping roundtrip time from each
one of them and you will end up with a series of time measurements that
correspond (roughly) to CF server "processing" time.
If you see wild fluctuations there, it means the CF end is ####ting itself. Could
be the CF process itself, or other processes running on the same box (esp if
it's shared).
I've done that in the past and saw lag that correlated with "load", where load
== number of players on.
|
|
|
|
| |
|
Murphy | Sat 14-Jan-17 12:32 AM |
Member since 30th Dec 2010
1639 posts
| |
|
#66349, "It's on the CF side"
In response to Reply #1
|
Lag spikes happen on ticks, although not only on ticks.
It's obvious that sometimes the delta time between command and response is 1-2 seconds, but the ping NEVER goes above 210 ms. I left it running in background numerous times.
|
|
|
|
| |
|
Humbert | Sat 14-Jan-17 07:47 AM |
Member since 13th Jun 2009
182 posts
| |
|
#66353, "I have a theory it is area respawns"
In response to Reply #2
|
Such a long lag almost certainly isn't due to CPU.
I assume that the ROM codebase doesn't have any such obvious errors in programming, so it must be a CF-specific feature. Limited items jumps out at me as a CF-specific feature.
If you respawn X areas, each with Y limited items, and suppose you (badly) do it as X * Y separate queries, that could lead to the big delay...
Or what if the database were accessed over a network connection with its own latency?
Hopefully CF gets a programmer who can look at that soon.
|
|
|
|
| |
|
-flso | Sat 14-Jan-17 12:02 PM |
Member since 02nd Oct 2007
296 posts
| |
|
#66355, "It's not a new issue"
In response to Reply #3
Edited on Sat 14-Jan-17 12:03 PM
|
it's been there for 5+ years. I've certainly posted about it before.
IIRC when the server move happened, it became perceivably worse.
|
|
|
|
|
Printer-friendly copy 
Email this topic to a friend 
