About heavy armor, and roundtime

[artus]

Hello everyone!
I know the abilities topics are more than just to be called the hot threat over the forum. Now, Artus has come up with something else, less interesting but worth a thought.

I really have to thank Vaylon, Coanid and some players over chat yesterday (yesterday my time, probably the server time too), for bringing up this idea. What I'm going to mention is :

First : I wonder why Clok very easily hinder my stealth whenever my weight goes higher. When you sneak or hide, you don't really do anything noisy that much except in some places that weight has something to do. Instead, when you weigh a lot and have to fight something or someone, dodging is the first and the most to be reduced due to whatever stuff you carry. I love the idea of dodging affecting tumble ability, but what about the weight? It should be dodging, not stealth.

Second : I just got an opinion about the too laggy roundtime from someone on audiogames.net forum, on clokmud topic. I didn't even know roundtime could drive player off like that, until that opinion came to mind. It actually makes sense to make things feel kinda realistic with roundtime and stuff. What is the problem, is the lag between command and command, which seems to be a little too long.

Thank you for every consideration and opinion that may come after this topic.

[Jirato]

First : I wonder why Clok very easily hinder my stealth whenever my weight goes higher. When you sneak or hide, you don't really do anything noisy that much except in some places that weight has something to do. Instead, when you weigh a lot and have to fight something or someone, dodging is the first and the most to be reduced due to whatever stuff you carry. I love the idea of dodging affecting tumble ability, but what about the weight? It should be dodging, not stealth.

Armor stealth penalty is more about bulk (sight) and material (noise) than it is weight.

Second : I just got an opinion about the too laggy roundtime from someone on audiogames.net forum, on clokmud topic. I didn't even know roundtime could drive player off like that, until that opinion came to mind. It actually makes sense to make things feel kinda realistic with roundtime and stuff. What is the problem, is the lag between command and command, which seems to be a little too long.

Can you elaborate on this a bit? Is the complaint with roundtime, or with the lag time it takes from the time you enter a command to the time the server registers it and responds? I've got a solution in mind for the latter but it requires a significant rewrite of a core server component as well as all rewriting all 610 verbs. As for roundtime specifically, I have no idea what could be done to change that. It's a pretty vital game mechanic.

[Kothar]

My personal concern since playing is mostly the latter, I type a command before the round, but it doesn't actually act like I did anything until AFTER the round, so if I get attacked while foraging and holding a satchel, rather than waiting for roundtime to end, and wearing the satchel, grabbin my sword and starting a combat round, I often have two rounds of getting my face kicked before my satchel even gets worn, or sometimes I'll get my face kicekd, wear the satchel, get my face kicked again, and then I'll start battling at the start of the NEXT round, when I really only was supposed to wait for my roundtime from the forage to end as wearing a satchel and grabbin a sword dowsn't incur a roundtime. Granted, small example that isn't a game ender for me, but I see that sort of delay in many things I do.

[Jirato]

To be clear, are we talking about queued commands here, or all commands in general? You should not be experiencing that sort of delay unless you are queuing your commands.

[Kothar]

For me, it happens with non-queued commands and it's not generally consistent enough to know yet if it's something specifically with the game, which is why I haven't bugged it or brought it up. For me it's just a periodic annoyance that hasn't had any life-altering affects on my character. Queuing I understand and I am a master at repeatedly queuing commands over the top of each other and only performing the last action queued and having to redo things because I am too hasty, and I have no issues with that, it's the non-queued delays that confuse me, but like i said, I'm not yet sure it's the game yet, need to do more testing, but if you have ideas to make command submission to server processing faster, I'm all for that.

[Jirato]

Most of the delay that you're talking about seems network related, if several actions are taking place before your command gets processed.

What I'm thinking about changing is the way commands are currently read from a script file into pre-loading them into memory and calling them as functions instead, eliminating some file access times. There's no way that would account for more than maybe half a second though.

What's your ping times with clok.contrarium.net? Is it over 60ms?

[Kothar]

