CHTJonas
commented
3 years ago Thanks for this! We are aware of this particular Timeout 'peculiarity' -- in some ways it's a sort of feature and not a bug but I get that if you come from the perspective of /bin/ping then it doesn't behave as you expect.
This is a dupe of #63 so I'll close in favour of that ticket which was opened first.
I wonder current interval and timeout mechanism is final or not.
Current mechanism is to send packet every interval and repeat the set counts. For example, 100ms interval, 100 counts ,1000000ms timeout. It works like in the period of 10s(100*100ms = 10s), send 100 packet, and then see how many packets can be received.
In this case, timeout is waiting for all the counts over which no use at most of the test cases. It's not for one count. It couldn't show the network immediately. Interval triggerd in current mechanism will send another packet no extra condition. It's more like timeout than interval.The major problem is when the server responses slower than interval, it still send another packet whicht would cause more lost.(see the pictures below)
If set the interval to 1s, in this case , it will work more accurate but will be too slow. This way cannot pick the slow but stable sever.
So I want to make it less influence to server(don't send too much before received) and more faster.
In my opinion, timeout is for each count. If set a timeout for 1000ms, When triggered , It means the server hasn't responsed in 1000ms, I can know it has pool network and treat this count as a lost. Interval triggered, I will check the last packet has received or not. Yes: Send another packet; No: skip this interval; Received triggered,I will check the usetime, if usetime > interval, send at once else Sleep for (interval - passtime).See(flow chart)
The comparison is in the case of : params: 50 servers,100ms , 200 count. First is the original, Second is the modify. (I use this to ping vpn servers seeing which is the most fast and stable)
The result is that : new way has less loss. It may be more accurate and clear. Also the cpu occupied needs to be improve as I said yesterday.
The last View, I can see after 200packet sent ,which one is better or more stable.
