IRTT-CLIENT(1)

πŸ“¦
version 0.9.1 Β· 2 versions
, in fedora 43, fedora 44, ubuntu resolute, ubuntu stonking

πŸ’– IRTT-CLIENT(1) πŸ’–

okay so bestie, this is a page straight out of the IRTT Manual, and it's literally the client half of the whole irtt situation. grab a strawberry drink πŸ“, we're going in.


✨ NAME ✨

irtt-client β€” Isochronous Round-Trip Time Client πŸ¦‹


πŸŽ€ SYNOPSIS πŸŽ€

irtt client [args]

🌸 DESCRIPTION 🌸

irtt client is the client for irtt(1). that's it, that's the sentence, she's the one who calls up the server and starts the whole vibe. πŸ’…


πŸ‘‘ OPTIONS πŸ‘‘

  • -d duration β€” total time to send (default 1m0s, see Duration units down below bestie)
  • -i interval β€” send interval (default 1s, see Duration units below)
  • -l length β€” length of packet (default 0, and it gets increased as necessary for required headers). the common values, the ones you'll actually see in the wild:
    • 1472 β€” max unfragmented size of IPv4 datagram for 1500 byte MTU
    • 1452 β€” max unfragmented size of IPv6 datagram for 1500 byte MTU
  • -o file β€” write JSON output to file (use - for stdout, and note that output to stdout is not gzipped). the extension you pick for the file controls the gzip behavior like this:
    • no extension β†’ extension .json.gz is added, output is gzipped
    • .json.gz β†’ output is gzipped
    • .gz β†’ output is gzipped, extension changed to .json.gz
    • .json β†’ output is not gzipped
  • -q β€” quiet mode, suppress per-packet output 🀫
  • -Q β€” really quiet, suppress all output except errors to stderr 😢
  • -n β€” no test: connect to the server and validate test parameters but don't actually run the test. it's giving "rehearsal, not the show" πŸ™ˆ
  • --stats=stats β€” server stats on received packets (default both). possible values:
    • none β€” no server stats on received packets
    • count β€” total count of received packets
    • window β€” receipt status of last 64 packets with each reply
    • both β€” both count and window
  • --tstamp=mode β€” server timestamp mode (default both). possible values:
    • none β€” request no timestamps
    • send β€” request timestamp at server send
    • receive β€” request timestamp at server receive
    • both β€” request both send and receive timestamps
    • midpoint β€” request midpoint timestamp (send/receive avg)
  • --clock=clock β€” clock/s used for server timestamps (default both). possible values:
    • wall β€” wall clock only
    • monotonic β€” monotonic clock only
    • both β€” both clocks
  • --dscp=dscp β€” DSCP (ToS) value (default 0, and 0x prefix means hex). common values:
    • 0 β€” Best effort
    • 8 β€” CS1- Bulk
    • 40 β€” CS5- Video
    • 46 β€” EF- Expedited forwarding
DSCP & ToS reference: https://www.tucny.com/Home/dscp-tos πŸ”—
  • --df=DF β€” setting for do not fragment (DF) bit in all packets. possible values:
    • default β€” OS default
    • false β€” DF bit not set
    • true β€” DF bit set
  • --wait=wait β€” wait time at end of test for unreceived replies (default 3x4s). possible values:
    • #xduration β€” # times max RTT, or duration if no response
    • #rduration β€” # times RTT, or duration if no response
    • duration β€” fixed duration (see Duration units below)