As I said I need to do some more testing, but here's my general response:
Pinging clok.net [72.52.4.91] with 32 bytes of data:
Reply from 72.52.4.91: bytes=32 time=39ms TTL=247
Reply from 72.52.4.91: bytes=32 time=42ms TTL=247
Reply from 72.52.4.91: bytes=32 time=42ms TTL=247
Reply from 72.52.4.91: bytes=32 time=47ms TTL=247

[Jirato]

I'm not sure what clok.net is, but it isn't us!

[Kothar]

Right....oops. hehe. I need more coffee. What region/timezone is CLOk in anyway? I never bothered to look.

C:\Users\jmorris>ping clok.contrarium.net

Pinging clylla.contrarium.net [67.23.247.154] with 32 bytes of data:
Reply from 67.23.247.154: bytes=32 time=89ms TTL=54
Reply from 67.23.247.154: bytes=32 time=96ms TTL=54
Reply from 67.23.247.154: bytes=32 time=84ms TTL=54
Reply from 67.23.247.154: bytes=32 time=90ms TTL=54

[Jirato]

The server is housed in an Orlando, Florida datacenter, though in-game server time is set 2 hours earlier to reflect the original location of the server (Utah, I think?) before it was moved about a year and a half ago.

[Kothar]

Ah ok, good to know. I'll keep an eye on network stuff and let you folks know if I think there's something to look into, wasn't tryin to hijack the thread here so if ya want, feel free to kill my posts here back to the original content. Thanks for everything as always :)

[sona]

Pinging clylla.contrarium.net [67.23.247.154] with 32 bytes of data:
Reply from 67.23.247.154: bytes=32 time=97ms TTL=50
Reply from 67.23.247.154: bytes=32 time=97ms TTL=50
Reply from 67.23.247.154: bytes=32 time=88ms TTL=50
Reply from 67.23.247.154: bytes=32 time=90ms TTL=50

Ping statistics for 67.23.247.154:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 88ms, Maximum = 97ms, Average = 93ms

there's my ping data. Probably some consistency with us being about 90-100 ms ping range.

[artus]

In my opinion, as far as I understand, I think it's the delayed between command to command, which I'd prefer to call lag. I'm not quite comfortable myself getting punched 5 times due to too laggy roundtime, and then unable to draw anything after that, then lag waiting for new roundtime to come again. Worse than that, sometimes that laggy thing makes me miss something important about ic rp, and can't interact in time.

Hmm, how can I ping the surver anyway?

[Xyra]

I've noticed fairly regularly that I have about 2-3 second lag from my command being entered to it being executed. It isn't all the time, but it does come up with a regularity that I've not had on any other MU* that I can remember playing. The biggest place I notice this is while traveling in the wild. For example, I'm following a road, and I forget that there is a bend in it, so I go 'e' 'e'. I get to the first room right away and have a 4 second travel delay. I realize my mistake right away and try changing directions. Sometimes that change goes through before the move, sometimes it doesn't register until afterwards because of the lag. And yes, I know my reaction time is a factor there, but I have had instances where I know with mechanical precision that it took at least 2 seconds for a command to go through.

While I've occasionally noticed a little lag elsewhere, the wilderness seems particularly prone to it for some reason, or possibly I just pay more attention to it there, since I see roundtimes and similar things more regularly.

P.S.
Pinging clylla.contrarium.net [67.23.247.154] with 32 bytes of data:
Reply from 67.23.247.154: bytes=32 time=51ms TTL=52
Reply from 67.23.247.154: bytes=32 time=52ms TTL=52
Reply from 67.23.247.154: bytes=32 time=51ms TTL=52
Reply from 67.23.247.154: bytes=32 time=53ms TTL=52

[Barius]

The lag topic again, huh?

I can tell by people's posts that it's a confusing issue. And it really is. I've talked about it before, and it is unrelated to roundtime. It's unrelated to network latency. It's a delay in the processing of the game commands, in some form or another. It sounds like Jirato knows what's going on, and it also sounds like a big job to tackle, especially considering so much development has gone on with this issue buried in the code. It's never been anything game breaking, because once you get used to it you can work around it. Some games have a delay like that built in. As best as I can recall, CLOK was not like this when I first started playing, so it is something that happened over the course of its development.

