-
Notifications
You must be signed in to change notification settings - Fork 268
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
[Bug] Packets slowly drift further and further behind when they should be sent #630
Comments
I have not seen this before. I need more context. Please fill in the bug report. Describe the bug To Reproduce Expected behavior Screenshots System (please complete the following information):
Additional context |
tcpreplay slowly loses time meaning that packets get more and more delayed as the playout continues. An easy way to reproduce this is:
The timestamps for the packets gets behind by a couple of microseconds for each packet. After 60 packets it's behind by 100 microseconds. The Actual time reported after playback being over 10 seconds accurately reflects the drift.
and the playback took 9.99 seconds each time I had assumed that the reference to tcpreplay in this academic paper referred to this same issue, though it's hard to say https://core.ac.uk/download/pdf/33506736.pdf
OS: Debian linux Note that I found this replaying real captures which contained video PCR data, it's just |
Thanks for the bug report. Scheduled for next release. |
Verification of PR #631 ... Played back a basic ping file and compared expected vs. actual debug log results. They match:
|
This issue became more evident with #630. First file has proper deltas, second file sends with no delay. Tested with 2 ping.pcap files and obverved proper delays.
Using a simple tcpreplay e.g.
sudo src/tcpreplay -K test.pcap
If I record another PCAP of the playout, the packets in the playout happen later and later compared to the original test.pcap. The reason is that the timing is all done using deltas between packets and errors in timing accumulate. This has a huge impact on playback of time sensitive PCAPs e.g. UDP video containing PCR timestamps.
I have a suggested patch for this which switches to comparing times since the first packet was sent.
The text was updated successfully, but these errors were encountered: