Question on addon feasibility

[Buzzkill]

Greetings all.  Quick-ish question for you on an idea I've had bouncing around in my head.

A little back story.  I was fairly involved in the scene about 10 years ago, doing development on MetaMod with Hulu and to some extent AdminMod.  I recently got pulled back in when I found my kids playing GMod  (the circle is now complete!).

So I fired up a junk PC and have been screwing around with a sandbox server.  Given the low CPU specs, spam is something I'm paying close attention to.  I'm currently using PatchProtect, which is my favorite-of-the-day, and it does a decent job, but the server can still get run into the ground on occasion.  I was thinking about a more brute force approach....

Say an addon monitored performance and if it detected CPU > X for more than Y periods, it began intelligently removing props.  In theory it sounds like it has some possibilities, but I was wondering if anyone had already tried this and run into some issue that isn't obvious to me. Any thoughts or insight is appreciated.

Thanks for the time.
Buzz / Mike

[Neku]

I'm not sure if you can retrieve CPU usage in Garry's Mod.

There are plenty of other alternatives for removing props, just Google "gmod anti prop abuse" or something along those lines.

[XxLMM13xX]

DarkRP servers come with a anti pro spam unit if that's what you mean

[Buzzkill]

Thanks guys.  I realize that there are a number of anti-spam, prop protection tools.  I've played with Simple Prop Protection, Falco's and Patch Protect.  They all do a good job of restricting props and throttling spam.  However, it seems there'd be some value in attacking the problem from the other end (ie, when the server gets slammed).  If processor usage stats aren't available through GMod then it's probably a no-go then.

[MrPresident]

We had an addon that we made at one point that would disable physics if the game started lagging. You can compare CurTime with RealTime or something like that to see if it's starting to slow. I don't quite remember.

[Buzzkill]

Interesting. Might Frametime provide better insight into point-in-time server performance?  There'd need to be some averaging and perhaps a baseline value calculated at map start, of course.  Maybe even some kind of function against active player count.

[Neku]

Perhaps something along the lines of this:

Code: Lua

1. local timerange = 10 -- Fill in the time, I'm unfamiliar with Cur/Real/SysTime
2.  
3. function GetTimeRange()
4.         return RealTime() - CurTime()
5. end
6.  
7. function IsTimeSync()
8.         if GetTimeRange() < timerange then
9.                 return false
10.         end
11.         return true
12. end

[Buzzkill]

I'm starting to play with this again.  What kind of variation should I see between Cur and Real during laggy situations?  I can bring server FPS down to under 10 and still not see any difference in the spread between Cur and Real.

I wish RunConsoleCommand would return the output --- then a simple call to stats would yield the server fps.  Seems that RunConsoleCommand is async, though.

[Buzzkill]

Ok, so after doing some controlled experiments and not just eyeballing, I do see some actionable delta values.  So here's what I've whipped together, in case anyone is interested. Seems to be working as expected for some basic lag checks.  No doubt my code is inefficient -- this is the first script I've written for a HL engine in 10 years and my first lua script ever. 

Code: [Select]

if SERVER then


local timerange = CreateConVar( "timemon_range", "0.03", { FCVAR_ARCHIVE, FCVAR_REPLICATED } )
local timecount = CreateConVar( "timemon_count", "2", { FCVAR_ARCHIVE, FCVAR_REPLICATED } )
local timesettle = CreateConVar( "timemon_period", "30", { FCVAR_ARCHIVE, FCVAR_REPLICATED } )

local lastSysCurrDiff = 9999
local deltaSysCurrDiff = 0

local currcount = 0




function GetCurrentDelta()
local SysCurrDiff = SysTime() - CurTime()
deltaSysCurrDiff = SysCurrDiff - lastSysCurrDiff
lastSysCurrDiff = SysCurrDiff
--print("dbg:deltaSysCurrDiff",deltaSysCurrDiff) -- dbg, remove
return deltaSysCurrDiff
end


function TimeMonThreshold()

-- see if we've settled down from previous lag
if currcount > 0 then
if RealTime() > clearTime then
currcount = 0
print ("TimeMon: Cleared count due to quiet server")
end
end

-- nothing interesting here.  move along
if GetCurrentDelta() < timerange:GetFloat() then
return false
end

-- server is lagging
currcount = currcount + 1
print ("TimeMon: Server is lagging. Count = ", currcount)
clearTime = RealTime() + timesettle:GetInt()
if (currcount >= timecount:GetInt()) then
currcount = 0
return true
end

return false
end


timer.Create("CheckPerf",1, 0, function()
--RunConsoleCommand("stats") -- dbg. remove
if TimeMonThreshold() then
print("TimeMon: Initiating entity cleanup. Timing delta is ", deltaSysCurrDiff)
RunConsoleCommand("gmod_admin_cleanup")
end
end)


end




[JamminR]

Nice work.
I hope it proves over use to remain accurate in detecting deltas just due to CPU / malicious spam/bad physics (malicious or not).
However, though I like the monitoring idea, playing on a server where one person caused lag and then got any creation I had been working (for me, possibly an/for hour(s) ....I'm just slow that way) on would really peeve me to lose it mid build.
Yes, I know, one person causing lag might crash a server and then I'd be in same boat, but with how crazy Gmod is about glitching / picky about physics in the first place, admin clean seems almost as bad.

Years ago, there was a server I played on that host-selected users/groups etc could run a command that would freeze all props/physics, and would prevent players from spawning more props, while allowing discussion/research as to if another player was spamming, or had built something that was spazzing/glitching the physics.
Items/contraptions could be unfrozen using phys gun (by both players and admins), or, if player abuse found, ban the player and along with it his lag causing props would be removed

As you develop more, I'd think adding features like that might be better than just clearing all.

[Buzzkill]

Yep -- this is definitely a brute force approach to managing lag, and would be a nightmare for a serious build server (in fact, it would likely backfire and allow trolls to do more damage once they discovered that lagging the server wiped the field).  This is much more of an experiment on my part to detect lag, and will hopefully evolve in time.

[JamminR]

Keep up the great work and ideas. I like seeing intelligent design and questions within the community.
I'm glad your kids got you involved in a fun project.
Perhaps they have ideas that could lead to even further fun.