jbrzusto / find_tags

search raw data streams for patterns from registered tags
GNU General Public License v2.0
2 stars 0 forks source link

tag being detected before deployment date #41

Closed jbrzusto closed 7 years ago

jbrzusto commented 7 years ago

e.g.: Tag 15584 is being detected 45 seconds before its deployment time:


MariaDB [motus]> select * from runs where motusTagID=15584 order by tsBegin limit 1;
+-------+--------------+-----------------+-----------------+------+------------+-----+-----+-----------------+
| runID | batchIDbegin | tsBegin         | tsEnd           | done | motusTagID | ant | len | tagDepProjectID |
+-------+--------------+-----------------+-----------------+------+------------+-----+-----+-----------------+
| 24128 |            7 | 1441106955.8745 | 1441107046.9688 |    1 |      15584 |   2 |   3 |            NULL |
+-------+--------------+-----------------+-----------------+------+------------+-----+-----+-----------------+

MariaDB [motus]> select * from tagDeps where motusTagID=15584;
+-----------+------------+------------+------------------+
| projectID | motusTagID | tsStart    | tsEnd            |
+-----------+------------+------------+------------------+
|        74 |      15584 | 1441107000 | 1445367361.59924 |
+-----------+------------+------------+------------------+

MariaDB [motus]> select * from batches where batchID=7;
+---------+---------------+--------+----------------+-----------------+---------+------------------+---------+-------------+----------------+------------+------------------+
| batchID | motusDeviceID | monoBN | tsStart        | tsEnd           | numHits | ts               | tsMotus | motusUserID | motusProjectID | motusJobID | recvDepProjectID |
+---------+---------------+--------+----------------+-----------------+---------+------------------+---------+-------------+----------------+------------+------------------+
|       7 |           479 |      1 | 1428940602.091 | 1477479263.8008 |  311115 | 1504010229.85168 |       0 |        NULL |           NULL |         42 |               74 |
+---------+---------------+--------+----------------+-----------------+---------+------------------+---------+-------------+----------------+------------+------------------+

sqlite> select * from events where tagID=15584;
ts            tagID       event     
------------  ----------  ----------
1441107000.0  15584       1         
1445367361.5  15584       0         
jbrzusto commented 7 years ago

This happens when a burst detected before the nominal activation starts a tag candidate at the SINGLE tag_id_level, and adding the tag demotes it to MULTIPLE tag_id_level, but maintains it as an active candidate. This is a minor issue: we should get at most one pre- activation detection in the run, and it won't be too far back in time. Trying to prevent this would require versioning the DFA graph so that existing candidates at the single confirmation level would continue to follow the original graph when the latter was modified by addition of a new tag. Hardly seems worth the trouble!

This issue was only noticed because it led to many runs of unambiguous tags having tagDepProjectID unset. That more significant problem can be solved by allowing some slop in deployment time for assigning projectID. When allowing a 20 minute slop in tag deployment time, only 8 out of 1290440 runs of real tags could not be assigned a tagDepProjectID:

MariaDB [motus]> select * from runs where motusTagID > 0 and tagDepProjectID is null;
+---------+--------------+-----------------+-----------------+------+------------+-----+-----+-----------------+
| runID   | batchIDbegin | tsBegin         | tsEnd           | done | motusTagID | ant | len | tagDepProjectID |
+---------+--------------+-----------------+-----------------+------+------------+-----+-----+-----------------+
|  106839 |            8 | 1498206547.9259 | 1498206607.6563 |    1 |      25169 |   1 |   2 |            NULL |
|  109189 |            8 | 1498294349.7439 |  1498294469.052 |    1 |      25169 |   1 |   3 |            NULL |
|  109206 |            8 |  1498294990.186 |  1498295183.965 |    1 |      25169 |   1 |   4 |            NULL |
|  112319 |            8 | 1498385651.1464 | 1498385785.3664 |    1 |      25180 |   4 |   3 |            NULL |
|  579046 |           41 | 1487272503.6707 | 1487272586.3943 |    1 |      22057 |   4 |   2 |            NULL |
|  730317 |           45 |  1479911675.085 | 1479911757.8929 |    1 |      22057 |   6 |   2 |            NULL |
| 1189627 |           59 | 1496101785.6944 | 1496101860.3699 |    1 |      25187 |   3 |   2 |            NULL |
| 1190124 |           59 | 1496749993.2235 | 1496750022.8969 |    1 |      22057 |   3 |   2 |            NULL |
+---------+--------------+-----------------+-----------------+------+------------+-----+-----+-----------------+
8 rows in set (1.11 sec)

This presumably indicates another problem, but we defer investigation for now. The case of tag 25169 in the table above disappeared on rerunning; perhaps metadata changed.