[Elecraft] How reliable an internet connection is needed for A K3 remote to work well?

[David Woolley]

It is standard to use UDP (RTP) over VoIP for the reasons given by Iain. 
  Over a corporate network, VoIP traffic should have a QoS tagging on 
the IP packets which causes routers to prioritise it. VoIP over the 
internet has always been done for cost, not quality reasons, as the 
whole concept behind IP networks is at conflict with constant rate 
traffic; the telephone industry devised ATM as a packet network for that 
application (although they are now moving to IP, because voice is no 
longer the dominant bandwidth user - but I am sure they will prioritise 
their voice traffic).

RTP has a marker bit which indicates a safe place to dump a latency 
buffer's contents.  Conceivably setting this during tuning would be a 
good idea.  If the remote operation protocol doesn't user RTP, someone 
has been re-inventing the wheel.

As someone mentioned WiFi.  It is generally accepted, in the VoIP world, 
that WiFi and VoIP don't mix because WiFi introduces additional latency. 
  I believe it also does link level retransmission which, means latency 
can be particularly bad if you don't have ideal conditions.

-- 
David Woolley
Owner K2 06123

[ Top quoted through list policy, not preference. ]

On 16/07/14 20:35, iain macdonnell - N6ML wrote:

> The flip-side is that use of a "reliable" protocol, such as TCP, which
> detects and retransmits dropped packets, causes increasing latency
> over time (the more packets get retransmitted, the further behind
> "real time" you get). For something like a "real time" audio stream,
> it generally better to just accept the packet-loss. The problem of
> increasing latency can affect UDP too - some types of unreliable links
> cause a sequence of packets to get queued, then all transmitted in a
> burst.

> It's a tricky problem area. My personal software
> solution uses UDP and a moderately-sized buffer, and when the buffer
> builds up to a point where the latency is more than I like, I click a
> button to dump the contents of the buffer, and return me to
> low-latency.