Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
Need the latest SmartSDR, Power Genius, Tuner Genius and Antenna Genius Software?
SmartSDR v3.8.19 and the SmartSDR v3.8.19 Release Notes | SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes
Power Genius XL Utility v3.8.8 and the Power Genius XL Release Notes v3.8.8
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
SmartSDR v3.8.19 and the SmartSDR v3.8.19 Release Notes | SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes
Power Genius XL Utility v3.8.8 and the Power Genius XL Release Notes v3.8.8
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
latency difference between RTT numbers and actual experience
K9SO
Member ✭✭
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?
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?
0
Answers
-
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.
0 -
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.0
-
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.0
-
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.0 -
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 **** their run rates.0 -
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
K9SO0 -
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.
Fred0 -
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
0 -
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.
Mike0 -
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.0 -
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?
John0 -
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
0
Leave a Comment
Categories
- All Categories
- 289 Community Topics
- 2.1K New Ideas
- 529 The Flea Market
- 7.5K Software
- 6K SmartSDR for Windows
- 146 SmartSDR for Maestro and M models
- 357 SmartSDR for Mac
- 249 SmartSDR for iOS
- 229 SmartSDR CAT
- 171 DAX
- 352 SmartSDR API
- 8.7K Radios and Accessories
- 7K FLEX-6000 Signature Series
- 20 FLEX-8000 Signature Series
- 840 Maestro
- 43 FlexControl
- 847 FLEX Series (Legacy) Radios
- 793 Genius Products
- 415 Power Genius XL Amplifier
- 277 Tuner Genius XL
- 101 Antenna Genius
- 243 Shack Infrastructure
- 166 Networking
- 404 Remote Operation (SmartLink)
- 129 Contesting
- 630 Peripherals & Station Integration
- 125 Amateur Radio Interests
- 867 Third-Party Software