[Bug] Fix ZMap not obeying --rate edge case#907
Merged
Conversation
zakird
approved these changes
Nov 27, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #903
Thanks to @huxcrux for helping to debug this issue that I was having difficulty reproducing locally.
The bug he saw was that sometimes, ZMap would not obey the
--ratelimit set in the CLI. After investigation, the issue is here. The adaptive timing code uses an adaptive delay to ensure the send rate stays near the user's desired rate.This code works in most circumstances, however if some outside influence (other processes in @huxcrux's case were having contention on the core, when he used
--cores=to pin ZMap, the effect was far reduced) prevents ZMap from sending at the desired rate, this adaptive delay will decrease to attempt to send faster. If ZMap is continually prevented from sending at the desired rate, thedelayvariable will be halved repeatedly until eventually it becomes equal to zero. With adelay = 0, it will remain locked at 0 even if in the future ZMap can send faster. The adaptive delay logic uses a multiplier to modifydelayand ifdelay = 0, it'll stay at 0.From this point on, the delay will be locked at
delay = 0and ZMap will send at the maximum rate supported by the NIC and CPU.Testing
To reproduce what @huxcrux saw, I used
tcto artificially limit the bandwidth of my testing VM.main
TImeline Summary
--rate=24000Phillip/903-force-delay-nonzero--rate=24000--rate=24000Here you can see the bandwidth constraints imposed and the send rate drop. But after they're lifted, we just return to sending at
24000.