I've also known people who were turned off from the game because of the delay. When I first started playing again and noticed it, it was very significant to me and I can very much understand how it can put others off. If I wasn't already attached to the game, it probably would have put me off too. Because sometimes it is two or three seconds before a command gets processed. Try speed-walking through a town or other non-wilderness area. You might notice the first movement is delayed, but the rest are instant. And it's never been related to my ping, which has always been under 100 ms on my end, unless there was something off with my connection.

Anyway, that's my two, or ten, cents. And here's my ping data, just for information's sake:

Code: Select all

Pinging clylla.contrarium.net [67.23.247.154] with 32 bytes of data:

Reply from 67.23.247.154: bytes=32 time=74ms TTL=53
Reply from 67.23.247.154: bytes=32 time=69ms TTL=53
Reply from 67.23.247.154: bytes=32 time=79ms TTL=53
Reply from 67.23.247.154: bytes=32 time=70ms TTL=53

Ping statistics for 67.23.247.154:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 69ms, Maximum = 79ms, Average = 73ms

[Xyra]

So, the GMs did a bit of testing on it this morning, and I did some tests while they were doing theirs, and I'm about 95% positive that the problem is with the queue (Not the queue that sets up actions while in roundtime), and I'm fairly sure the GMs know this too.

Basically what is happening is that commands are getting to the server just fine, and the individual commands are being executed just fine, but there are simply so many commands coming in that the server is getting overloaded. You have to remember that the server isn't just processing your commands, or even just all the player's commands. It is also having to run checks on rooms to see if they need to spawn anything, critters if they need to walk around or attack someone, crops if they need to grow or get weeds, roundtimes need to tick down, energy needs to be recovered, and dozens of other things. While none of these actions individually takes much time, all of them together can add up to quite a bit.

This is why sometimes the lag is fairly minor, and sometimes it spikes. The spikes occur when all the critters check at once if they're supposed to move, or other similar waves of checks come in at the same time.

It's quite a painful problem to fix, and the GMs are already working on it. It mostly comes down to code optimization, trying to make every command execute as quickly as possible so when it is executed a thousand times in a second, it doesn't create a sudden hangup.

[Barius]

So, the GMs did a bit of testing on it this morning, and I did some tests while they were doing theirs, and I'm about 95% positive that the problem is with the queue (Not the queue that sets up actions while in roundtime), and I'm fairly sure the GMs know this too.

Basically what is happening is that commands are getting to the server just fine, and the individual commands are being executed just fine, but there are simply so many commands coming in that the server is getting overloaded. You have to remember that the server isn't just processing your commands, or even just all the player's commands. It is also having to run checks on rooms to see if they need to spawn anything, critters if they need to walk around or attack someone, crops if they need to grow or get weeds, roundtimes need to tick down, energy needs to be recovered, and dozens of other things. While none of these actions individually takes much time, all of them together can add up to quite a bit.

This is why sometimes the lag is fairly minor, and sometimes it spikes. The spikes occur when all the critters check at once if they're supposed to move, or other similar waves of checks come in at the same time.

It's quite a painful problem to fix, and the GMs are already working on it. It mostly comes down to code optimization, trying to make every command execute as quickly as possible so when it is executed a thousand times in a second, it doesn't create a sudden hangup.

Yep. It's especially noticeable when there are very few people online, and so a very significant decrease of load to the server processing commands and such.

[Edoras]

This might be an unnecessary thread necro, but I wanted to ask a question as a player who made a character a while ago but then put it on the back burner. The delay between commands reaching the server and actually being executed is really noticeable to me, and is probably one of the primary reasons why I was turned off of the game when I tried it a while ago: I'm really intrigued otherwise by the sheer depth of the game itself.

