Giter Club home page Giter Club logo

seqtest's People

Contributors

gdamore avatar rzezeski avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

seqtest's Issues

small patch to allow build on freebsd

--- seqtest.c.orig 2016-02-07 18:44:38 UTC
+++ seqtest.c
@@ -56,7 +56,7 @@ typedef struct sample {

  • Amazing - MacOS X doesn't have a standards conforming version
  • of high resolution timers.
    */
    -#ifdef APPLE
    +#if defined(APPLE) || defined(FreeBSD)
    uint64_t
    gethrtime(void)
    {

seqtest crashes without a count option

[garrett@ny4-c106-sdn08 build]$ ./seqtest -s 127.0.0.1:6699
Address 0: Host 127.0.0.1 Port 6699
replier/recv: Connection reset by peer
Segmentation fault (core dumped)

Probably it needs to have a minimum count.

sender and replier need couples therapy

Both the README and code comments would have you believe that only the sender requires options. That you can simply start the replier and it will base its behavior (per connection) on the sender's options as passed to -o. This would lead one to believe that the sender and replier negotiate the benchmark terms before starting the benchmark. However, while trying to diagnose something else, I noticed some unexpected behavior from the replier process. For each message from the sender it used two recv(2) calls. This DTrace snippet below makes the behavior clear:

# dtrace -n 'syscall::recv:entry /cpu == 19/ { @["ask"] = quantize(arg2); @s[ustack()] = count(); }' -c 'psrset -e 5 /zones/826df1b9-e66f-493e-8bd2-8125a3b04bf3/root/root/seqtest-master/seqtest -S -o ssize=200,rsize=200,threads=1,count=100000 192.168.241.75,192.168.241.74:6667'
dtrace: description 'syscall::recv:entry ' matched 1 probe
ssz_max 200
Address 0: Host 192.168.241.74 Port 6667
t->ssz_max 200
Received 100000 replies
Time: 5121763.8 us
ROUND TRIP LATENCY:
Average:  49.5 us
Stddev:   0.8 us
Median:   49.5 us
90.0%ile: 49.9 us
99.0%ile: 50.3 us
99.9%ile: 52.7 us
Minimum:  42.7 us
Maximum:  127.9 us
dtrace: pid 23264 has exited

  ask
           value  ------------- Distribution ------------- count
              16 |                                         0
              32 |@@@@@@@@@@@@@@@@@@@@                     100001
              64 |                                         0
             128 |@@@@@@@@@@@@@@@@@@@@                     100000
             256 |                                         0


              libc.so.1`__so_recv+0xa
              libsocket.so.1`recv+0x22
              seqtest`replier+0xfb
              libc.so.1`_thrp_setup+0x8a
              libc.so.1`_lwp_start
           200001

Notice there are 200K calls to recv(2) on the replier alone. That's 100K more than expected.

If I pass options to the replier, so that it is aware of the proper size, things work as expected.

# psrset -e 6 /zones/826df1b9-e66f-493e-8bd2-8125a3b04bf3/root/root/seqtest-master/seqtest -o ssize=200,rsize=200 -r 192.168.241.74:6667
Address 0: Host 192.168.241.74 Port 6667
# dtrace -n 'syscall::recv:entry /cpu == 19/ { @["ask"] = quantize(arg2); @s[ustack()] = count(); }' -c 'psrset -e 5 /zones/826df1b9-e66f-493e-8bd2-8125a3b04bf3/root/root/seqtest-master/seqtest -S -o ssize=200,rsize=200,threads=1,count=100000 192.168.241.75,192.168.241.74:6667'
dtrace: description 'syscall::recv:entry ' matched 1 probe
Address 0: Host 192.168.241.74 Port 6667
Received 100000 replies
Time: 5121178.0 us
ROUND TRIP LATENCY:
Average:  49.5 us
Stddev:   0.7 us
Median:   49.5 us
90.0%ile: 49.9 us
99.0%ile: 50.4 us
99.9%ile: 52.0 us
Minimum:  38.3 us
Maximum:  126.6 us
dtrace: pid 23203 has exited

  ask
           value  ------------- Distribution ------------- count
              64 |                                         0
             128 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 100001
             256 |                                         0


              libc.so.1`__so_recv+0xa
              libsocket.so.1`recv+0x22
              seqtest`replier+0xfb
              libc.so.1`_thrp_setup+0x8a
              libc.so.1`_lwp_start
           100001

My preferred fix:

  1. Implement the sender/replier negotiation.
  2. For each benchmark connection have the replier print a one line summary describing negotiated parameters.
  3. If someone passes -o to replier print usage and exit.

build with CMake

CMake is a nicer way to build -- the old Makefile depended on GNU make, and frankly failed to function in a variety of scenarios. Easier to just use CMake and test for libm, libnsl,and libsocket.

strlcpy missing on Linux

[garrett@ny4-c106-sdn08 build]$ make
Scanning dependencies of target seqtest
[100%] Building C object CMakeFiles/seqtest.dir/seqtest.c.o
Linking C executable seqtest
CMakeFiles/seqtest.dir/seqtest.c.o: In function `main':
seqtest.c:(.text+0x1f95): undefined reference to `strlcpy'
collect2: ld returned 1 exit status
make[2]: *** [seqtest] Error 1
make[1]: *** [CMakeFiles/seqtest.dir/all] Error 2
make: *** [all] Error 2

CLOCK_MONOTONIC_RAW is linux-specific

So:

``
--- seqtest.c.orig 2016-02-21 09:06:35 UTC
+++ seqtest.c
@@ -78,7 +78,11 @@ uint64_t
gethrtime(void)
{
struct timespec ts;
+#if defined(FreeBSD)

  •   if (clock_gettime(CLOCK_MONOTONIC, &ts) != 0) {
    
    +#else
    if (clock_gettime(CLOCK_MONOTONIC_RAW, &ts) != 0) {
    +#endif
    perror("clock_gettime");
    exit(1);
    }

Don't require C99

C99 requires special flags to enable on many compilers, and detecting those is a pain. So change the code to just use plain old ANSI C-90. The main difference here is use of declarations inside for loops. As nice as this is, the benefit isn't worth the portability cost. (Even though pretty much ~every compile supports C99, many require explicit flags to enable it.)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.