As far as I can tell, siege/vegeta/ab/boom/wrk are all affected by Coordinated Omission, which makes their results of little value. The only tool I'm aware of doing this properly is wrk2. I'm not sure about the distributed tools, free JMeter or hosted like gatling.io and blitz.io, but I'm fairly certain that they all suffer from the same problem.
If you're reaching for a tool like that and can code in Go, implementing a correct one is very easy (~200 loc): just spin up new goroutines for each request at a regular interval.
Those tools all make use of a pool of workers. Say you want 1000 RPS, they'll make something like 100 workers and make them do 10 RPS each. To make 10 RPS each, their requests all must take at most 100ms each. The issue of coordinated omission arises when those requests take more than 100ms each and the rate of requests your measuring becomes distorted. This is well explained if you read Gil Tene:
How to avoid this error yourself? Don't make a pool of workers, have each 1000 requests be their own thread/goroutine. So you'll create 1000 goroutines per second, each of them doing their own request. This way you won't omit measurements by skipping beats.
The key is that the request rate be independent of the latency of individual requests.
In the case of wrk (the original wrk, not Gil Tene's version), you could use this version to check for maximum RPS / bandwidth. This is because it's sending requests as fast as it can, but one after the other.
In the case of wrk2, Gil Tene's version, you have to specify the rate at which to send requests. This is how it avoids coordinated omission.
If you're reaching for a tool like that and can code in Go, implementing a correct one is very easy (~200 loc): just spin up new goroutines for each request at a regular interval.