#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
244731 |
|
27-Dec-2012 |
luigi |
use nanosecond resolution, make sure gettimeofday is called at most every 100 packets.
|
#
234984 |
|
03-May-2012 |
luigi |
indicate the time per packet in nanoseconds.
|
#
227345 |
|
08-Nov-2011 |
cognet |
Add IPv6 support to netblast/netsend/netreceive
PR: bin/161368 Submitted by: Olivier Cochard-Labbe <olivier AT cochard doT me>
|
#
225334 |
|
02-Sep-2011 |
marius |
Fix alignment assumptions.
PR: 160289 Approved by: re (kib) MFC after: 3 days
|
#
198136 |
|
15-Oct-2009 |
luigi |
Support the specification of a range of destination ports e.g.
netsend 127.0.0.1 6666-7777 [payloadsize] [packet_rate] [duration]
This is useful to test the behaviour of systems that do some kind of flow classifications and so exhibit different behaviour depending on the number of flows that hit them. I plan to add a similar extension to sweep on a range of IP addresses, so we can issue a single command to flood (obviously, for testing purposes!) a number of different destinations.
When there is only one destination, we do a preliminary connect() of the socket so we can use send() instead of sendto(). When we have multiple ports, the socket is not connect()'ed and we do a sendto() instead. There is a performance hit in this case, as the throughput on the loopback interface (with a firewall rule that blocks the transmission) goes down from 900kpps to 490kpps on my test machine.
If the number of different destinations is limited, one option to explore is to have multiple connect()ed sockets.
MFC after: 1 month
|
#
198132 |
|
15-Oct-2009 |
luigi |
A small change to avoid calling gettimeofday() too often (hardwired to once every 20us at most).
I found out that on many machines round here, i could only get 300-400kpps with netsend even on loopback and a 'deny' rule in the firewall, while reducing the number of calls to gettimeofday() brings the value to 900kpps and more.
This code is just a quick fix for the problem. Of course it could be done better, with proper getopt() parsing and the like, but since this applies to the entire program i'll postpone that to when i have more time.
Reviewed by: rwatson MFC after: 1 month
|
#
166567 |
|
08-Feb-2007 |
rwatson |
Add 's' after printing the send interval to make it clear it's a send interval.
|
#
145367 |
|
21-Apr-2005 |
mux |
Fix printf() format string errors with 64-bit architectures.
Spotted by: pav
|
#
139121 |
|
21-Dec-2004 |
keramida |
Fix the build of netrate/ with WARNS=5 and add a Makefile.inc to make it the default for all the netrate test tools.
Approved by: rwatson
|
#
136259 |
|
08-Oct-2004 |
rwatson |
Use int format string, not a long format string.
|
#
135954 |
|
30-Sep-2004 |
rwatson |
While calling perror() on send() failure was useful for debugging the if_em "wedging" problem, large numbers of perror() calls impacts send performance. As such, just count the error, don't print it.
|
#
135750 |
|
24-Sep-2004 |
rwatson |
Print number of "waits" per second during transmission, not just waits per call to send().
|
#
135551 |
|
21-Sep-2004 |
rwatson |
Improve netsend timing logic in various ways: - Centralize time comparison. - Check clock resolution to make sure it has enough granularity to implement the desired wait interval. - Keep track of how many times the timing loop has to spin waiting for the next send time; report statistics. - Add commented out warning about deadlines being missed when spinning. - Improve statistics reporting generally to provide a more useful summary of sender condition after a run.
|
#
135485 |
|
19-Sep-2004 |
rwatson |
netsend uses an arbitrary maximum send rate to reject bogus arguments. It was previously 1mpps; raise to 10mpps. While here, get the error message right.
|
#
135042 |
|
10-Sep-2004 |
rwatson |
Add netrate (netreceive, netsend), a tool for generating (and sinking) UDP packets of specified size at a fixed rate. I've been using this for netperf-related testing.
|