How do I calculate network speed: either "goodput" Bandwidth, or real Bandwith?

Question

I'm trying to determine the latency and bandwidth between the server and various clients in a multi-tier system. I believe the easiest item to get is the "goodput" or the effective Application-layer rate, but the latency is a bit harder to get at, yet harder still is the true bandwidth that includes "window size" and other technical factors.

I'm looking for either a description of how to most accurately calculate this from either the client or server perspective... as long as I am able to run the server on Azure.

I'm open to (but not limited to) using IIS to stream a series of bytes, a TCP-based WCF service, but the solution needs to be .NET based.

UPDATE

I added a bounty to this question since there is so much information out there... and yet much seems to conflict each other, or have missing data, especially in a .NET implementation. I'm most interested in having 2 implementations C# or Silverlight.

Some networking Gurus have said I need to take the "slow start" of TCP window size into consideration.

Answer 1

Hello,

did you try WCF tracing and message logging? If you turn on tracing ane message logging on the service and also on clients you can open all logs in Service trace viewer and check all end to end information.

Best regards, Ladislav

Answer 2

I hate to see a good bounty go to waste so I'll attempt to answer my own question with the information I have available.

[Latency]

Measuring actual (on the wire) latency and speed using Silverlight is not possible, since we don't have access to TCP sockets and can't access such low-level interfaces from the sandbox. That also kills the "TCP SlowStart" as well.That being said, it's possible to infer WCF latency and Goodput bandwith.

WCF Service

2    using System;
3    using System.Net.NetworkInformation;
4    using System.Text;
5    
6    public class Service : IService
7    {
8        public bool PingNetwork()
9        {
10           return true;
11       }
12   }

And the client side:

   using System;
   using System.Windows;
   using System.Windows.Controls;
   using PingDemo.PingServiceReference;

   namespace PingDemo
   {
       public partial class MainPage : UserControl
       {
           private ServiceClient client = new ServiceClient();
           private DateTime PingStart = new DateTime();


       public MainPage()
       {
           InitializeComponent();

           client.PingNetworkCompleted += new EventHandler(client_PingNetworkCompleted);
       }

       void client_PingNetworkCompleted(object sender, PingNetworkCompletedEventArgs e)
       {
           if (e.Error == null && e.Cancelled == false)
           {
               MessageBox.Show("Ping Status: " + e.Result);
           }
       }

       private void btnPing_Click(object sender, RoutedEventArgs e)
       {
           if (client == null)
           {
               client = new ServiceClient();
           }

           PingStart = DateTime.UtcNow();
           client.PingNetworkAsync(txtHostIP.Text.Trim());
           TimeSpan Est_RoundTripTime = DateTime - PingStart;  //may need to look up exact syntax

       }
   }

}

[Upload Download]

In a similar manner that Latency is determined by using a WCF service host, upload and download speed can be estimated by downloading a known (uncompressable) set of data to the client, and back.

The following blog discusses an approach to send large data over WCF. This can be used to calculate the speed in which data is sent/transmitted using a similar manner as above.

http://kjellsj.blogspot.com/2007/02/wcf-streaming-upload-files-over-http.html

Answer 3

I've been considering a technique for a while that could produce decent results with regard to determining latency.

If the client and the server have synchronized clocks with very high accuracy (against a common, low-latency source; i.e.: time.nist.gov), simply sending the current timestamp on the server to the client would allow the client to compare its local time with the server's time. The difference in timestamps would yield the latency.

This could be used in combination with large "dummy" file transfers to determine latency during sustained transfers and under different network loads.