examples, because examples slay:

  • 3x4s β€” 3 times max RTT, or 4 seconds if no response
  • 1500ms β€” fixed 1500 milliseconds
  • --timer=timer β€” timer for waiting to send packets (default comp). possible values:
    • simple β€” Go's standard time.Timer
    • comp β€” simple timer with error compensation (see -tcomp)
    • hybrid:# β€” hybrid comp/busy timer with sleep factor (default 0.95)
    • busy β€” busy wait loop (high precision and CPU, blasphemy πŸ’€)
  • --tcomp=alg β€” comp timer averaging algorithm (default exp:0.10). possible values:
    • avg β€” cumulative average error
    • win:# β€” moving average error with window # (default 5)
    • exp:# β€” exponential average with alpha # (default 0.10)
  • --fill=fill β€” fill payload with given data (default none). possible values:
    • none β€” leave payload as all zeroes
    • rand β€” use random bytes from Go's math.rand
    • pattern:XX β€” use repeating pattern of hex (default 69727474)
  • --fill-one β€” fill only once and repeat for all packets πŸ”
  • --sfill=fill β€” request server fill (default not specified). see the values for --fill. the server must support and allow this fill with --allow-fills.
  • --local=addr β€” local address (default from OS). possible values:
    • :port β€” unspecified address (all IPv4/IPv6 addresses) with port
    • host β€” host with dynamic port, see Host formats below
    • host:port β€” host with specified port, see Host formats below
  • --hmac=key β€” add HMAC with key (0x for hex) to all packets. it provides:
    • dropping of all packets without a correct HMAC
    • protection for the server against unauthorized discovery and use πŸ”
  • -4 β€” IPv4 only
  • -6 β€” IPv6 only
  • --timeouts=durations β€” timeouts used when connecting to server (default 1s,2s,4s,8s). it's a comma separated list of durations (see Duration units below). total wait time will be up to the sum of these durations. max packets sent is up to the number of durations. minimum timeout duration is 200ms.
  • --ttl=ttl β€” time to live (default 0, meaning use OS default)
  • --loose β€” accept and use any server restricted test parameters instead of exiting with nonzero status. chill vibes only 🧘
  • --thread β€” lock sending and receiving goroutines to OS threads
  • -h β€” show help
  • -v β€” show version

πŸ¦‹ Host formats πŸ¦‹

hosts may be either hostnames (for IPv4 or IPv6) or IP addresses. IPv6 addresses must be surrounded by brackets and may include a zone after the % character. examples, bestie:

  • IPv4 IP β†’ 192.168.1.10
  • IPv6 IP β†’ [2001:db8:8f::2/32]
  • IPv4/6 hostname β†’ localhost
note: IPv6 addresses must be quoted in most shells. no cap, your shell will simply not get it otherwise. 😭

⏳ Duration units ⏳

durations are a sequence of decimal numbers, each with optional fraction, and unit suffix, like "300ms", "1m30s" or "2.5m". sanity not enforced πŸ’€.

  • h β€” hours
  • m β€” minutes
  • s β€” seconds
  • ms β€” milliseconds
  • ns β€” nanoseconds

🌈 OUTPUT 🌈

IRTT's JSON output format consists of five top-level objects:

  1. version
  2. system_info
  3. config
  4. stats
  5. round_trips

these are documented through the examples below. all attributes are present unless otherwise noted. πŸ“


⭐ version ⭐

version information:

"version": {
    "irtt": "0.9.0",
    "protocol": 1,
    "json_format": 1
},
  • irtt β€” the IRTT version number
  • protocol β€” the protocol version number (increments mean incompatible changes)
  • json_format β€” the JSON format number (increments mean incompatible changes)

⭐ system_info ⭐

a few basic pieces of system information:

"system_info": {
    "os": "darwin",
    "cpus": 8,
    "go_version": "go1.9.2",
    "hostname": "tron.local"
},
  • os β€” the Operating System from Go's runtime.GOOS
  • cpus β€” the number of CPUs reported by Go's runtime.NumCPU(), which reflects the number of logical rather than physical CPUs. in the example below, the number 8 is reported for a Core i7 (quad core) with hyperthreading (2 threads per core).
  • go_version β€” the version of Go the executable was built with
  • hostname β€” the local hostname

⭐ config ⭐

the configuration used for the test

