Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor shared code between latency and latencybg tests #1450

Open
arlake228 opened this issue Jun 26, 2024 · 2 comments
Open

Refactor shared code between latency and latencybg tests #1450

arlake228 opened this issue Jun 26, 2024 · 2 comments

Comments

@arlake228
Copy link
Collaborator

Currently the latency and latencybg tests have a lot of copy and pasted code between them which make it challenging when you need to do updates since you have to do it in two place. Its made worse by the fact that its clearly copy and pasted but file structures and such don't even match, so its "just close enough to be annoying". For example, the result formatting is almost exactly the same even though each test has its own independent copy. Recently we fixed how bucket width is handled in latency and that did not make its way to latencybg since it was separate even though the code is similar.

We should give them some proper shared libraries between them for code like this. They are legitimately different tests, but for the common bits we should only need to update code in one place.

@arlake228 arlake228 converted this from a draft issue Jun 26, 2024
@mfeit-internet2
Copy link
Member

Semi-related: #994

@mfeit-internet2
Copy link
Member

The plan for this should be:

  • Adjust the internal architecture so the winning tool plugin selects the scheduling class instead of having it hard-wired in the test enumeration. This won't matter because no scheduling happens until the tool has been selected.

  • Merge latencybg into latency, adding parameters that will allow tools to accept/reject tasks depending on the parameters. (E.g., owping only accepts tests without parameters that make them long-running and powstream accepts those with them.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Ready
Development

No branches or pull requests

2 participants