11 posts
Posted 29 December 2012 - 07:33 PM
I'm not sure if ComputerCraft has something like this already, but a profiler might be useful on servers. An op should be able to check which computers are taking up the most CPU time or memory and remotely terminate them.
Maybe in the config there can be a way to make computer "crash" if they are taking up too much of a server's resources. Alternatively (or additionally) having a way to "throttle" computer craft computers to run slower might also be good, though I'm not certain how this should be achieved. This might be a crude solution, but maybe programs can be copied and very short "sleep" commands can be automatically inserted between lines effectively acting as a way to "throttle" the program.
997 posts
Location
Wellington, New Zealand
Posted 29 December 2012 - 09:57 PM
This would be very useful. I think the only practical way to do it is to crash computers that use too many resources (similar to "too long without yielding" but based on average load instead of time since last yield) or to just add an op command to show which computers are using the most time, because of how CC is currently implemented. There isn't a way to throttle individual computers.
2447 posts
Posted 29 December 2012 - 10:24 PM
There's no easy way of finding out how much CPU time or memory an individual computer is taking up. CC works in a separate thread also, so effects of a computer taking up CPU time is mitigated.
The way CC is coded, most of the time a CC computer will be suspended waiting for an event to be triggered.
2005 posts
Posted 29 December 2012 - 11:54 PM
True of well-written programs, but less true of programs that only work because of the liberal use of sleep(0) (though once they yield, it actually does take a while for them to get another turn). If you're determined, you can write a program that doesn't yield for several seconds at a time (and uses resources like a devil) without ever actually going too long without yielding.
If you check through the startup programs of computers, looking for sleep(0) (or similar nonsense), it should be pretty easy to spot offenders…at least innocent ones.
11 posts
Posted 30 December 2012 - 08:15 AM
I don't know much about how ComputerCraft was designed, but maybe CPU time could be figured out by replacing sleep and the timer events with versions that measure the time between the thread waking up and sleeping again?
Another concern might be bandwidth usage due to excessive screen updates.
2447 posts
Posted 30 December 2012 - 11:04 AM
I don't know much about how ComputerCraft was designed, but maybe CPU time could be figured out by replacing sleep and the timer events with versions that measure the time between the thread waking up and sleeping again?
Possible, but would require a big restructuring - I'd rather just re-implement the pseudo cooperative multitasking I managed to achieve a few versions back, meaning the time a computer can take up is limited.
Another concern might be bandwidth usage due to excessive screen updates.
I've seen network stats regarding CC - we actually use much less than most mods do. I have also done all I can to make bandwidth usage even less. 13 bytes saved per message isn't always much, but it soon adds up.
At the end of the day, regardless of the mod you're going to find things to pick at - but CC is surprisingly robust at what it uses CPU and network wise, considering what is possible with it.
302 posts
Posted 30 December 2012 - 12:17 PM
Possible, but would require a big restructuring - I'd rather just re-implement the pseudo cooperative multitasking I managed to achieve a few versions back, meaning the time a computer can take up is limited.
So, each computer would run in a separate thread? Or you just stop yielding to a computer for a calculated time?
997 posts
Location
Wellington, New Zealand
Posted 31 December 2012 - 02:30 AM
@Cloudy: it's easy to waste CPU maliciously with CC:
while true do
– set this as high as possible without causing "too long without yielding"
for k=1,1000000000 do end
sleep(0)
end
To measure CPU time, just measure time between yielding and receiving the next event. To measure CPU%, divide that by total time (same thing, but including time spent waiting for events)
2447 posts
Posted 31 December 2012 - 03:52 AM
I never said it wasn't possible maliciously. I also said if I was implementing measuring statistics in, I'd rather stop malicious cpu hogging happening in the first place.
997 posts
Location
Wellington, New Zealand
Posted 31 December 2012 - 05:26 PM
Well, if the statistics are much easier to implement than the prevention, then why not? It will give server owners some way to find malicious programs.
302 posts
Posted 31 December 2012 - 05:45 PM
Well, if the statistics are much easier to implement than the prevention, then why not? It will give server owners some way to find malicious programs.
Cloudy didn't say it was easier, he said that if statistics were available (implemented), then self-regulation would also be.
2005 posts
Posted 31 December 2012 - 10:21 PM
Must…Resist…Urge…To…Improve…Malicious…Code…
Ha, circumvented with "You're not supposed to post malicious code, duh!" rule.
I think that, all things being said and done, it's easier to tell if code is intentionally malicious than it is to infer the presence of malicious code from statistics. So while I grant that those statistics could be useful to a server owner looking for bad computers to eliminate, it would still be preferable to examine the code to determine the appropriate course of administrative action to take.
997 posts
Location
Wellington, New Zealand
Posted 31 December 2012 - 10:38 PM
Must…Resist…Urge…To…Improve…Malicious…Code…
Ha, circumvented with "You're not supposed to post malicious code, duh!" rule.
I think that, all things being said and done, it's easier to tell if code is intentionally malicious than it is to infer the presence of malicious code from statistics. So while I grant that those statistics could be useful to a server owner looking for bad computers to eliminate, it would still be preferable to examine the code to determine the appropriate course of administrative action to take.
Absolutely, but if you can't find the damn computer you can't take
any administrative action.
302 posts
Posted 01 January 2013 - 06:12 AM
Hum, this is kind of fun, it enlarges my idea of what kind of protections and tools are needed to control automatons (blocks/entities/ect that have a life of their own). Turtles are easy to spot visually (then again, one could hide, and make it go rampant between random intervals of time), but computers causing lag…. I think that this is something that can be solved with a custom OS. Server owners worried about it just have to modify the parallel API, so that it acts in case the original shell is taking too much CPU time, possibly by throwing an error (reboot may just re-start the problem, and shutdown can be bypassed by having a computer turning on the malicious computer automatically). That implemented, means the only way of running laggy code for long, would be to sit by a computer continuously re-starting the malicious code. Since there are tools to cycle over players (teleporting to them), and you can detect CC load with a computer, it would be easy to rig up an alert system and find the malicious player.
2005 posts
Posted 01 January 2013 - 06:23 AM
You can find the computer in the world save, where you can examine (and rewrite) it's files as you like.
1214 posts
Location
The Sammich Kingdom
Posted 01 January 2013 - 06:27 AM
Hum, this is kind of fun, it enlarges my idea of what kind of protections and tools are needed to control automatons (blocks/entities/ect that have a life of their own). Turtles are easy to spot visually (then again, one could hide, and make it go rampant between random intervals of time), but computers causing lag…. I think that this is something that can be solved with a custom OS. Server owners worried about it just have to modify the parallel API, so that it acts in case the original shell is taking too much CPU time, possibly by throwing an error (reboot may just re-start the problem, and shutdown can be bypassed by having a computer turning on the malicious computer automatically). That implemented, means the only way of running laggy code for long, would be to sit by a computer continuously re-starting the malicious code. Since there are tools to cycle over players (teleporting to them), and you can detect CC load with a computer, it would be easy to rig up an alert system and find the malicious player.
You can have a turtle start a computer. Also, some mods include a chunk loader, meaning you can have a computer in the farlands and not be able to find it.
302 posts
Posted 01 January 2013 - 06:52 AM
You can have a turtle start a computer. Also, some mods include a chunk loader, meaning you can have a computer in the farlands and not be able to find it.
Tht's why I suggested throwing an error instead of shutting down. Or can they reboot computers?
997 posts
Location
Wellington, New Zealand
Posted 01 January 2013 - 01:36 PM
You can't measure CPU time from Lua.
You can have a turtle start a computer. Also, some mods include a chunk loader, meaning you can have a computer in the farlands and not be able to find it.
Tht's why I suggested throwing an error instead of shutting down. Or can they reboot computers?
They can reboot computers. Computers can also reboot other computers.
302 posts
Posted 02 January 2013 - 02:57 AM
You can't measure CPU time from Lua.
I meant the kind of CPU time you mentioned:To measure CPU time, just measure time between yielding and receiving the next event. To measure CPU%, divide that by total time (same thing, but including time spent waiting for events)
They can reboot computers. Computers can also reboot other computers.
My bad. I guess that if the shell keeps track of previous errors thrown, and on boot decides to not run the startup program at all until it gets some keyboard interaction, would work; it wouldn't prevent continuous rebooting of computers, but that's about it. Interesting, if permissions are ever done, peripheral calls to computers will have to be controlled too.
997 posts
Location
Wellington, New Zealand
Posted 02 January 2013 - 01:55 PM
You can't measure CPU time from Lua.
I meant the kind of CPU time you mentioned:To measure CPU time, just measure time between yielding and receiving the next event. To measure CPU%, divide that by total time (same thing, but including time spent waiting for events)
Whoops, I had it backwards. Measure the time between receiving an event and yielding again. os.time() and os.clock() don't seem to update until the computer yields.
302 posts
Posted 02 January 2013 - 02:25 PM
They do update, immibis already knows via IRC. Tested both in CC-emu by me and on the real-game by immibis.