yixing1337

no, the results based on the current solutions are not ideal. Most of the rtt obtained by ping LAN machines will be twice the delay detected by directly using the ping command, and sometimes it will be much higher. So, i think maybe native implementation is the better way to solve this problem. Thank you very much for your enthusiastic answers and help

no, the results based on the current solutions are not ideal. Most of the rtt obtained by ping LAN machines will be twice the delay detected by directly using the ping command, and sometimes it will be much higher. So, native implementation is the better way to solve this problem. Thank you very much for your enthusiastic answers and help

Indeed, this solution does add additional time overhead, and will introduce additional deviations in detecting the network status between machines. We are preparing to do network monitoring between machines, so the ping delay is best calculated in native.

For the reasons you said, using nanoseconds seems to be an easier solution to this problem. I agree with it. When is this problem expected to be fixed?

thanks！ I use the implementation class UnixJniNativeBridge in the project。Another suggestion is whether to consider modifying the data type? It may be the data type used is causing this problem

thanks！ I use the implementation class UnixJniNativeBridge in the project。Another suggestion is whether to consider modifying the data type? It may be the data type used is causing this problem

When running icmp4j on Linux, pinging a LAN machine, the round trip delay rtt less than 1 millisecond will be displayed as 0. We guess that the data type of the rtt field in the Icmp4jJNI class is an integer, which causes the data to be rounded. How to deal with it？