Thank you for your changes! I stumbled over one more thing: it is possible that the delta value is greather than tm._tick_timeout, which would result in a negative tm._select_timeout value. I used the edits in line 107 as a fix:

tm._select_timeout = std::max(0.0,tm._select_timeout);

(file #49707)

As we have discussed, the same behavior exists in the service tick(min,max) in HLA 1.3. Unfortunately, JCERTI does not work with HLA 1516 and so Ptolemy (written in Java) must stick with HLA 1.3.

The code in RTIamServices.hh says:
/**

• Evoke multiple callbacks (HLA1.3).
• Blocks up to "minimum" seconds until a callback delivery, then evokes
• multiple callbacks until no callback is pending, or until "maximum"
• duration is reached.
• @param[in] minimum the minimum amount of time spent in the tick call.
• @param[in] maximum the maximum amount of time spent in the tick call.
• @return true if additional callbacks pending, false otherwise

 */
Boolean tick(TickTime minimum, TickTime maximum)
    throw (SpecifiedSaveLabelDoesNotExist, ConcurrentAccessAttempted, RTIinternalError);

The environement Ptolemy-HLA was commited yesterday replacing tick() and tick2() by tick((MAX_BLOCKING_TIME, 0). For the moment, MAX_BLOCKING_TIME=1s. All tests pass and a federation syncrhnozed with the computer clock (at 1s) works fine. Here the way Ptolemy is using tick(min,max):

        while (!(_federateAmbassador.timeAdvanceGrant)) {
                // Wait for a callback. This will return immediately if there
                // is already a callback pending. If there is no callback pending, it will
                // wait up to MAX_BLOCKING_TIME and then return even if there is
                // no callback.
                // NOTE: The second argument, which the API confusingly calls "max"
                // but is usually less than "min", appears to not be used in the C++ code.
                _rtia.tick(MAX_BLOCKING_TIME, 0); 
        }