Re: Nmap SoC Ideas? (progress estimates)

[Ron <ron () skullsecurity net>]

On Sun, 21 Mar 2010 20:11:08 -0600 David Fifield
<david () bamsoftware com> wrote:
> I wasn't able to make an improvement in this despite trying. My page
> on it is http://www.bamsoftware.com/wiki/Nmap/CompletionTimeEstimates.
>
> Things that make this hard for Nmap are the fact that the scanning
> rate is not constant (speeds up and slows down for congestion
> control, so you have to filter the signal, but how much?), that the
> completion percentage at any instant is only an estimate (though it
> is pretty close in the case of a port scan), and that the completion
> percentage may decrease instantaneously when the retry counter
> increases.
>
> Bram Cohen has said it's "non-trivial." And that's for estimating
> download time, which is probably easier than what Nmap is doing. There
> are some ideas here though:
> http://bramcohen.livejournal.com/24122.html.
>
> You could measure the goodness of an estimation algorithm after the
> fact. If you have a sequence of N + 1 e (estimated) and a (actual)
> values, taken at times t[0..N], take the sum from i = 1 to N of
> (t[i] - t[i - 1]) * (e(t[i]) - a(t[i])^2 and divide by t[N] - t[0].
>
> David Fifield

We went through something like this at work on an app that takes potentially hours to run. We discovered it was just as 
good to have something spinning or colourful to let the user know that something was happening. The actual time didn't 
really matter, just feedback that something was going on. :)

-- 
Ron Bowes
http://www.skullsecurity.org
http://www.twitter.com/iagox86
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/