okay so the config object in the JSON output is giving full detail realness, and it looks like this:

              "config": {
                  "local_address": "127.0.0.1:51203",
                  "remote_address": "127.0.0.1:2112",
                  "open_timeouts": "1s,2s,4s,8s",
                  "params": {
                      "proto_version": 1,
                      "duration": 600000000,
                      "interval": 200000000,
                      "length": 48,
                      "received_stats": "both",
                      "stamp_at": "both",
                      "clock": "both",
                      "dscp": 0,
                      "server_fill": ""
                  },
                  "loose": false,
                  "ip_version": "IPv4",
                  "df": 0,
                  "ttl": 0,
                  "timer": "comp",
                  "waiter": "3x4s",
                  "filler": "none",
                  "fill_one": false,
                  "thread_lock": false,
                  "supplied": {
                      "local_address": ":0",
                      "remote_address": "localhost",
                      "open_timeouts": "1s,2s,4s,8s",
                      "params": {
                          "proto_version": 1,
                          "duration": 600000000,
                          "interval": 200000000,
                          "length": 0,
                          "received_stats": "both",
                          "stamp_at": "both",
                          "clock": "both",
                          "dscp": 0,
                          "server_fill": ""
                      },
                      "loose": false,
                      "ip_version": "IPv4+6",
                      "df": 0,
                      "ttl": 0,
                      "timer": "comp",
                      "waiter": "3x4s",
                      "filler": "none",
                      "fill_one": false,
                      "thread_lock": false
                  }
              },
  • local_address β€” the local address (IP:port) for the client πŸ’…
  • remote_address β€” the remote address (IP:port) for the server 🌐
  • open_timeouts β€” a list of timeout durations used after an open packet is sent ⏳
  • params β€” the parameters that were negotiated with the server, including:
    • proto_version β€” protocol version number πŸ”’
    • duration β€” duration of the test, in nanoseconds ⏱️
    • interval β€” send interval, in nanoseconds ⏲️
    • length β€” packet length πŸ“
    • received_stats β€” statistics for packets received by server (none, count, window or both, --stats flag for irtt client) πŸ“Š
    • stamp_at β€” timestamp selection parameter (none, send, receive, both or midpoint, --tstamp flag for irtt client) πŸ•°οΈ
    • clock β€” clock selection parameter (wall or monotonic, --clock flag for irtt client) πŸ•°οΈ
    • dscp β€” the DSCP (https://en.wikipedia.org/wiki/Differentiated_services) value 🎚️
    • server_fill β€” the requested server fill (--sfill flag for irtt client) 🧺
  • loose β€” if true, client accepts and uses restricted server parameters, with a warning ⚠️
  • ip_version β€” the IP version used (IPv4 or IPv6) 🌐
  • df β€” the do-not-fragment setting (0 == OS default, 1 == false, 2 == true) 🧩
  • ttl β€” the IP time-to-live (https://en.wikipedia.org/wiki/Time_to_live) value ⏳
  • timer β€” the timer used: simple, comp, hybrid or busy (irtt client --timer flag) ⏱️
  • time_source β€” the time source used: go or windows πŸ–₯️
  • waiter β€” the waiter used: fixed duration, multiple of RTT or multiple of max RTT (irtt client --wait flag) ⏳
  • filler β€” the packet filler used: none, rand or pattern (irtt client --fill flag) 🎨
  • fill_one β€” whether to fill only once and repeat for all packets (irtt client --fill-one flag) 1️⃣
  • thread_lock β€” whether to lock packet handling goroutines to OS threads πŸ”’
  • supplied β€” a nested config object with the configuration as originally supplied to the API or irtt command. The supplied configuration can differ from the final configuration in the following ways:
    • local_address and remote_address may have hostnames or named ports before being resolved to an IP and numbered port 🏷️
    • ip_version may be IPv4+6 before it is determined after address resolution 🌐
    • params may be different before the server applies restrictions based on its configuration πŸ› οΈ

stats πŸ’…

and the stats object is where the receipts live. It's literally statistics for the results:

              "stats": {
                  "start_time": {
                      "wall": 1528621979787034330,
                      "monotonic": 5136247
                  },
                  "send_call": {
                      "total": 79547,
                      "n": 3,
                      "min": 17790,
                      "max": 33926,
                      "mean": 26515,
                      "stddev": 8148,
                      "variance": 66390200
                  },
                  "timer_error": {
                      "total": 227261,
                      "n": 2,
                      "min": 59003,
                      "max": 168258,
                      "mean": 113630,
                      "stddev": 77254,
                      "variance": 5968327512
                  },
                  "rtt": {
                      "total": 233915,
                      "n": 2,
                      "min": 99455,
                      "max": 134460,
                      "mean": 116957,
                      "median": 116957,
                      "stddev": 24752,
                      "variance": 612675012
                  },
                  "send_delay": {
                      "total": 143470,
                      "n": 2,
                      "min": 54187,
                      "max": 89283,
                      "mean": 71735,
                      "median": 71735,
                      "stddev": 24816,
                      "variance": 615864608
                  },
                  "receive_delay": {
                      "total": 90445,
                      "n": 2,
                      "min": 45177,
                      "max": 45268,
                      "mean": 45222,
                      "median": 45222,
                      "stddev": 64,
                      "variance": 4140
                  },
                  "server_packets_received": 2,
                  "bytes_sent": 144,
                  "bytes_received": 96,
                  "duplicates": 0,
                  "late_packets": 0,
                  "wait": 403380,
                  "duration": 400964028,
                  "packets_sent": 3,
                  "packets_received": 2,
                  "packet_loss_percent": 33.333333333333336,
                  "upstream_loss_percent": 33.333333333333336,
                  "downstream_loss_percent": 0,
                  "duplicate_percent": 0,
                  "late_packets_percent": 0,
                  "ipdv_send": {
                      "total": 35096,
                      "n": 1,
                      "min": 35096,
                      "max": 35096,
                      "mean": 35096,
                      "median": 35096,
                      "stddev": 0,
                      "variance": 0
                  },
                  "ipdv_receive": {
                      "total": 91,
                      "n": 1,
                      "min": 91,
                      "max": 91,
                      "mean": 91,
                      "median": 91,
                      "stddev": 0,
                      "variance": 0
                  },
                  "ipdv_round_trip": {
                      "total": 35005,
                      "n": 1,
                      "min": 35005,
                      "max": 35005,
                      "mean": 35005,
                      "median": 35005,
                      "stddev": 0,
                      "variance": 0
                  },
                  "server_processing_time": {
                      "total": 20931,
                      "n": 2,
                      "min": 9979,
                      "max": 10952,
                      "mean": 10465,
                      "stddev": 688,
                      "variance": 473364
                  },
                  "timer_err_percent": 0.056815,
                  "timer_misses": 0,
                  "timer_miss_percent": 0,
                  "send_rate": {
                      "bps": 2878,
                      "string": "2.9 Kbps"
                  },
                  "receive_rate": {
                      "bps": 3839,
                      "string": "3.8 Kbps"
                  }
              },

Note: In the stats object, a duration stats class of object repeats and will not be repeated in the individual descriptions. It contains statistics about nanosecond duration values and has the following attributes:

  • total β€” the total of the duration values
  • n β€” the number of duration values
  • min β€” the minimum duration value
  • max β€” the maximum duration value
  • mean β€” the mean duration value
  • stddev β€” the standard deviation
  • variance β€” the variance

The regular attributes in stats are as follows:

  • start_time β€” the start time of the test (see round_trips Notes for descriptions of wall and monotonic values)
  • send_call β€” a duration stats object for the call time when sending packets
  • timer_error β€” a duration stats object for the observed sleep time error
  • rtt β€” a duration stats object for the round-trip time
  • send_delay β€” a duration stats object for the one-way send delay (only available if server timestamps are enabled)
  • receive_delay β€” a duration stats object for the one-way receive delay (only available if server timestamps are enabled)
  • server_packets_received β€” the number of packets received by the server, including duplicates (always present, but only valid if the ReceivedStats parameter includes ReceivedStatsCount, or the --stats flag to the irtt client is count or both)
  • bytes_sent β€” the number of UDP payload bytes sent during the test
  • bytes_received β€” the number of UDP payload bytes received during the test
  • duplicates β€” the number of packets received with the same sequence number
  • late_packets β€” the number of packets received with a sequence number lower than the previously received sequence number (one simple metric for out-of-order packets)
  • wait β€” the actual time spent waiting for final packets, in nanoseconds
  • duration β€” the actual duration of the test, in nanoseconds, from the time just before the first packet was sent to the time after the last packet was received and results are starting to be calculated
  • packets_sent β€” the number of packets sent to the server
  • packets_received β€” the number of packets received from the server
  • packet_loss_percent β€” 100 * (packets_sent - packets_received) / packets_sent
  • upstream_loss_percent β€” 100 * (packets_sent - server_packets_received / packets_sent) (always present, but only valid if server_packets_received is valid)
  • downstream_loss_percent β€” 100 * (server_packets_received - packets_received / server_packets_received) (always present, but only valid if server_packets_received is valid)
  • duplicate_percent β€” 100 * duplicates / packets_received
  • late_packets_percent β€” 100 * late_packets / packets_received
  • ipdv_send β€” a duration stats object for the send IPDV (https://en.wikipedia.org/wiki/Packet_delay_variation). Only shows up if server timestamps are on, bestie. ✨
  • ipdv_receive β€” a duration stats object for the receive IPDV (https://en.wikipedia.org/wiki/Packet_delay_variation). Same deal, server timestamps must be enabled.
  • ipdv_round_trip β€” a duration stats object for the round-trip IPDV (https://en.wikipedia.org/wiki/Packet_delay_variation). This one's available no matter what β€” server timestamps on or off, she's there. πŸ’…
  • server_processing_time β€” a duration stats object for the time the server took after it received the packet to when it sent the response. Only available when both send and receive timestamps are enabled.
  • timer_err_percent β€” the mean of the absolute values of the timer error, as a percentage of the interval. Math! ✨
  • timer_misses β€” the number of times the timer missed the interval (was at least 50% over the scheduled time). oof
  • timer_miss_percent β€” 100 * timer_misses / expected packets sent
  • send_rate β€” the send bitrate (bits-per-second and a corresponding string), calculated using the number of UDP payload bytes sent between the time right before the first send call and the time right after the last send call. πŸš€
  • receive_rate β€” the receive bitrate (bits-per-second and a corresponding string), calculated using the number of UDP payload bytes received between the time right after the first receive call and the time right after the last receive call. πŸ›¬

πŸ¦‹ round_trips πŸ¦‹

okay so each round-trip is a single request to / reply from the server. like, one little conversation. here's what it looks like:

"round_trips": [
    {
        "seqno": 0,
        "lost": false,
        "timestamps": {
            "client": {
                "receive": {
                    "wall": 1508180723502871779,
                    "monotonic": 2921143
                },
                "send": {
                    "wall": 1508180723502727340,
                    "monotonic": 2776704
                }
            },
            "server": {
                "receive": {
                    "wall": 1508180723502816623,
                    "monotonic": 32644353327
                },
                "send": {
                    "wall": 1508180723502826602,
                    "monotonic": 32644363306
                }
            }
        },
        "delay": {
            "receive": 45177,
            "rtt": 134460,
            "send": 89283
        },
        "ipdv": {}
    },
    {
        "seqno": 1,
        "lost": false,
        "timestamps": {
            "client": {
                "receive": {
                    "wall": 1508180723702917735,
                    "monotonic": 202967099
                },
                "send": {
                    "wall": 1508180723702807328,
                    "monotonic": 202856692
                }
            },
            "server": {
                "receive": {
                    "wall": 1508180723702861515,
                    "monotonic": 32844398219
                },
                "send": {
                    "wall": 1508180723702872467,
                    "monotonic": 32844409171
                }
            }
        },
        "delay": {
            "receive": 45268,
            "rtt": 99455,
            "send": 54187
        },
        "ipdv": {
            "receive": 91,
            "rtt": -35005,
            "send": -35096
        }
    },
    {
        "seqno": 2,
        "lost": true,
        "timestamps": {
            "client": {
                "receive": {},
                "send": {
                    "wall": 1508180723902925971,
                    "monotonic": 402975335
                }
            },
            "server": {
                "receive": {},
                "send": {}
            }
        },
        "delay": {},
        "ipdv": {}
    }
]
Note: wall values are from Go's time.Time.UnixNano(), the number of nanoseconds elapsed since January 1, 1970 UTC. πŸ•°οΈ
Note: monotonic values are the number of nanoseconds since some arbitrary point in time, so can only be relied on to measure duration. no cap, don't use them as a clock fr fr.

  • seqno β€” the sequence number. πŸ”’
  • lost β€” the lost status of the packet, which can be one of false, true, true_down or true_up. The true_down and true_up values are only possible if the ReceivedStats parameter includes ReceivedStatsWindow (irtt client --stats flag). Even then, if it could not be determined whether the packet was lost upstream or downstream, the value true is used. πŸ’€
  • timestamps β€” the client and server timestamps.
    • client β€” the client send and receive wall and monotonic timestamps (receive values only present if lost is false).
    • server β€” the server send and receive wall and monotonic timestamps (both send and receive values not present if lost is true), and additionally:
      • send values are not present if the StampAt (irtt client --tstamp flag) does not include send timestamps.
      • receive values are not present if the StampAt (irtt client --tstamp flag) does not include receive timestamps.
      • wall values are not present if the Clock (irtt client --clock flag) does not include wall values or server timestamps are not enabled.
      • monotonic values are not present if the Clock (irtt client --clock flag) does not include monotonic values or server timestamps are not enabled.
  • delay β€” an object containing the delay values.
    • receive β€” the one-way receive delay, in nanoseconds (present only if server timestamps are enabled and at least one wall clock value is available).
    • rtt β€” the round-trip time, in nanoseconds, always present. πŸ‘‘
    • send β€” the one-way send delay, in nanoseconds (present only if server timestamps are enabled and at least one wall clock value is available).
  • ipdv β€” an object containing the IPDV (https://en.wikipedia.org/wiki/Packet_delay_variation) values (attributes present only for seqno > 0, and if lost is false for both the current and previous round_trip).
    • receive β€” the difference in receive delay relative to the previous packet (present only if at least one server timestamp is available).
    • rtt β€” the difference in round-trip time relative to the previous packet (always present for seqno > 0).
    • send β€” the difference in send delay relative to the previous packet (present only if at least one server timestamp is available).

✨ EXIT STATUS ✨

irtt client exits with one of the following status codes, bestie β€” memorize these, they're your vibe check:

  • 0 β€” Success πŸŽ‰
  • 1 β€” Runtime error 😭
  • 2 β€” Command line error πŸ™ˆ
  • 3 β€” Two interrupt signals received πŸ’€

🚨 WARNINGS 🚨

okay so listen. it is possible with the irtt client to dramatically harm network performance by using intervals that are too low, particularly in combination with large packet lengths. Careful consideration should be given before using sub-millisecond intervals, not only because of the impact on the network, but also because:

  • Timer accuracy at sub-millisecond intervals may begin to suffer without the use of a custom kernel or the busy timer (which pins the CPU). 😳
  • Memory consumption for results storage and system CPU time both rise rapidly. πŸ“ˆ
  • The granularity of the results reported may very well not be required. like, maybe you don't need it?? just saying.
fr fr be careful with this one. sub-millisecond intervals are not a casual decision. πŸ’…

🌈 EXAMPLES 🌈

$ irtt client localhost

Sends requests once per second for one minute to localhost. easy peasy. ✨

$ irtt client -i 200ms -d 10s -o - localhost

Sends requests every 0.2 sec for 10 seconds to localhost. Writes JSON output to stdout. πŸŽ€

$ irtt client -i 20ms -d 1m -l 172 --fill=rand --sfill=rand 192.168.100.10

Sends requests every 20ms for one minute to 192.168.100.10. Fills both the client and server payload with random data. This simulates a G.711 VoIP conversation, one of the most commonly used codecs for VoIP as of this writing. ☎️ iconic honestly.

$ irtt client -i 0.1s -d 5s -6 --dscp=46 irtt.example.org

Sends requests with IPv6 every 100ms for 5 seconds to irtt.example.org. Sets the DSCP value (ToS field) of requests and responses to 46 (Expedited Forwarding). 🚦

$ irtt client --hmac=secret -d 10s "[2001:db8:8f::2/32]:64381"

Sends requests to the specified IPv6 IP on port 64381 every second for 10 seconds. Adds an HMAC to each packet with the key secret. πŸ”


🫢 SEE ALSO 🫢


and that's the whole page, bestie!! πŸ’– this is v0.9.0, dated February 11, 2018, and the man page itself is IRTT-CLIENT(1). go forth and measure your packets, you absolute icon. πŸ‘‘πŸŒΈ

πŸ“¦ where this page comes from