Out of curiosity, has there been any meaningful progress made with regard to the significant rewrite Jirato was mentioning, or has it been deemed as one of those options that would require way too much trouble for the reward? From my brief sessions today, it seems like there's still a 1-2 second delay between a command reaching the server and when it gets processed, which does actually seem a bit better than what I recall it being, although it's still really jarring when I send 4-5 commands at a time only to have a 2 second delay of nothing followed by a couple of screens worth of output as a result of them all executing at the same time.

For the players, are there any tips that you might have to help adjusting to the delay that you've grown accustomed to?

[Jirato]

It's not 100%, but we've migrated pretty much the most frequently used verbs over. Everything to do with movement, combat, speech, chat, and just looking around.

If you're experiencing just general network lag, feel free to try to connect to one of our alternate IPs.

• 67.23.247.154
• 67.23.247.155
• 67.23.247.156
• 67.23.247.157

Random fact: CLOK presently has 7373 rooms, and at the time of this post 2018 critters.

[Edoras]

It's definitely not network lag unfortunately, if you want to see my ping results are below:

Pinging clylla.contrarium.net [67.23.247.154] with 32 bytes of data:
Reply from 67.23.247.154: bytes=32 time=25ms TTL=55
Reply from 67.23.247.154: bytes=32 time=25ms TTL=55
Reply from 67.23.247.154: bytes=32 time=25ms TTL=55
Reply from 67.23.247.154: bytes=32 time=25ms TTL=55

It just still seems that on average, it takes a couple of seconds for a command to get processed after I send it, including movement and looking about. Unfortunately I can't really show you a log to describe the behavior, since it's timing based, except for the following where I can attempt to describe it. I sent multiple "time" requests to the game, waiting until I saw the results of the previous time before I sent the next. Now, obviously there's going to be some manner of delay involving my own reaction time, but in most circumstances I would be waiting at least a full second before seeing the results: In some cases, the command would return almost instantly, but in most cases it was a second or so.

EAvd>
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:02:09 2016)

EAvd>
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:02:10 2016)

EAvd>
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:02:12 2016)

EAvd>
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:02:14 2016)

EAvd>
worth
You are carrying 187 riln.
Roundtime: 1 second.

EAvd>
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:02:25 2016)

EAvd>
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:02:27 2016)

EAvd>
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:02:28 2016)

EAvd>
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:02:31 2016)

In contrast, if I stacked ten time commands on top of each other, I still wouldn't get any response for about a second, but then I would simultaneously see the result of every single time command returned. Despite being rather lengthy, the following snippet is that output, where I'd wait until I saw the results of one set of commands before sending the next set.

EAvd>
time
time
time
time
time
time
time
time
time
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:46 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:46 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:46 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:46 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:46 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:46 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:46 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:46 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:46 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:46 2016)

EAvd>
time
time
time
time
time
time
time
time
time
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:48 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:48 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:48 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:48 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:48 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:48 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:48 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:48 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:48 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:48 2016)

EAvd>
time
time
time
time
time
time
time
time
time
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:49 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:50 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:50 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:50 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:50 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:50 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:50 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:50 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:50 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:50 2016)

EAvd>
time
time
time
time
time
time
time
time
time
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:51 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:51 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:51 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:51 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:51 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:51 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:51 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:51 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:51 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:51 2016)

EAvd>
time
time
time
time
time
time
time
time
time
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:52 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:52 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:52 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:52 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:52 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:52 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:52 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:52 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:52 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:52 2016)

EAvd>
time
time
time
time
time
time
time
time
time
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:53 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:53 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:53 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:53 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:53 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:53 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:53 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:53 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:53 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:53 2016)

EAvd>
time
time
time
time
time
time
time
time
time
time
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:55 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:55 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:55 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:55 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:55 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:55 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:55 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:55 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:55 2016)

EAvd>
By the Viali Calendar, today is Kingsday, 8th day of Februm of the year 1216.
The time is approximately nine bells.
(OOC: Mon Feb 8 09:03:55 2016)

