Re: massping-migration and other dev testing results

[David Fifield <david () bamsoftware com>]

On Wed, Sep 12, 2007 at 05:45:26AM +0000, Brandon Enright wrote:
> Okay, so I have results for adjusting the ping group sizes.
>
> Here are The two base scans with no adjustment.  These used -T5 only:
>
> david_mpm_r5824b.nmap:
> # Nmap done at Wed Sep 12 00:17:31 2007 -- 186368 IP addresses (15628 hosts
> up) scanned in 2640.259 seconds
>
> david_nmap_r5824b.nmap:
> # Nmap done at Wed Sep 12 00:49:08 2007 -- 186368 IP addresses (15901 hosts
> up) scanned in 4536.876 seconds
>
>
> Here are those scans repeated with --randomize-hosts to increase the ping
> group from 4096 to 16384:
>
> david_mpm_r5824c.nmap:
> # Nmap done at Wed Sep 12 01:27:32 2007 -- 186368 IP addresses (13327 hosts
> up) scanned in 2019.837 seconds
>
> david_nmap_r5824c.nmap:
> # Nmap done at Wed Sep 12 02:01:47 2007 -- 186368 IP addresses (14696 hosts
> up) scanned in 4073.890 seconds

I don't know why larger ping groups would decrease accuracy. It would
seem that a larger group would give slow hosts more time to respond.
I'll have to think about it.

> Now I modified PING_GROUP_SZ to be 65536 and didn't use --randomize-hosts:
>
> # Nmap done at Wed Sep 12 02:53:11 2007 -- 186368 IP addresses (6293 hosts
> up) scanned in 2654.588 seconds
>
> # Nmap done at Wed Sep 12 02:58:49 2007 -- 186368 IP addresses (4801 hosts
> up) scanned in 2992.511 seconds
>
> Ouch, that really hurt accuracy and actually slowed down the MPM branch.
> Clearly there is going to be some sweet spot and 2**16 is overkill.
> Maybe 4096 is good.  Maybe 8192 is better?  I'll have to test this.

Yeah, that's scary. ultra_scan does a lot of traversals of the whole
list of hosts on every iteration, so too many hosts will slow it down.
Now we have an upper bound.

David Fifield

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