Closed b-reich closed 2 years ago
Maybe its related on the ping_deadline option
-c count
Stop after sending count ECHO_REQUEST packets. With deadline option, ping waits for count ECHO_REPLY packets, until the timeout expires.
-w deadline
Specify a timeout, in seconds, before ping exits regardless of how many packets have been sent or received. In this case ping does not stop after count packet are sent, it waits either for deadline expire or until count probes are answered or for some error notification from network.
I guess that is the problem here. Fixing.
Do you have any idea how?
I have just pushed a fix. Not sure if this is the appropiate fix, as errors packets are received, but then, it is probably send from the local IP stack.
@b-reich please have a look.
I will it run over night. Thanks @mwarning
I just noticed that the problem is not entirely fixed, yet.
I looks good now.
I just update and test it.
Looks good to me. How is it for you?
I have to run the latest push again.
Traceback (most recent call last):
File "./benchmark.py", line 93, in <module>
run(protocol, csvfile)
File "./benchmark.py", line 69, in run
ping_deadline=30,
File "../../ping.py", line 470, in ping
process_results()
File "../../ping.py", line 417, in process_results
_parse_ping(result, output.decode())
File "../../ping.py", line 352, in _parse_ping
result.packet_loss = int(toks[2])
ValueError: invalid literal for int() with base 10: '87.5'
casting to int is a problem
I see. Thank you. Should be fixed now.
Those are packet counters/integers
Traceback (most recent call last):
File "./benchmark.py", line 93, in <module>
run(protocol, csvfile)
File "./benchmark.py", line 69, in run
ping_deadline=30,
File "../../ping.py", line 510, in ping
success_pc = 100.0 * (ret.received / ret.send)
ZeroDivisionError: division by zero
That is easy to fix as well. It seems you call these methods with all kinds of input. :P
I take my job as a tester very seriously :D
I start a new run.
@mwarning thanks for fixing. I am closing this. Everything seems to work .
[066:001972] ping 18 => 3 (fdef:17a0:ffb1:300:f89f:d6ff:fe13:2651 / uplink) => running
[067:002005] ping 79 => 23 (fdef:17a0:ffb1:300:d02b:3dff:feb5:ff1 / uplink) => running
[068:002034] ping 75 => 22 (fdef:17a0:ffb1:300:e8ed:c4ff:fe4c:b88b / uplink) => running
[069:002063] ping 86 => 61 (fdef:17a0:ffb1:300:7c15:dbff:fed3:c2fc / uplink) => running
[070:002093] ping 79 => 11 (fdef:17a0:ffb1:300:a44d:dff:fee6:bf21 / uplink) => running
[071:002126] ping 93 => 54 (fdef:17a0:ffb1:300:cc53:28ff:fe76:7660 / uplink) => running
[072:002156] ping 36 => 34 (fdef:17a0:ffb1:300:a483:c9ff:fe13:befb / uplink) => running
[073:002185] ping 66 => 56 (fdef:17a0:ffb1:300:3cca:83ff:feca:80f3 / uplink) => running
[074:002215] ping 60 => 32 (fdef:17a0:ffb1:300:a0b1:67ff:fe1a:5d30 / uplink) => running
[075:002245] ping 62 => 38 (fdef:17a0:ffb1:300:d074:6bff:fefb:87e2 / uplink) => running
[076:002274] ping 53 => 2 (fdef:17a0:ffb1:300:b0e0:aeff:fe19:afb9 / uplink) => running
[077:002307] ping 85 => 76 (fdef:17a0:ffb1:300:48c1:7cff:fe5e:4c8e / uplink) => running
[078:002337] ping 95 => 24 (fdef:17a0:ffb1:300:4413:e6ff:fee5:b670 / uplink) => running
[079:002367] ping 82 => 5 (fdef:17a0:ffb1:300:1822:bcff:fe5b:c418 / uplink) => running
[080:002396] ping 94 => 68 (fdef:17a0:ffb1:300:e8b8:10ff:fe86:c159 / uplink) => running
[081:002429] ping 78 => 2 (fdef:17a0:ffb1:300:b0e0:aeff:fe19:afb9 / uplink) => running
[082:002459] ping 87 => 45 (fdef:17a0:ffb1:300:d80f:2ff:fe7e:5c68 / uplink) => running
[083:002489] ping 91 => 62 (fdef:17a0:ffb1:300:74ce:14ff:fe8b:318a / uplink) => running
[084:002519] ping 40 => 6 (fdef:17a0:ffb1:300:b0df:22ff:fe41:65ac / uplink) => running
[085:002549] ping 12 => 8 (fdef:17a0:ffb1:300:c0e2:35ff:fe39:7586 / uplink) => running
[086:002579] ping 72 => 0 (fdef:17a0:ffb1:300:f0d4:35ff:fe42:46b3 / uplink) => running
[087:002608] ping 80 => 33 (fdef:17a0:ffb1:300:6c01:39ff:feba:e32f / uplink) => running
[088:002641] ping 64 => 57 (fdef:17a0:ffb1:300:a03e:aff:fed8:4600 / uplink) => running
[089:002670] ping 44 => 12 (fdef:17a0:ffb1:300:3884:40ff:fede:913b / uplink) => running
[090:002700] ping 55 => 8 (fdef:17a0:ffb1:300:c0e2:35ff:fe39:7586 / uplink) => running
[091:002729] ping 63 => 7 (fdef:17a0:ffb1:300:c433:14ff:fe31:4055 / uplink) => running
[092:002762] ping 85 => 63 (fdef:17a0:ffb1:300:a440:e4ff:fe61:f279 / uplink) => running
[093:002791] ping 65 => 21 (fdef:17a0:ffb1:300:6c2e:aff:fee4:c45e / uplink) => running
[094:002821] ping 73 => 15 (fdef:17a0:ffb1:300:ec82:36ff:fe55:a541 / uplink) => running
[095:002850] ping 66 => 63 (fdef:17a0:ffb1:300:a440:e4ff:fe61:f279 / uplink) => running
[096:002883] ping 65 => 48 (fdef:17a0:ffb1:300:e864:1fff:fe02:e274 / uplink) => running
[097:002912] ping 83 => 77 (fdef:17a0:ffb1:300:9c7e:9eff:fe85:fc40 / uplink) => running
[098:002942] ping 56 => 26 (fdef:17a0:ffb1:300:e899:26ff:fe24:844b / uplink) => running
[099:002971] ping 87 => 47 (fdef:17a0:ffb1:300:5896:7dff:feb6:5ac3 / uplink) => running
pings send: 1, received: 1 (100.00%), measurement span: 3000ms
I think this behaviour is a bit odd,
pings send: 1, received: 1 (100.00%), measurement span: 3000ms
huh, how did you do that? :D
@mwarning
ping_result = ping.ping(
paths=paths,
duration_ms=3000,
verbosity="verbose",
remotes=remotes,
# ping_deadline=1,
address_type="6",
)
I understand, the pings have not finished yet. You see that all pings are still in the state of running (except one probably). We should include the number of pings that have not finished by the end of the measurement period.
hm, better we count unfinished pings as not received. This is a two line fix. I will push it when we are done with your merge request. :)
Forget this please... I did something stupid... Have a bad and confussing day.... Sorry @mwarning
@mwarning # Shouldn't we also count on which nodes the ping has arrived (or not) ping 4 => 8 => success ping 5 => 9 => failed 1 of 2 successfull
Isn't that what we are doing now?
Note: for e.g. batman-adv it takes about 30 seconds before any ping will arrive.
hah, I forgot to properly add the number of pings send.
still have this issue
[093:003721] ping 68 => 25 (fdef:17a0:ffb1:300:e004:74ff:fec8:680b / uplink) => success
[094:003760] ping 39 => 12 (fdef:17a0:ffb1:300:dc11:3ff:fe30:8563 / uplink) => success
[095:003802] ping 99 => 60 (fdef:17a0:ffb1:300:8cc7:b2ff:fe78:b5ab / uplink) => success
[096:003841] ping 65 => 37 (fdef:17a0:ffb1:300:90bc:47ff:fe4f:c2ed / uplink) => success
[097:003884] ping 73 => 15 (fdef:17a0:ffb1:300:c4c6:7cff:fe9a:ba64 / uplink) => running
[098:003922] ping 80 => 74 (fdef:17a0:ffb1:300:7c22:b7ff:fe7d:5ce5 / uplink) => success
[099:003964] ping 61 => 2 (fdef:17a0:ffb1:300:b4d2:d1ff:fe87:86f6 / uplink) => running
pings send: 97, received: 97 (100.00%), measurement span: 4000ms
ping_result = ping.ping(
paths=paths,
duration_ms=4000,
verbosity="verbose",
remotes=remotes,
ping_deadline=15,
address_type="6",
)
there should be 99 Pings.
I cannot reproduce this. Have you this in your code? https://github.com/mwarning/meshnet-lab/commit/49783cf9f5e291847f90923c65a1ae13110ada90
I will rerun it. But pretty sure it was the latest version. Maybe it relay on the hop limit on the various protocols. I found some limits there . This happens with babel und line topolgy with 100 nodes.
There are some Bugs in the _parse_ping
I could not quite understand where the problem is. The following example use Batman-adv
I use these ping parameters:
Maybe because one of the outputs was like that. (I have logged all outputs once)