The point being, whether I'm sending one command or ten, the "delay" on the command(s) getting processed seems to be within the same range. It doesn't seem to be any different whether I'm using "time", "look" or "say" either, although unfortunately those other more important commands don't come with their own timing mechanism to assist in demonstrating the results in a test like this. In retrospect, perhaps a client side trigger that used a client side time in conjunction with a triggered say on seeing the results of my previous say would have been a better example.

I don't presume this is news to you, just providing my own point of view of the issue: It's definitely not latency related, but rather I'd assume it's just that there's an abundance of commands being executed by the server at any point in time, player driven or otherwise, and so every command sent by players have to wait their proper turn. As a side note, the MERC/ROM based mud I am the most familiar with would only process "commands" at a 6 command per second rate: At most, only six meaningful things could happen per second, whether it was a command issued by a player or by some AI on the server: For an example, stacking the "time" command 360 times would take a full minute to execute. In contrast, Clok seems to process as many commands as possible: I tried today to see how many "time" commands I could fit in the same second, and the number of returned outputs per second (server side second based on the time output) would vary anywhere from 40ish to well over a hundred (I'll omit that log because it would be a huge mess, and I only did that a handful of times lest I end up DOS'ing the game). Given that the delay between receiving and processing a command is variable, sometimes almost instant and sometimes close to a couple of seconds, it seems more like an issue of the sheer amount of work to be done rather than anything else: And at least from my brief experience so far, I still definitely feel what seems to the exact same delay even when looking, moving, and talking.

I don't mean to beat a dead horse, but since you stated that you'd migrated some verbs over, I wanted to point out that those commands don't seem to be working any more efficiently than others: Are those changes live or just on a test environment?

[Edoras]

Alright, follow-up post time, hopefully this'll be a bit more useful and less bulky.

First off, I apologize if I caused any problems with the game. I noticed the flooding update change preventing more than 3 commands being sent a time: I definitely didn't intend to exploit anything and I tried to avoid doing anything that seemed like it was adversely affecting the game.

That said, I took some more time to get some hard numbers based on the time between my client sending a command, and my client receiving the response from that command. I wrote some jscript on MUSHClient to calculate the difference in time between exactly when I send a command and when I see the result. I both tested the time command (36 total commands) as well as walking east or west in a city (62 total commands for those) I have the summarized values below for the min/max/average/median values for the time between my client sending a command and receiving the output.

Times are in milliseconds.

Code: Select all

West/East          Time Command
Min          31      Min          95
Max         5079   Max         3075
Average   1305   Average   1276 
Med         1442   Med         1461
Count       62      Count      36

If you want the full logs for the tests or the functions I've used in MUSHclient, let me know, but I'll leave them out for brevity here. The summary is that both the time command and east/west commands seem to behave virtually identically with regard to delay: Both range anywhere from nigh instant execution (<100ms) to sometimes upwards of 2-3 seconds, but on average they take a little over a second to process. Compare that to most other muds, where the response from a command very rarely takes more than a quarter of a second, and it produces a noticeable delay. What's especially interesting is that if you stack commands, as everyone knows, they execute at virtually the exact same time.

I hope this helps, and again I apologize if I caused any problems!

[maxtech]

Latency and Clok is weird stuff. I'd be curious to know what kind of latency you get when you ping clok.contrarium.net (I get 200-210 milliseconds RTT, and about 230ms for commands sent from Mudlet, which seems a perfectly acceptable 30ms process time.) I'm pretty sure Jirato uses a Florida hosting company (HostDime?), which seems to have so-so latency to a notherner like me.

As for running the ten commands in a row and seeing the same delay, it's possible there's some aggregation happening under the hood. Jumbo frames are becoming a really common way for networks to use available bandwidth more efficiently but they can have a negative effect on latency.

[Edoras]

Yeah, I'm east coast, and on the network I'm at currently I'm getting 23ms ping to clok.

ping clok.contrarium.net

Pinging clylla.contrarium.net [67.23.247.154] with 32 bytes of data:
Reply from 67.23.247.154: bytes=32 time=23ms TTL=55
Reply from 67.23.247.154: bytes=32 time=23ms TTL=55
Reply from 67.23.247.154: bytes=32 time=23ms TTL=55
Reply from 67.23.247.154: bytes=32 time=23ms TTL=55


