I'll just quote the whole code for the sending loop here:
while (1)
{
if (sentICMP > 0 && sentICMP % 100 == 0 && receivedICMP == 0) {
fprintf(stderr, "Warning: We've sent %lu packets, but received none.\n", sentICMP);
}
for (int i = 0; i < targets_len; i++)
{
switch (args->icmp_type) {
case 8:
send_icmp_echo_request(sock_fd, &targets[i], thread_data->id, htons(seq));
break;
case 13:
send_icmp_timestamp_request(sock_fd, &targets[i], thread_data->id, htons(seq));
break;
default:
fprintf(stderr, "sender: Invalid ICMP type: %u, exiting..\n", args->icmp_type);
pthread_exit(NULL);
}
if (args->target_spacing > 0 && args->targets_len > 1)
nanosleep(&spacing_time, NULL);
}
seq++;
if (args->sleep_time > 0)
nanosleep(&sleep_time, NULL);
}
I didn't consider this when I first wrote it, but this nanosleep(&spacing_time, NULL); should probably be skipped after the last target has been pinged, or?
Ah, stackoverflow has the answer for that one I believe:
Also, just wanted to mention that apparently in UNIX a newline will typically only flush the buffer if stdout is a terminal. If the output is being redirected to a file, a newline won't flush.
Didn't catch this since it works without a pipe, I guess buffering for stdout needs to be disabled entirely
That is really weird, and seems to only affect 9.9.9.10. I've neglected to use errno if something goes wrong when sending, so will add that as well so we can better see what it's complaining about
In looping or counting modes (−l, −c, or −C), this parameter sets the time in milliseconds that fping waits between successive packets to an individual target. Default is 1000 and minimum is 10.
−i, −−interval= MSEC
The minimum amount of time (in milliseconds) between sending a ping packet to any target (default is 10, minimum is 1).
As I understand it, this means that ${reflector_ping_interval_ms} separates ping sends to a particular target, and ${ping_response_interval_ms} separates ping sends to any target.
I think this system in fping probably is optimal. @patrakov do you agree?
Samples per reflector:
ReflectorID: 185.228.168.10; N: 91
ReflectorID: 185.228.168.9; N: 91
ReflectorID: 9.9.9.11; N: 90
ReflectorID: 9.9.9.9; N: 88
DL: maximum 95.000%-ile delta delay over all 4 reflectors: 18.670 ms.
DL: maximum 99.000%-ile delta delay over all 4 reflectors: 38.850 ms.
DL: maximum 99.500%-ile delta delay over all 4 reflectors: 38.850 ms.
DL: maximum 99.900%-ile delta delay over all 4 reflectors: 38.850 ms.
DL: maximum 99.950%-ile delta delay over all 4 reflectors: 38.850 ms.
DL: maximum 99.990%-ile delta delay over all 4 reflectors: 38.850 ms.
DL: maximum 99.999%-ile delta delay over all 4 reflectors: 38.850 ms.
UL: maximum 95.000%-ile delta delay over all 4 reflectors: 4.990 ms.
UL: maximum 99.000%-ile delta delay over all 4 reflectors: 11.985 ms.
UL: maximum 99.500%-ile delta delay over all 4 reflectors: 11.985 ms.
UL: maximum 99.900%-ile delta delay over all 4 reflectors: 11.985 ms.
UL: maximum 99.950%-ile delta delay over all 4 reflectors: 11.985 ms.
UL: maximum 99.990%-ile delta delay over all 4 reflectors: 11.985 ms.
UL: maximum 99.999%-ile delta delay over all 4 reflectors: 11.985 ms.
INFO: Writing plot as: ./output.timecourse.pdf
INFO: fn_parse_autorate_log took: 16.0685 seconds.
Not necessarily today, as the LTE link is good at night (20+ Mbps) and doesn't really need cake-autorate. And I won't have anything demanding (like Discord) until Wednesday.
Regarding mimicking fping options - yes I agree that it makes sense. That's assuming a sane interpretation of the timeout, in particular the case when it is greater than the period.
This will need testing and likely there will be one or two issues to iron out:
But it at least allowed me to produce the plot above using @Lochnair's tsping binary, which is available here:
and which includes support for ICMP type 13 (timestamp) requests and responses, and hence working with one way delays (OWDs) rather than round trip times (RTTs).
tsping is not yet an official OpenWrt package, but for anyone wanting to test there are simple instructions for building on OpenWrt here:
For any readers not sure about the significance of this, this facilitates determining the direction of bufferbloat (download or upload) and hence better control over the download and upload shaper rates since they can be controlled more independently in dependence upon the respective download and upload OWDs. Hitherto cake-autorate has fudged the issue by working with RTTs and erred on the side of caution.
Here is an example set of config overrides that work for my connection:
# tsping --help
Usage: tsping [OPTION...] IP1 IP2 IP3 ...
tsping -- a simple application to send ICMP echo/timestamp requests
-e, --icmp-echo Use ICMP echo requests
-t, --icmp-ts Use ICMP timestamp requests (default)
-r, --target-spacing=TIME Time to wait between pinging each target in ms
(default 0)
-s, --sleep-time=TIME Time to wait between each round of pinging in ms
(default 100)
-D, --print-timestamps Print UNIX timestamps for responses
-m, --machine-readable[=DELIMITER]
Output results in a machine readable format
-f, --fw-mark=MARK Firewall mark to set on outgoing packets
-i, --interface=INTERFACE Interface to bind to
-?, --help Give this help list
--usage Give a short usage message
Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
With the above, my understanding is that sleep-time 1000ms and target-spacing 500ms means: every 1000ms start round robin and send out first ICMP to first target, and then wait 500ms to send out interval to next target in that round robin.
That is, 1.5s and 500ms spacing between responses.
This is much clearer to me:
−p, −−period= MSEC
In looping or counting modes (−l, −c, or −C), this parameter sets the time in milliseconds that fping waits between successive packets to an individual target. Default is 1000 and minimum is 10.
−i, −−interval= MSEC
The minimum amount of time (in milliseconds) between sending a ping packet to any target (default is 10, minimum is 1).
Nope, with e.g. tow IPs, you will do:
probe1, 500ms, probe2, 1000ms
so your total period is 1500ms...
And that is what you see, 500ms between the members of the set (9.9.9.9's first response is missing)
9.9.9.9: 0
9.9.9.10: 500ms later
next round
9.9.9.9: 1000ms after 2), so exactly the requested sleep time.
Except you can specify stuff that fping does not complain about and does not deliver, period < interval...
My take is that you got used to fpings way of specifying this and hence confuse sleep with period, even though these are clearly different concepts. What like about @Lochnair's version is that you can not request impossible timings... it does become a tiny bit more involved to calculate the effective per reflector rate.
Ah, I think I get it now. So they are both spacings between sends. Target is the spacing between targets, and sleep is the spacing between rounds (i.e. the spacing between the last send and the next first send)?
