You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently omping only exits with non-0 status if there are problems with the command line.
When using -c or -T it seems like it should also exit with an error if either (a) it doesn't manage to communicate with a given host before the timeout, or (b) it manages to communicate with the host via unicast but not via multicast.
(I'm working on an end-to-end test of multicast connectivity between containers in OpenShift. omping is nice for this because omping -c 1 will exit quickly in the case where unicast works but multicast doesn't, rather than forcing us to guess an appropriate timeout.)
The text was updated successfully, but these errors were encountered:
(b) is little more problematic because building multicast tree can take a longer time and it's not unusual that first few multicast packets are lost. But I believe it's possible to use adjusted_loss and if it is 0, it's perfectly legal to return success.
Currently omping only exits with non-0 status if there are problems with the command line.
When using -c or -T it seems like it should also exit with an error if either (a) it doesn't manage to communicate with a given host before the timeout, or (b) it manages to communicate with the host via unicast but not via multicast.
(I'm working on an end-to-end test of multicast connectivity between containers in OpenShift. omping is nice for this because
omping -c 1
will exit quickly in the case where unicast works but multicast doesn't, rather than forcing us to guess an appropriate timeout.)The text was updated successfully, but these errors were encountered: