View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000009 | LDMud 3.2-dev | Other | public | 2003-08-11 19:14 | 2004-05-17 09:27 |
| Reporter | menaures | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0000009: input_to loops may cause lag | ||||
| Description | I don't know if this is a bug. I don't even know if it can or should be fixed. Have any kind of input_to Loop, preferably charmode. If you know XED (LPC-based VT100 text editor), use XEDs input_to loop. Start the loop, then press and hold a key. With a high keyboard repeat rate, lets say that you're now sending 30 commands per second to the MUD. If you do this, the MUD immediately starts lagging, the CPU load goes up and up. If you release the key after a minute or so, you can watch the MUD for yet another minute, until it finishes executing all your commands. Question: Is there a way, driver-sided, not to allow a single user / command loop to slow the whole MUD down in such a manner? Maybe it can be prioritized, so that input_to commands are only executed when everything else is done, so that it would not be possible to slow the MUD down that much. Same maybe applies to normal commands as well, only that problem is not present in UNItopia, because players are kicked if they send commands too fast. I don't know how the driver handles incoming commands currently, but judging from the drivers behaviour, it looks like a FIFO queue. Whatever comes in first is executed first, which makes it possible for users who send lots of commands pretty fast to drown all others. What I'm suggesting is fair queuing, to give every session the chance to issue a command in turn (if you know lartc/tc/QoS, this would be something like SFQ). And generally execute "normal" commands first before looking at special input_to's. | ||||
| Tags | No tags attached. | ||||
|
|
Oh yeah: I don't see how the charmode problem could be solved in LPC. The only way to add a pause to execution seems to be a call_out, which would make editing pretty awkward, since half of the typed keys would never actually be seen in the editor. In the editor example, its more likely that it messes the look in the local terminal window up. And throwing wizards out of an editor if they send too many keypresses would not come in handy, either. However, the problem only exists in theory, 'cause we usually don't have the kind of maniacs who keep keys pressed for ages :-) It came up when the driver generally had high CPU loads recently, and under these conditions xed was discovered to be the cause of really, really bad lags. |
|
|
I'm not quite sure yet how to solve this, as the driver already tries to be fair about the command handling: it does one select() over all connections, then it loops over the connections, checking if there is new data. If there is new data on a connection, it is read and evaluated, then the next connection is checked. Only when all connections have been checked, the driver does another select(). What happened here is probably that the editor user send many packets (lets say 20) when others send only one. So 19 times the driver did a select(), found the packet from the editor user, evaluated it, then did the select() again. Only on the 20th repetition, data from the other users arrived, but by then the driver had already spent lots of time in the editor code. Prioritizing the input_to()s wouldn't help, as the most of the time the input_to() was in fact the only connection getting data. One possible solution would be to limit the amount of packets a connection can receive within a 'tick' (currently two seconds). 10 packets per second seems to be a good default to still allow interactive editing. |
|
|
3.2.10-dev.601 experimentally limits the number of commands per second to 10. Let me know if that helps limiting the problem. |
|
|
avalon's been with it for 1/2 year now. seems to work just fine. |
|
|
The limitation of the number of commands per second has since been made configurable through a new efun set_max_commands()/get_max_commands() (3.2.10-dev.606, 3.3.488). Since that seems to be sufficient to handle the problem, this bug can be closed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-08-11 19:14 | menaures | New Issue | |
| 2003-08-11 19:21 | menaures | Note Added: 0000020 | |
| 2003-08-11 21:58 |
|
Note Added: 0000022 | |
| 2003-08-12 00:59 |
|
Note Added: 0000023 | |
| 2004-01-20 16:16 | xtian | Note Added: 0000028 | |
| 2004-03-30 00:10 |
|
Status | new => resolved |
| 2004-03-30 00:10 |
|
Resolution | open => fixed |
| 2004-03-30 00:10 |
|
Assigned To | => lars |
| 2004-03-30 00:10 |
|
Note Added: 0000036 | |
| 2004-05-17 09:27 |
|
Status | resolved => closed |
