Jump to content

Reset Average Reporting Time


kwdavids

Recommended Posts

just to put my .02 in

<snip>

...And my $0.02: considering how old this request now is, I consider it a waste of time to discuss it any further (but that's just my view; I'm not inclined to take any action to actually stop any further discussion of this topic, such as closing it). Either the SpamCop programmers have this on their list of things to "fix" or they don't. There's not much is users can do about it.
Link to comment
Share on other sites

...Assuming correct calculation, which may be at issue, skewed how? A change to a moving average or a report count isn't a lifetime average. Different numbers represent different things. Which calculation is appropriate does depend on what intent IronPost had when the number was included.
Evidently the simple equation (sum of ages on reporting)/(total reports) gets broken on occasion by errors in either/both the numerator and/or denominator. That skews the result which is intended to be the simple average of reporting time. Uncharacteristic input (such as an atypically old report) also skews the result although that should generally be a minor effect, given the restriction on the age of reports accepted for processing and the large, "lifetime", size of the denominator. But we know something occasionally goes astray and "impossible" results ensue. And we know the age on reporting, as seen during the parse, is variable depending on whether mailhosting is set up or not - which raises the whole question of "age".

The figure/"statistic" that would (logically) be of significance to Cisco/IronPort/SpamCop is the total number of reports submitted, it underlies the whole "user reporting" adjunct to the SCbl operation and represents the "product differentiation" of the SCbl. Don, on at least one occasion (IIRC), has demonstrated "here" the ability to cite this figure in relation to an individual reporter. Whatever the intention behind providing the users with the average reporting time it was, I think, enabled by the retention of this (denominator) factor as a matter of SC's vital concern.

IF (big supposition) the statistic is available, requests by reporters to provide it routinely (whether as well as or in place of the average reporting time) have been ignored. If Cisco/IronPort/SpamCop had any intention of restoring the credibility of the average reporting time figure they would provide it to eliminate or confirm that factor as the the principal problem in the equation. The fact they do not, to extend the chain of supposition, indicates to me that they probably do not wish to have it so closely scruitinized. Which would be bad news for Cisco/IronPort top management who probably rely to some extent on the accuracy of its aggregate value. (Yes, I know I'm cruel, Wazoo reminded me of that ages ago :D but it was not news even then.)

A neat way to sideline the accuracy issue would, indeed, be to restrict the average reporting time calculation - say to the 90 day period of user reporting history. Yes, this would represent a formidable processing overhead, truly, it would no longer be a "lifetime" measure - but it would reflect "current" user and system processing performance which might be at least as relevant to a greater number of reporters, especially given that the "long count" has little/no credibility in their eyes. Any errors would fairly quickly work their way through the count to be excreted into oblivion after (say) 90 days. If any such errors might be comparatively magnified, because of the comparatively low denominator, they will at least be highly visible - giving the opportunity for identification of the cause(s). But I think they're probably quite infrequent on any sensible timescale.

I'm surprised SC hasn't hit on this "solution" already, and implemented it with gleeful cries. I can only suppose my chain of supposition is faulty somewhere. Or the engineering staff have more pressing concerns (where's the emoticon for "just a touch ironic"?). Or both :unsure: IMUO - in my uninformed opinion.

Link to comment
Share on other sites

  • 3 weeks later...

Let me elaborate.

new_average = old_average * (1 - x) + new_reporting_time * x

Where X is how much the latest report.

The other reports' weights would decay exponentially.

X can be adjusted based on how many reports we have sent so far...and could cap at 1/100th.

Slewing X down harmonically would do the same thing as keeping track of all the parts manually. It's just that the previous average gets a bigger and bigger weight vs. the new report, so everything balances out.

"capping" the X factor at, say, 1/100th would give each new report a minimum weight in the new running average, and over time, new trends would weigh out the old stuff.

Link to comment
Share on other sites

  • 9 months later...
Evidently the simple equation (sum of ages on reporting)/(total reports) gets broken on occasion by errors in either/both the numerator and/or denominator. That skews the result which is intended to be the simple average of reporting time.

I was a bit surprized last week (maybe a week prior?) to see my number come down to 10 hours. Shortlived as it turns out. I just reported a attempted spam to the mailing-list/newsgroup archive .... within 10 minutes of receipt .. parse showed "0 hours old" .... my new reporting time is now showing as 39 hours. One just has to be amazed at the accuracy involved with the generation of this statistic.

Link to comment
Share on other sites

Actually the last thing I want to see is my average reporting time. ...
Yet many do. 'Twould indeed be better to scap it if it cannot be fixed, it is a bad look when it fails (calling into doubt other competencies) though it seems to function well enough for the silent majority. Not exactly the grapes of wrath, more like the cumquat of dicscontent (yes, yes, I use the OED spelling for that fruit and nanny filters be d*mned) but a needless distraction in any terms. Or fix it.
Link to comment
Share on other sites

  • 1 month later...

I'd like to reset mine too. I have been diligent at keeping my average reporting time at 2 hours, by making sure I never report any spam more than 3 hours old.

Suddenly, today, my average reporting time shows 25 hours! How is that possible, given that 24 hours is the maximum age for reporting spam?

It would be trivial to implement an exponential moving average to show the average reporting time for the last N reports:

N = number of reports to average = 300 or so.

w = weighting factor = 2/(N+1)

t = age of spam in current report

avg = most recent calculated average (this is the only value that needs to be stored)

Then new average reporting time = w*t + (1-w)*avg

This approximates a simple moving average calculated as the sum of the last N ages divided by N. The advantage with an exponential average, however, is that you need to store ONLY the last calculated value, nothing else.

Is the average reporting time used for anything, such as weighting the importance of certain reports over others?

-Alex

Link to comment
Share on other sites

  • 1 month later...
somehow, yesterday, my reporting time sent from 1 hour to 8.1 days.i know it is stupid, but i like my 1 hour reporting time.

is there anyone that can correct this please???

Sadly, no. It is well documented that the average reporting time appears to have little correlation with fact. Some users have seen the opposite to your experience but pretty much everyone who has taken any interest in the figure has come to realise that it is virtually meaningless.

There is an old thread on this topic which I can't find just now but I'm sure someone else will point you to it in due course. In fact an admin may well merge this thread with the older one.

Andrew

Link to comment
Share on other sites

  • 2 months later...
I was a bit surprized last week (maybe a week prior?) to see my number come down to 10 hours. Shortlived as it turns out. I just reported a attempted spam to the mailing-list/newsgroup archive .... within 10 minutes of receipt .. parse showed "0 hours old" .... my new reporting time is now showing as 39 hours. One just has to be amazed at the accuracy involved with the generation of this statistic.

Wicked .. had worked that data down to showing 22 hours .... submitted one spam at 9 hours old, the next at 6 hours, old .. Average Reporting Time jumped to 42 hours .... "not bad" isn't exactly my thought .. geeze ...

Link to comment
Share on other sites

...Home 7.5 DAYS

Work 9 hours

Amazing, I'm seeing 9 hours from work too - but from the +0800 time zone (well, +0900 with DST). On the assumption that spam is 'international' I would have expected an appreciable difference compared to a reporter in the -0500 zone. I guess the work spam really is 'targetted', right down to/including sending times (maybe 70-80% 'overnight', very considerate, slightly extra volume over the weekends, 25-30% of which is too old to report by Monday). If I could trust the reporting time stats - seems about right in my case.
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...