Skip to content

Commit

Permalink
Add test for constant interval greater than 1000ms
Browse files Browse the repository at this point in the history
  • Loading branch information
Erik Rigtorp authored and rigtorp committed Dec 31, 2019
1 parent a568aa2 commit 43070a6
Show file tree
Hide file tree
Showing 3 changed files with 12 additions and 1 deletion.
1 change: 1 addition & 0 deletions CMakeLists.txt
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,7 @@ install(TARGETS udpreplay DESTINATION bin/)
enable_testing()

add_test(constant-interval ${CMAKE_SOURCE_DIR}/test/constant-interval.expect)
add_test(constant-interval-ge1 ${CMAKE_SOURCE_DIR}/test/constant-interval-ge1.expect)

add_test(high-speed ${CMAKE_SOURCE_DIR}/test/high-speed.expect)

Expand Down
2 changes: 1 addition & 1 deletion src/udpreplay.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -201,7 +201,7 @@ int main(int argc, char *argv[]) {
if (interval != -1) {
// Use constant packet rate
deadline.tv_sec += interval / 1000L;
deadline.tv_nsec += interval * 1000000L;
deadline.tv_nsec += (interval * 1000000L) % NANOSECONDS_PER_SECOND;
} else {
// Next packet deadline = start + (packet ts - first packet ts) * speed
int64_t delta =
Expand Down
10 changes: 10 additions & 0 deletions test/constant-interval-ge1.expect
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
#!/usr/bin/expect -f

# Deadline was not incremented correctly for intervals greater than 1000ms

spawn time -p ./udpreplay -i lo -c 1001 ../test/test.pcap
wait
expect {
default { exit 1 }
"real 3.0" { exit 0 }
}

2 comments on commit 43070a6

@sobomax
Copy link
Contributor

@sobomax sobomax commented on 43070a6 Feb 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rigtorp I believe the test is not exactly correct and the fix is incomplete. Sending 3 packets with a constant interval of 1.001 second inbeetween should only take 2.002 seconds, not 3.003 seconds as one might naively think. This is because packet P1 goes out at 0.0s, packet P2 at 1.001s and packet P3 at 2.002s mark. Assuming logic works correctly. There is some bug in timing code, which either causes pause between P1 or pause after P3, neither is really justified IMHO. My fork does not have this issue, feel free to cherry-pick some commits to get this fixed.

@rigtorp
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is on purpose, it was the simplest implementation such that when using repeating mode the constant interval is honored. Doesn't seem worth it to complicate the code for this. You would need to not increment deadline for the first packet for the first repeat.

Please sign in to comment.