Conditions for printing timing estimates

[David Fifield <david () bamsoftware com>]

Hi,

While checking out Henri's patch from http://seclists.org/nmap-dev/2009/q1/0348.html
I looked closely at how the ScanProgressMeter decides when it should
print an update. It looked to me like the code didn't match the
intention so I changed it to do what I think it was trying to do in
r12088.

The code said

  /* If the estimate changed by more than X minutes, and if that
     change represents at least X% of the time remaining, print
     it.  */
  prev_est_time_left_s = difftime(last_est.tv_sec, now->tv_sec);
  change_abs_s = ABS(prev_est_time_left_s - time_left_s);
  if (prev_est_time_left_s <= 0)
    printit = true;
  else if (o.debugging || (change_abs_s > 180 && change_abs_s > .05 * MAX(time_left_s, prev_est_time_left_s)))
    printit = true;

time_left_s is the current estimate of the time remaining. According to
the comment, prev_est_time_left_s is supposed to be the time remaining
at the last time stats were printed, but the calculation is wrong.
last_est is the last estimated completion time, so the time remaining at
the time of the last print is (last_est - last_print), not (last_est - now).
now changes all the time, so prev_est_time_left_s is changing too,
decreasing at a constant rate. time_left_ms is decreasing at the same
rate, if the scan is going smoothly. That means their difference is
constant. So once the difference is less than 180 seconds, you would get
no more estimates. I think what was intended was to print an update
every 180 seconds as long as the scan has progressed sufficiently, so I
made it do that.

I also changed the rule requiring the time elapsed since the last
printing to be 5% of the time remaining. With that rule updates become
asymptotically faster and faster as the time remaining decreases, though
there are other mechanisms that keep them from going too fast. What I
think was meant is that the time elapsed should be 5% of the total
estimated time, so you get around 20 updates if the scan is sufficiently
long.

David Fifield

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