Adjust the tuning parameters for real-world usage.

The tests assume a mesh network with known connections, the node doesn't,
 so unneeded packet leakage isn't really as controllable as I'd hoped.

What's definitely important is that the system doesn't cache entries for
 long enough that it starts continuously sending packets the wrong way
 no matter what.
This commit is contained in:
20kdc 2017-03-19 21:54:57 +00:00
parent 7f2d0c99a7
commit 880a4dff08
3 changed files with 7 additions and 5 deletions

View File

@ -33,7 +33,9 @@ return function (hostname, transmit, onReceive, time)
-- Expect another packet after this amount of time,
-- or else clear the known receivers cache entry.
local tuningExpectContinue = 600 + math.random(1200)
-- Minimum should be less or equal to tuningAttempts *
-- tuningAttemptTime in relib.
local tuningExpectContinue = 15 + math.random(15)
-- Flush the loop detector every so often.
-- This is not a complete clear.

View File

@ -15,8 +15,8 @@ return function (hostname, transmit, onRReceive, time)
-- The maximum amount of timers (used to cap memory usage)
local tuningMaxTimers = 0x200
local tuningClearAntiduplicate = 60
local tuningAttempts = 8
local tuningAttemptTime = 4
local tuningAttempts = 12
local tuningAttemptTime = 2.5
-- Just an array, no special index.
-- Contents : {

View File

@ -78,8 +78,8 @@ local function generateMessage()
nodes[na].output(nodenames[na], nodenames[nb], "T" .. tostring(math.random()))
end
-- ~Once every 5 seconds, think a polling script
local generateEvery = math.floor(50 / targetableCount)
-- This is set so it should reuse the same pair every 10 seconds(?)
local generateEvery = 1
local generateCount = 10000
while (generateCount > 0) or (#queuedCalls > 0) do
if (systime % generateEvery) == 0 then