latency difference between RTT numbers and actual experience

  • 1
  • Question
  • Updated 5 months ago
Operating "Hunt and Pounce" in the ARRL DX contest this weekend clearly brought forward my disadvantages due to latencies in my remote setup. I wonder if someone could help me understand the sources and particularly the difference between my displayed RTT times and my actual experienced delays. 

I operate my Wisconsin station from nearly 700 miles away in North Carolina. I use a Maestro in NC to link back to a 6600 in Wisconsin. On the NC side, I have a local station running a 6500 controlled by a local PC. I'm using SmartLink on the Maestro for the remote link. Previous posts have indicated that SmartLink does not contribute to latencies after the initial setup. 

My RTT as shown on the NC Maestro ranges between 120-175mS and I only drop 1-2 packets out of every million or so sent (a "GOOD" connection).  But when I send a CW "DIT" from NC [MAESTRO ==>6600 in Wis] and wait to hear it back in NC on the local 6500, the latency is easy much more like 500mS and I'm trying to understand the difference between the RTT  number and the actual round trip "DIT" times I'm experiencing. 

I run a PFSense site-to-site VPN running on two boxes each with Celeron N3160 processors. I know this contributes a lot to the overall latency, but it doesn't seem to be reflected in the RTT times.

Is it possible that the RTT measurement doesn't include the VPN encryption delays? That might explain why I'm seeing such a difference. If not, can anyone help me understand what's going on?
Photo of K9SO

K9SO

  • 104 Posts
  • 19 Reply Likes

Posted 6 months ago

  • 1
Photo of Bob Craig, K8RC

Bob Craig, K8RC

  • 255 Posts
  • 104 Reply Likes
Well, for one, the return path NC==>WI is more like a satellite relay than a wire. It's actually NC => ionosphere  => WI. Depending on frequency, it could easily be a two-hop skip. I frequently hear NC and WI simultaneously here in SW Ohio.

And THAT path latency can become significant. 


(Edited)
Photo of K9SO

K9SO

  • 100 Posts
  • 19 Reply Likes
Bob, you're right, but even if I quadruple the 700 mile path length to account for multiple skip it doesn't add up to much more than 20mS. I'm trying to understand hundreds of milliseconds added delay here. 

Fred
Photo of Chip Swett

Chip Swett

  • 27 Posts
  • 1 Reply Like
I have the same issues between my remote base in Maine and home base in South Carolina.  I prefer to 'run' in contests rather than S&P, but the latencies make running almost impossible.
Photo of JohnSweeney

JohnSweeney

  • 92 Posts
  • 14 Reply Likes
The Flex radios have inherent latency in their design, typically 150 ms or so. If you are using Flex radios on both ends, that is already 300 ms. I operate my IL station from FL and I see the same delays on CW but it has not caused any problems working stations. You do not need VPN for the Maestro, but I do not know the latency involved utilizing the Smartlink server. I also use a VPN connection for other things back home, but use OpenVPN. OpenVPN latency has been about 50 ms. (Comcast to COmcast) I have tested FT8 running on a local PC in IL and also running in FL over DAX and have no problem making FT8 QSO’s. Typically the time delay in FT8 shows up as .2 or .3 seconds. I know this does not answer your question, but thought it might help knowing others are operating in a similar manner.
Photo of Stan - VA7NF

Stan - VA7NF

  • 451 Posts
  • 106 Reply Likes
John hit the main factor.  You have double processing latency.  This is the main reason the variable filter shapes are available.  Setting a less steep filter shape (actually the number of filtering calculations) will reduce that.
Smartlink itself will have NO effect; it is only used in establishing the connection and no traffic is routed through the server.  A direct connection is made between your local and remote ends, after which they talk without outside control.
Photo of K9SO

K9SO

  • 104 Posts
  • 19 Reply Likes
No, RF transmission path latency does not account for what I'm seeing. 700 miles/186,000 miles per second is only 3.8mS. Multiple skips would add no more than 1mS to that. I'm seeing latencies more than two orders of magnitude larger than that.  It is clearly network (or radio) related. 

I think John is closer to the correct response. Much of the latency seems to be built into the design (including filter shapes, etc.). But I'm still trying to understand the difference between the observed latency and the RTT displayed data. In other words, should I be concentrating on an alternative to VPN? I suppose I could do that, but it opens my network up to some bad things.

Surprisingly, this doesn't seem to be as much of a problem on CW, even though the latency is the same. I've never felt at a disadvantage in the CW contests. But some of these big guns in the ARRL DX phone contest don't wait around 500mS for a response. That would kill their run rates. 
Photo of K9SO

K9SO

  • 104 Posts
  • 19 Reply Likes
Stan, thanks. Yes clearly I have double processing involved. Interestingly enough, while playing with the filter settings may have a measurable effect,  I sure don't notice it.

But back to my original question about the RTT displayed times and observation ???

Thanks to all for the inputs so far.

73, Fred
K9SO
(Edited)
Photo of Jim Gilliam

Jim Gilliam

  • 932 Posts
  • 218 Reply Likes
I use OpenVPN and usually see 4 to 5 green bars, When I use Smartlink, I usually 3 to 4 bars. I have never had the experience of having the Smartlink setup equal the lower latency of OpenVPN. Anyone have an idea why? I am using Charter/Spectrum as my ISP. These readings are between a remote that is 100 miles away and the home QTH.

Jim, K6QE
Photo of Michael Walker

Michael Walker, Official Rep

  • 856 Posts
  • 249 Reply Likes
If you do some searching in the community, you will find a few posts regarding Ping and RTT, which are 2 different measurements.

RTT, if I remember correctly is measured between applications.  Ping is measured at the machine level.  RTT is usually longer (not always).

As for 100ms latency, I have yet to see it make a difference despite people saying it does.  If you are a run station you will work the first station you can copy 100% of the callsign and calling first is not always the right way to break a pile up unless you are the loudest.   

When I run, I might hear a weak station, start to copy the first 2 letters and then someone blows him away with a much stronger signal that I easily copy.  I will work that person and then go back to the weaker station.  This is how run stations keep their numbers up.

The process on breaking pileups is well discussed in various Contest University's.   First in does not always win.

Mike 
Photo of K9SO

K9SO

  • 104 Posts
  • 19 Reply Likes
I agree Mike, 100mS doesn't make much difference. I would be very happy with that.

But I'm experiencing over 500mS and trying to understand where that's coming from.  I'm simply asking if anyone knows of any techniques to improve it. The kind of delay I'm seeing does make a difference.
Photo of K1ESE

K1ESE

  • 131 Posts
  • 17 Reply Likes
This weekend I was seeing as much as a 2-second delay in SSB.  Much of the time the latency was very low.  It is rarely a problem on CW.  But, on SSB it was very long in the evenings.

I suspect my cable Internet connection is being shared by other users streaming movies in the evening.  Might that account for the difference?

John
Photo of K9SO

K9SO

  • 104 Posts
  • 19 Reply Likes
John, it most certainly would but I would think that would be reflected in my RTT measurement which really doesn't change.

Mike, I didn't want this thread to degenerate into a discussion of contest operating techniques. I realize I'm not among the best. I simply wanted to understand potential sources of my latency and why it wasn't being reflected in my RTT measurements.

I think most of my latency issue is evenly split between the inherent end-to-end SDR latencies and my particular VPN setup. I can't do anything about the former so I'll take my networking questions to the PFSense VPN forum rather than continuing here.

Nevertheless, I appreciate all the comments.

Thanks and 73,
Fred
K9SO