Ticket #109 (closed defect: fixed)
Support quiet mode which doesn't print as much output
| Reported by: | aturner | Owned by: | aturner |
|---|---|---|---|
| Priority: | medium | Milestone: | 3.0.beta13 |
| Component: | tcpreplay | Version: | 3.0.beta12 |
| Keywords: | Cc: | ||
| Operating System: | Add to FAQ?: | ||
| Hardware: | All | ||
| Output of tcpreplay -V: | |||
Description
Hi,
i replayed a small dump file (about 30 packets) using -l 10000 at different speeds (2000, 4000, 8000 and 15000 pkts/s) using tcpreplay 2.x and tcpreplay 3.0.betax Both, tcpreplay 2 and 3, displayed the message
processing file: /home/lothar/net/localhost.dump
on stdout.
Tcpreplay 2 writes this message once, while tcpreplay 3.0 writes the message each time the dumpfile is processed. This behavior results in an huge amount of messages printed to the screen with tcpreplay. The more packets per second you replay, the more busy tcpreplay gets printing these messages.
Whereas tcpreplay 2 had no problem to send out all packets at 15000 pkts/s, tcpreplay 3 already got problems at 4000 pkts/s because it was so busy printing its messages.
I think it would be a good idea to get the tcpreplay-2 behavior back. Is that possible for the next beta or the final release?
Best regards,
Lothar
Change History
comment:2 Changed 5 years ago by aturner
- Status changed from closed to reopened
- Resolution fixed deleted
comment:4 Changed 5 years ago by aturner
- Status changed from reopened to closed
- Resolution set to fixed
- Summary changed from Don't print processing file multiple times when --loop > 1 to Support quiet mode which doesn't print as much output
Note: as far as I can tell, using --quiet has basically a very close to zero impact on performance.
(In [1696]) add --quiet mode. fixes #109