It's my assumption that the majority of the "lag" is on server-side processing, not due to network latency, for many reasons including the fact that every now and then I get a command that executes in less than 100 ms, and if you stack commands they all execute at virtually the exact same time: That's what Jirato seemed to think earlier given that he's working on restructuring the internals on the verbs.

[Lassyn]

I can't speak to the code side of things, as I know literally nothing about it.
That being said, there is so much that Clok can offer, and as someone who's been playing and/or GMing for over a year now, it doesn't get in the way all that much. Frankly I don't even notice it anymore. So, respectfully, I would say that I think it's definitely something worth "putting up with" until it's not as noticeable, in order to enjoy what I believe (and many would agree) is a truly unique game. If it's a deal breaker, I completely understand, and hopefully we can fix it, but from my understanding it would take a long time that could be easily devoted towards the design and presentation of new ingame noticeable components.

[Edoras]

Yeah, it's definitely noticeable and frustrating coming from any other mud, because it really doesn't feel responsive. To be honest, it actually was one of the primary reasons why I didn't stick around, but I'm still very intrigued by the sheer breadth of the game and the active development on it.

That said, I do want to make it clear that I didn't resurrect this thread with the intention of saying "Fix it or I'll never play." Rather, I wanted to see if there was any progress and to offer my own point of view in helping to pinpoint the source of the problem if my point of view could help. From a personal standpoint, I know that there's probably no "simple" fix, but I also honestly get the feeling that the real reason as to why the server lag is present isn't fully known by the devs, indicated by the fact that the verbs Jirato mentioned he'd reworked experience the exact same server delay as all other commands. As a programmer by trade, I like to poke into things like this and see what the reason might be, and if I could offer my limited perspective and save a great deal of frustration and needless work, I'd be happier for it. Having spent countless hours debugging things on programs I've written, I know what help an extra point of view can often provide.

As for priority, I can definitely understand that there's a tradeoff in time spent development for the reward of the work done. As for whether it's worth investigating and/or fixing the server lag, I personally think that minimizing the server lag would make the game -much- more attractive to new players, and current players would really like it. As it stands, it's obvious even from the login screen of Clok that there's a noticeable delay compared to any other mud. As for the real reason as to why: I remember sometime a year or two ago that there was a feature which was broken on the server side, and during that timeframe there was zero server lag and everything behaved very snappily: I heard from other players that it was the "command queue" (Not the round-time queue I think?) that was broken. My memory is definitely fuzzy on that instance, but I do recall that the game felt abundantly more responsive during the time in which that feature being disabled, and then went back to its standard 0.5 to 3 second delay on all actions soon afterwards.

To that end, Barius presented a good point of view about the origin of the server lag, and Xyra's post from this thread seems to likely be a more accurate representation of the most likely source of the server lag.

So, the GMs did a bit of testing on it this morning, and I did some tests while they were doing theirs, and I'm about 95% positive that the problem is with the queue (Not the queue that sets up actions while in roundtime), and I'm fairly sure the GMs know this too.

Basically what is happening is that commands are getting to the server just fine, and the individual commands are being executed just fine, but there are simply so many commands coming in that the server is getting overloaded. You have to remember that the server isn't just processing your commands, or even just all the player's commands. It is also having to run checks on rooms to see if they need to spawn anything, critters if they need to walk around or attack someone, crops if they need to grow or get weeds, roundtimes need to tick down, energy needs to be recovered, and dozens of other things. While none of these actions individually takes much time, all of them together can add up to quite a bit.

This is why sometimes the lag is fairly minor, and sometimes it spikes. The spikes occur when all the critters check at once if they're supposed to move, or other similar waves of checks come in at the same time.

It's quite a painful problem to fix, and the GMs are already working on it. It mostly comes down to code optimization, trying to make every command execute as quickly as possible so when it is executed a thousand times in a second, it doesn't create a sudden hangup