How to Determine Effective Data-Transfer Rate in Mobilized .NET* Applications

Submit New Article

February 25, 2009 7:48 AM PST


Challenge

Determine the effective data-transfer rate in a mobilized .NET* application. The effective data rate refers to the speed at which real data is being transferred to a remote IP Endpoint. On an Ethernet connection with a link speed of 100 Mbps, in the unlikely event that there were no transport overhead or packet collisions, the best effective data rate would be 12.5 MB/s. Link speed, like the speed limit on an interstate freeway, is useful in determining the ideal nature of the immediate segment of a journey; but it is not very helpful when there is a lot of traffic, and when the segment beyond our immediate ken has a much lower speed limit.

Solution

Extend the Socket class with a DataRateAwareSocket class to track how many bytes are transferred, and how long it takes to transfer them. For example:

//Our new Send method

public new int Send (byte[] buffer)

{

    DateTime start = DateTime.Now; //Start the clock

    int retVal = base.Send( buffer );

    DateTime stop = DateTime.Now; //stop the clock

    TimeSpan elapsedTime = stop - start;

    double rate = (double)retVal / elapsedTime.TotalSeconds;



    Monitor.Enter( m_dCumulativeSendRate ); //Synchronize access

    //BAD algorithm, but you get the idea

    m_dCumulativeSendRate = ( m_dCumulativeSendRate + rate ) / 2; 

    Monitor.Exit( m_dCumulativeSendRate );

    return retVal;

}



public double SendRate

{

    get

    {

        //Calculation is already done, just return the value

    double retVal;

    Monitor.Enter( m_dCumulativeSendRate );

    retVal = m_dCumulativeSendRate;

    Monitor.Exit( m_dCumulativeSendRate );

    return retVal;

    }

}

 

We can make the data transferring threads more efficient if we just accumulate the bytes transferred in the transfer operation and perform calculations only when the querying thread wants the data rate:

//more efficient

public new int Send (byte[] buffer)

{

    int retVal = base.Send( buffer );

    TotalSentBytes += retVal;

    return retVal;

}



//Don't call this on the same thread that is sending data!

public double SampleSendRate(TimeSpan sampleLength)

{

    int iStartByteCount = TotalSentBytes;

            

    //sleep while data is sent

    Thread.Sleep(sampleLength);

    int iEndByteCount = TotalSentBytes;

    int iSentBytes = iEndByteCount - iStartByteCount;

            

    //rate = bytes/second

    return iSentBytes / sampleLength.TotalSeconds;

}

 

Because we have more than one thread using the TotalBytes property, we need to make it thread-safe:

//The object we are going to synchronize on must be a reference type

private Int32 m_iTotalSentBytes = new Int32(); 



//allow threadsafe access

private int TotalSentBytes

{

    get

    {

        int retVal;

    Monitor.Enter( m_iTotalSentBytes ); //Synchronize access

    retVal = m_iTotalSentBytes;

    Monitor.Exit( m_iTotalSentBytes );

    return retVal;

    }

    set

    {

        Monitor.Enter( m_iTotalSentBytes ); //Synchronize access

    m_iTotalSentBytes += value; 

    Monitor.Exit( m_iTotalSentBytes );
            
    }

}

 

A few caveats are necessary here. First, this method does introduce some sampling overhead, compounded by our use of synchronization objects. Second, because of the Nagle algorithm and by the size of the underlying send buffer, our Send() method above may return before the data is actually sent across the network media. One work-around would be to disable the Nagle algorithm and optimize the send buffer size while sampling is taking place; this, of course, would mean that the sampled data rate is not a completely accurate measure of the effective data rate.

Finally, as is the case with road traffic, it would be nice to know the effective data rate before we start transferring data. The method above, however, requires at least some data to be transferred before a measurement can be taken. Since that is probably what we are trying to do anyway, this is no big deal. Should the data rate be too slow for an effective transfer, we can abort the process; if our distributed application has the ability to resume the transfer, we have at least made forward progress while determining our data rate.

We can work around some of these problems by creating our own Internet Control Message Protocol (ICMP) ping functionality using sockets. This would alleviate the sampling overhead and allow us to estimate the effective data rate between us and our target machine before we transfer any of our own data. However, because network traffic requires system resources that may be constrained, and because ICMP replies can be generated by network hardware and drivers, this method is guaranteed to reflect the working state of the remote system on the data rate. In addition, of course, this method is useless in ICMP-unfriendly network environments.

This item is part of a series of items that present sample implementations to obtain network-connection information using the classes found in the .NET Framework:

 

Source