PArSEC has two significant features which make for a much more pleasant testing/troubleshooting experience than is currently available for the UHS architectures:
First, targeted throughput; when running tests against PArSEC, you can configure the load-generators to try to produce a specific throughput, slowly increasing the total amount of load being sent till that target is reached. This enables a really efficient mechanism for approximating the maximum load a configuration can support (because you can set the target very high, and watch for the point in the test where the latency curve grows without-bound). It, more or less, deprecates sweeps.
Second, fine-grained telemetry. PArSEC can produce very thorough data for a single transaction execution trace (down to how long individual parts of the state-machine took to complete). This is wildly invaluable for debugging and troubleshooting bottlenecks.
Both of these would be massive help for #80, and neither should be particularly difficult to tackle!
PArSEC has two significant features which make for a much more pleasant testing/troubleshooting experience than is currently available for the UHS architectures:
First, targeted throughput; when running tests against PArSEC, you can configure the load-generators to try to produce a specific throughput, slowly increasing the total amount of load being sent till that target is reached. This enables a really efficient mechanism for approximating the maximum load a configuration can support (because you can set the target very high, and watch for the point in the test where the latency curve grows without-bound). It, more or less, deprecates sweeps.
Second, fine-grained telemetry. PArSEC can produce very thorough data for a single transaction execution trace (down to how long individual parts of the state-machine took to complete). This is wildly invaluable for debugging and troubleshooting bottlenecks.
Both of these would be massive help for #80, and neither should be particularly difficult to tackle!