> On 4/05/2020, at 9:30 AM, Stuart Henderson wrote:
>
> On 2020/05/04 09:23, Richard Procter wrote:
>> I like it.
>>
>> Assuming a mention in tcpbench.1 - ok procter
>
> ok like this? text stolen from ping.
the server has an small edge case: it refuses to display stats
that don’t exist,
On 2020/05/04 09:23, Richard Procter wrote:
> I like it.
>
> Assuming a mention in tcpbench.1 - ok procter
ok like this? text stolen from ping.
Index: tcpbench.1
===
RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.1,v
retrieving
I like it.
Assuming a mention in tcpbench.1 - ok procter
> On 4/05/2020, at 4:25 AM, Stuart Henderson wrote:
>
> Is it worth triggering this on SIGINFO? I use that often with ping(1).
>
> Index: tcpbench.c
> ===
> RCS file:
On Sun, May 03, 2020 at 10:31:35AM -0600, Theo de Raadt wrote:
> Theo Buehler wrote:
>
> > On Sun, May 03, 2020 at 05:25:25PM +0100, Stuart Henderson wrote:
> > > Is it worth triggering this on SIGINFO? I use that often with ping(1).
> >
> > I was going to suggest a similar diff but couldn't
Theo Buehler wrote:
> On Sun, May 03, 2020 at 05:25:25PM +0100, Stuart Henderson wrote:
> > Is it worth triggering this on SIGINFO? I use that often with ping(1).
>
> I was going to suggest a similar diff but couldn't figure out why this
> breaks the stats at the end with ^C.
An error in
That's very nice.
I should mention that signal_handler() isn't an async signal handler,
since this is a libevent program using syncronous signal_set(). Therefore
the stdio and FPU use is safe.
Stuart Henderson wrote:
> Is it worth triggering this on SIGINFO? I use that often with ping(1).
>
On Sun, May 03, 2020 at 05:25:25PM +0100, Stuart Henderson wrote:
> Is it worth triggering this on SIGINFO? I use that often with ping(1).
I was going to suggest a similar diff but couldn't figure out why this
breaks the stats at the end with ^C.
>
> Index: tcpbench.c
>
Is it worth triggering this on SIGINFO? I use that often with ping(1).
Index: tcpbench.c
===
RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.c,v
retrieving revision 1.62
diff -u -p -r1.62 tcpbench.c
--- tcpbench.c 2 May 2020 22:00:29
Hi,
On 02/05/2020 12:41, richard.n.proc...@gmail.com wrote:
>> More assumptions are implied here. How do I measure a 2400 bps link
>> with this
>> report? The precision is lost in "%.3Lf".
> I highly doubt anyone needs to benchmark a 2400 bps link. The display is
> in any case precise to 1000
On Sat, 2 May 2020, j...@bitminer.ca wrote:
> A couple of further questions embedded:
>
> A question on the std-dev -- is this for "n" measures as defined
> by -r interval? "ping" reports an N packets transmitted. Maybe
> this is obvious but your revised manpage doesn't say. Could this
>
A couple of further questions embedded:
On 2020-05-02 05:41, richard.n.proc...@gmail.com wrote:
On Fri, 1 May 2020, j...@bitminer.ca wrote:
> From: richard.n.procter () gmail ! com
> This implements ping(1)-like summary statistics for tcpbench(1), e.g.
>
> ^C
> --- localhost tcpbench
On Fri, 1 May 2020, j...@bitminer.ca wrote:
> > From: richard.n.procter () gmail ! com
> > This implements ping(1)-like summary statistics for tcpbench(1), e.g.
> >
> > ^C
> > --- localhost tcpbench statistics ---
> > 1099642814 bytes sent over 4.126 seconds
> > bandwidth min/avg/max/std-dev =
From: richard.n.procter () gmail ! com
Date: Fri, 01 May 2020 10:12:05 +
To: openbsd-tech
Subject: [PATCH] add ping(1)-like stats to tcpbench(1)
Hi,
This implements ping(1)-like summary statistics for tcpbench(1), e.g.
^C
--- localhost tcpbench statistics ---
1099642814 bytes sent over
Hi,
This implements ping(1)-like summary statistics for tcpbench(1), e.g.
^C
--- localhost tcpbench statistics ---
1099642814 bytes sent over 4.126 seconds
bandwidth min/avg/max/std-dev = 1228.131/2117.309/2491.399/517.779 Mbps
The std-dev especially would have helped me catch a TCP
14 matches
Mail list logo
