The per-host completion fraction is calculated (
ports_finished * ( maxtries - 1 ) + probes_sent
maxtries * numprobes
The total completion percentage is calculated from this across all the hosts.
In a TCP scan (
-sT) the number of probes
numprobes is fixed to the number of ports (
scan_engine.cc UltraScanInfo::numProbesPerHost()) and never changes after initialization, so
maxtries is the interesting term of the calculation.
probes_sent are incrementing counters, the above works out to 1.0 when
ports_finished == probes_sent == numprobes.
numprobes will be 1000, the default number of TCP probes in the example you gave.
maxtries increases (due to timeout and retry) the estimated amount of work left to do increases, and hence the fraction of work completed decreases. (
--max-retries can control this, though with a
-sT for TCP connection by the OS IP stack
connect() some of the other timeout/retry parameters that nmap supports are ineffective).
maxtries count is not naïve, it is the high water mark of retries (+1) for a successfully probed port in the scan so far. If you add
-d (debug) you will see the message "Increasing max_successful_tryno for 184.108.40.206 to 1 (packet drop)". This is not the same message as "Increasing send delay ...". You will likely see both messages when there is packet loss during a scan.
What you have seen then is a successful TCP probe for a host, but it required a retry, it occurred late in the scan and managed to bump up the upper bound on the work estimate. It probably revised the completion down more than 1%, and packet loss probably cause timeouts to increase, decreasing the scan rate. Approximately 4 minutes elapsed between the two status lines, so the drop in completion was not simply 0.01%.
Service scan timing is a separate calculation.