Limegarden.net Personal site of Wouter Lindenhof

Precision, precision…

One of the things I have been writing for Flexposure is the RAPI which is short for Remote API. The RAPI (which you should mispronounce when you are among the opposite sex) is nothing more than a thin communication layer which can be used on virtual any other protocol like UDP and TCP but also on some industrial standards which are used by hardware (even my worst enemy: RS232 AKA comport).

Even though I'm not racist I hate the diversity of compilers and OS so I decided to use Boost for all the timing relevant functions. Within boost you have two types of clock:

1. boost::posix::second_clock
2. boost::posix::microsec_clock

Thinking which one I wanted I decided not to go for the high-performance clock. I only want to know if a message had timed out and if I should send another one.

A basic example of the code would be this:

class SendTask : public IClientTask
{
public:
    SendTask()
        : m_SendTimestamp(boost::posix::second_clock::universal_time())
        , m_SendInterval(boost::posix::seconds(1))
    {

    }
    void Tick()
    {
        auto currentTime = boost::poxix::second_clock::universal_time();

        bool sendAgain = m_SendTimestamp < currentTime;
        if(sendAgain)
        {
            // ...
            // Send message again
            // ...

            // Increase the next timestamp.
            m_SendTimestamp = currentTime + m_SendInterval;
        }
    }

private:
    boost::posix::ptime m_SendTimestamp;

    // The default delay is one second (decided by constructor)
    boost::posix::time_duration m_SendInterval;
};

Timing the above code I was surprised to see that sending a message using UDP over the loopback took about 0.5 seconds, which was at least ten times more than what I had expected. After checking my code multiple times and not finding anything I could only come to the conclusion that somewhere in my code I made a wrong assumption. So I wrote a little test to at least ensure it had nothing to do with boost and to ensure it was my code.

int main()
{
    while(true)
    {
        std::cout << boost::posix::second_clock::universal_time() << std::endl;
    }

    return 0;
}

Removing all the duplicate entries that were printed I found out that the time difference between each timestamp was around 0.5 seconds. This would explain why it would take so long before it would send again. I told its resend delay is 100 milliseconds it would take at least 0.5 seconds because of the problem with the resolution/precision.

But I was using the loopback (sending to 127.0.0.1) and although messages can get lost there it should not happen that often. Sure I could replace everything with a faster clock but I wanted to know why this delay occurred. Taking another look at the send code I noticed that the following line:

bool sendAgain = m_SendTimestamp < currentTime;

If the send time is in the past it would send and this is also true for the very first time. Changing the code so that it checks if the next send time is less or equal than the current time fixed it and the performance increased to 0.005 milliseconds since it no longer had to wait for the first time out.

Sure I could have saved myself a lot of trouble by replacing the clock with the higher resolution variant (after striking concurrency of my list this was my next guess) but I rather spend a few hours on figuring out what exactly is going on. It takes time now but in the end it should save me time when I come before the decision which clock to choose.