PacketLoss maybe negative about ping HOT 7 CLOSED

I think should filter previous response.if ping continuity ,the pre response can make the count of receive bigger than the count of send

from ping.

I am experiencing the same issue with concurrent uses of the Pinger, which makes it unusable... :/

from ping.

I can duplicate this by running in a goroutine.

go pinger.Run() causes negative PacketLoss for all checks, when running without the goroutine gives me sane values.

from ping.

This is an old issue, but I will answer it here anyway

This was happening to me just now. I was getting PacketLoss of -150%, or -175%.

But, after investigating a bit more, I found out that I was having this issue because I was running two (or more) ping processes. When I finally was aware of it, it was just a matter of killing all the processes and running only one to fix the issue.

I would guess the same would happen if many go routines (i.e. go pinger.Run()) are executed at the same time (independently whether pinger is the same instance or not).

A trick to find out if one process is interfering with another one is to check the icmp_seq value. For a valid result, they should follow a proper sequence, like this:

16 bytes from xxx.xx.x.xx: icmp_seq=0 time=13.322ms
16 bytes from xxx.xx.x.xx: icmp_seq=1 time=13.403ms
16 bytes from xxx.xx.x.xx: icmp_seq=2 time=13.43ms
16 bytes from xxx.xx.x.xx: icmp_seq=3 time=13.448ms
16 bytes from xxx.xx.x.xx: icmp_seq=4 time=14.291ms
16 bytes from xxx.xx.x.xx: icmp_seq=5 time=13.612ms
16 bytes from xxx.xx.x.xx: icmp_seq=6 time=13.352ms
16 bytes from xxx.xx.x.xx: icmp_seq=7 time=13.481ms

If you have two or more processes, the icmp_seq value will get scrambled:

16 bytes from xxx.xx.x.xx: icmp_seq=0 time=13.466ms
16 bytes from xxx.xx.x.xx: icmp_seq=1 time=13.458ms
16 bytes from xxx.xx.x.xx: icmp_seq=0 time=13.422ms
16 bytes from xxx.xx.x.xx: icmp_seq=2 time=13.516ms
16 bytes from xxx.xx.x.xx: icmp_seq=1 time=13.347ms
16 bytes from xxx.xx.x.xx: icmp_seq=3 time=13.346ms
16 bytes from xxx.xx.x.xx: icmp_seq=2 time=13.361ms
16 bytes from xxx.xx.x.xx: icmp_seq=4 time=13.532ms
16 bytes from xxx.xx.x.xx: icmp_seq=3 time=13.448ms
16 bytes from xxx.xx.x.xx: icmp_seq=5 time=13.404ms
16 bytes from xxx.xx.x.xx: icmp_seq=4 time=13.491ms
16 bytes from xxx.xx.x.xx: icmp_seq=6 time=13.488ms
16 bytes from xxx.xx.x.xx: icmp_seq=5 time=13.359ms

And then, of course, the result doesn't make sense:

9 packets transmitted, 16 packets received, -77.77777777777779% packet loss
round-trip min/avg/max/stddev = 13.346ms/13.438ms/13.532ms/63.213µs

Try to check if you are running two or more processes at the same time.

from ping.

After digging a bit into the code, this PR (#33) fix this issue as well.

from ping.

I believe this was actually fixed with #15, can anyone confirm that?

from ping.

@sparrc, the issue was partially fixed by #15. While the ID is being randomly assigned, there is no rand.Seed being given to the randomiser (fixed by #33).

Because there is no seed being given to the randomiser, rand.Intn(0xffff) will return the same sequence of numbers when executed in two separated processes. Because each process will be listening to responses from the same host, and under the same id, the calculations of one will interfere in the other.

from ping.