nmap-perf merged; summary of changes and benchmarks

[David Fifield <david () bamsoftware com>]

Hi all,

I just merged the nmap-perf branch into the trunk, with these changes:

        Don't make a host the global ping host until it moves to the
        completed hosts list, and only change the global ping probe if
        the new probe is no worse than the old.

        Restore the ping magnifier for host congestion window updates.

        Ignore the timing of certain ICMP errors that are likely to be
        rate limited and don't change the port or host state. Avoid
        making timing pings out of probes that elicit such errors. This
        used to be done only for port scans and only at -T4 and above
        (and didn't prohibit the creation of timing pings). Now it is
        done for host discovery too, and at all timing levels.

        Gracefully handle updates from the recent past in RateMeter.
        Doesn't affect performance, but avoids a rare assertion failure.

But of course what everyone's most interested in is tables and graphs:

http://www.bamsoftware.com/wiki/Nmap/PerformanceNotes#bench-11

There's a table and a graph there comparing the timing and accuracy of
three versions of Nmap: nmap from just before the merge, nmap-perf, and
nmap r11204 from before the nmap-perf branch was created. Records of
many previous benchmarks are in a linked archive page. The upshot of it
all is that performance is increased in some situations without losing
accuracy. Scans that are most likely to benefit are large-scale scans,
especially when hosts are filtered or firewalls are in place.

If you look at the diff of r11643:11645 the changes really aren't all
that extensive. That's not to say I haven't made a mistake; I missed an
important piece of code in the merge in r11644 that I went back and
added in r11645. The new changes have been tested pretty thoroughly over
the past weeks but of course I want to hear about any unusual behavior.

I want to thank Brandon Enright and Fyodor for helping me run benchmarks
and for advice and encouragement.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org