semantics. As GEOM prevents actual concurrent accesses that are
deemed generally unsafe. As we know, as a rawio(1) user, that we
are intending to do something ostensibly unsafe, we can use a single
open(2) shared among the worker children and then use pread(2) and
pwrite(2) instead of read(2), write(2) and lseek(2). This properly
bypasses the sanity checks GEOM makes for concurrent access.
Additionally, sector size isn't and hasn't ever been necessarily 512
(or a multiple thereof), but we don't have many classical examples
of devices not the common case that we'd test rawio(1) with. In my
particular case, I'm using graid3(8) and have an effective sector size
of 1024. The program now attempts to use DIOCGSECTORSIZE to find
the correct base for a device and thus Works For Me.
Cursory review by: MAINTAINER
the port's version.
Clean up leftover .o files from the build before installing. On
some systems there are also .s files for no apparent reason, so
clean those up too.
other performance metrics of a network by sending a bulk TCP or UDP
stream over it.
Special features of thrulay include:
* For TCP, ability to measure round-trip delay along with throughput
* For UDP, ability to measure
- one-way delay, with quantiles
- packet loss
- packet duplication
- reordering
* For UDP, the ability to send precisely positioned true Poisson streams
(microsecond errors in sending times)
* Human- and machine-readable output (ready to be fed to gnuplot)
WWW: http://www.internet2.edu/~shalunov/thrulay/
PR: ports/87683
Submitted by: Stanislav Shalunov <shalunov@internet2.edu>
Pathrate is a tool that can estimate the capacity of network paths. An
important feature of Pathrate is that it is robust to cross traffic effects,
meaning that it can measure the path capacity even when the path is
significantly loaded. This is crucial, since the hardest paths to measure are
the heavily loaded ones.
WWW: http://www.cc.gatech.edu/fac/Constantinos.Dovrolis/pathrate.html
PR: ports/81295
Submitted by: dikshie <dikshie@lapi.itb.ac.id>
pathChirp is a new active probing tool for estimating the available bandwidth
on a communication network path. Based on the concept of "self-induced
congestion", pathChirp features an exponential flight pattern of probes we
call a chirp. Packet chirps offer several significant advantages over current
probing schemes based on packet pairs or packet trains. By rapidly increasing
the probing rate within each chirp, pathChirp obtains a rich set of
information from which to dynamically estimate the available bandwidth.
WWW: http://www.spin.rice.edu/Software/pathChirp/
PR: ports/81293
Submitted by: dikshie <dikshie@lapi.itb.ac.id>