Better statistical understanding of PrioQ benefits/drawbacks

[dkmur]

Usage of PrioQ has pro’s and con’s, proper evaluation today isn’t that easy.

I guess the main reason for using PrioQ is having a proper de-spawn time yet this is hard to measure as timediff on last_modified and disappear_time isn’t reliable if a mon is being scanned multiple times.

Suggestion: Add column first_scanned to table Pokémon.

This way, for an area, data on: location handled, location failure rate, teleport increase, teleport failure rate, increased location gandling time, Pokémon scanned and de-spawn time increase can be evaluated for better judgement if deployment of PrioQ is actually beneficial (for a specific area).

[krzee]

i see the benefits in my discord alert timers

[dkmur]

sure, just hard to quatify how much the average increase of de-spawn time for an area is while comparing that to the con's and from there possibly tune the parameters and analize that effect. Pretty much impossible to do from discord alert time really.

[Boby360]

I see the drawbacks when one spawn for whatever reason doesn't get gathered data. Then it goes back 15-20min later because of a different spawn and have a really shitty despawn time remaining. A non priority queue system could go over the point every 5min and have increased reliability.

[dkmur]

Measuring the con's is very wel possible today with location_raw, detect and pokemon stats . The pro's on the otherhand not so much

[dkmur]

maybe just adding column "first_detection datetime NOT NULL DEFAULT UTC_TIMESTAMP()" to table pokmemon would be sufficient

[ColdShadow80]

maybe just adding column "first_detection datetime NOT NULL DEFAULT UTC_TIMESTAMP()" to table pokmemon would be sufficient

"First encounter time" would be required to determine time of first IV scan/first encounter, therefore providing better statistical data to PrioQ.

[dkmur]

adding "first_detection" or "First encounter time" would also be usefull for improving global mon stats I guess as it is most likely using the "last_modified" timestamp.

One of my area's has a roundtrip time of about 10 minutes, so each mon is scanned at least two (often more) times by multiple workers. When looking at hourly global mon stats most of the mons spawning before and despawning after the hour would be counted in both hours showing a misleading number.

[crhbetz]

Maybe you guys would like to look into https://github.com/Map-A-Droid/MAD/pull/610 too? (fishing for reviews :-) ) I'm not doing statistics there, but I enhanced logging a bit in addition to my bug fixes, so you can see live how far your workers are behind, and it'll warn over events being dropped, at least.