Forum Discussion

Brian_Ott_11267's avatar
Brian_Ott_11267
Icon for Nimbostratus rankNimbostratus
Nov 11, 2005

RTT value

The value provided by TCP:rtt, is it effected by processing time server side?

 

 

Meaning if the customer does a big search and it takes time to process, does that effect RTT? Or is RTT based on the time to send a packet between us and them?

 

 

Also the value returned by TCP:rtt, its 1/32nd of a millisecond, right?

 

 

So does that mean: if the value is 2400, its 75 ms?

 

 

Or 1600 is 50 ms?

 

 

I appreciate any help offered.

 

 

-Brian.

7 Replies

  • rapmaster_c_127's avatar
    rapmaster_c_127
    Historic F5 Account
    TCP::rtt is not affected by processing time. It is the "pure rtt" determined at the TCP layer to the peer. The value will be different between the client side and the serverside. If we were to include processing time, it would lead to vastly unfair and non-deterministic results, not to mention a bit of a layering violation.

     

     

    Even though our measurement granularity for a round-trip is generally 1ms (as given by the timestamps we use to obtain fine-grained round-trip resolutions and re-ordering detection), we use a smoothed-round-trip moving average that requires us to return these values in multiples. For those who are interested, floating-point math should generally be avoided in the kernel, so we simply scale up by a factor of 32 to obtain the resolution we need when calculating these values, so we don't lose too much to round-off errors.

     

     

    So yes, if TCP::rtt gives you "32" this means that we've detected the round trip time between us and the endpoint in question to be 1ms. And if you get 2400, the rtt being estimated is indeed 75ms.

     

     

    Does this help?
  • rapmaster_c_127's avatar
    rapmaster_c_127
    Historic F5 Account
    There is one more caveat that I wanted to briefly mention. As you can imagine, internet RTTs vary greatly. If someone's connected to you via a wireless connection, and turns on their microwave oven, that could lead to some jitter that throws the rtt values off.

     

     

    To resolve this, we use certain low-pass filters and smoothing functions to make sure that outliers don't completely kill the values you're getting. However, in order for these to be effective, we need a number of round-trip samples to converge and make that determination. Thus, the longer a host has been talking to us, the better this estimation will be. It needn't be in the same connection (we remember the rtts we calculated for hosts we spoke to in the recent past even if they're not connected to us), but in case you see jitter right after the 3-way handshake completes for the first time, this is usually due to our not having a large enough sample set.

     

     

  • Would it be possible to log out the rtt for some connections so we can get some idea of what this value can be for various people?

     

     

    I'd like to send it to a log on a remote server ,preferably, and just build some kind of table.

     

     

    I am still hunting through documentation as to how to do this.

     

     

    -Brian.
  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    That would mostly be done through syslog-ng. Find an appropritely available facility and route it to your remote server. Then simply add a statement like:
    log . "Client: [IP::remote_addr] - RTT: [TCP::rtt]"
    to your rule. syslog-ng should then route that log message to your remote server.
  • Posted By rapmaster_c on 11/11/2005 10:54 AM

     

     

    There is one more caveat that I wanted to briefly mention. As you can imagine, internet RTTs vary greatly. If someone's connected to you via a wireless connection, and turns on their microwave oven, that could lead to some jitter that throws the rtt values off.

     

     

    To resolve this, we use certain low-pass filters and smoothing functions to make sure that outliers don't completely kill the values you're getting. However, in order for these to be effective, we need a number of round-trip samples to converge and make that determination. Thus, the longer a host has been talking to us, the better this estimation will be. It needn't be in the same connection (we remember the rtts we calculated for hosts we spoke to in the recent past even if they're not connected to us), but in case you see jitter right after the 3-way handshake completes for the first time, this is usually due to our not having a large enough sample set.

     

     

     

     

    Hi,

     

     

    In most case, we cannot get the RTT value on the first time we connected. I think it is due to not enough sample set, right? So, what is the fastest way to find out the RTT?

     

     

    In addition, if we use small data size (e.g. less than 1KB), will it be able to get the RTT?

     

     

    Regards,
  • So, it is likely that I get 1K data 5 times is better than get a 5K data one time, right?

     

     

    In addition, should I write some iRules to handle these connection, in order to get the RTT value?

     

     

    Million thanks.
  • Hi everyone, I'm very interested by these explanations because I'm trying to setup an iRule redirecting people to different websites depending on their "connection speed" to the load balancer ... Here is my iRule, but the RTT I'm measuring are not relevant 😞 I guess that's because there is not enough traffic to detemine a relevant value

    How could I generate this kind of traffic with the same iRule in order to have a more precise RTT measure ?

     
    when HTTP_REQUEST {
      clientside { set rtt [TCP::rtt] }
      set clientip [IP::remote_addr]
      if {$rtt < 5600 } {
       log "$clientip redirect fast $rtt"
       HTTP::redirect "http://fast-site"
      } else {
       log "$clientip redirect slow $rtt"
       HTTP::redirect "http://slow-site"
      }
    }

    thanks everyone for your help