On Jul 25, 2014, at 5:02 PM, W5UXH chuck.broadw...@gmail.com wrote:
Almost all of my packet loss is at hop #2 which is the first node past my
router.
But are you seeing that packet loss reflected on every hop past that point? ISP
routers are often configured to rate-limit or block
On 7/29/2014 3:47 AM, Bob Snyder wrote:
On Jul 25, 2014, at 5:02 PM, W5UXHchuck.broadw...@gmail.com wrote:
Almost all of my packet loss is at hop #2 which is the first node past my
router.
But are you seeing that packet loss reflected on every hop past that point?
I'm not going to disagree
Remember that we're talking UDP, not TCP, so it's not actually a connection.
and the theory is that IP networks are a mesh, but it often doesn't
behave like a mesh, and least in any positive way.
Good networks cost more than cheezy ones, but many of us find it hard to
justify $200+
Huh?
On Jul 25, 2014, at 12:43 PM, Lynn W. Taylor, WB6UUT
k...@coldrockshotbrooms.com wrote:
If you're going to ping something, do a traceroute and ping a router a few
hops into your provider's network, or ping something like your provider's web
server.
When you choose to ping
Mike,
Think of it as tuning up on top of an existing QSO. You're using
Google's bandwidth, but not in any way that supports Google.
If lots of people tune up on top of Google, they have to address the
unwanted traffic, or throw money at the problem (buy more bandwidth).
Courtesy suggest
TCP/IP insures delivery, not performance. It is a mesh, not a point to point
connection
Every router along the way is subject to congestion and packets can take
different path if conditions warrant. There is no way to control the path once
it is past gear in your control.
You could go over a
I recently started using the PingPlotter network monitoring software and find
it quite useful for keeping long term data in graph format of my packet loss
with Comcast.
http://www.pingplotter.com/ http://www.pingplotter.com/
The Free version does not provide long term monitoring. The
If you're going to ping something, do a traceroute and ping a router a
few hops into your provider's network, or ping something like your
provider's web server.
When you choose to ping something like Google, it tells you about your
provider's network up to the first place they can get rid of
I have almost identical symptoms - brief audio dropouts, sometimes
solitary, sometimes many and frequent, rendering the remote setup unusable.
However, I'm NOT using WiFi connectivity between the RRC and the router. My
RRC connects directly to my Cisco/Linksys EA4500 router with a short RJ45
Suggest you find the EA menu that allows you to optimize SIP
and/or VoIP performance. It is here on this EA9600 somewhere. I
think all the higher-end Linksys routers have this setting.
Most remote audio uses SIP for call setup and one of several ULPs for
voice VoIP. RTP is one of them.
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
Is QoS well implemented in IPv4?
Per-Tore / LA7NO
On 18 July 2014 11:22, David Woolley for...@david-woolley.me.uk wrote:
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
Just a further tip from my side: the RemoteRig RRC allows ToS tagging.
It is entered in the advanced settings under IP Type-of-Service (dec).
The manual refers to RFC791 that use this in QoS networks and support
this function. Entries must be made in decimal.
Unfortunately, I have found no
I have a MicroTik inexpensive router that supports QOS, and it helps.
However, all bets are off when using far-flung networks.
BTW, I've been exclusively VoIP with my landlines for over 10 years.
Quality is very good (using the correct provider), and, yes, cost is very
low. All the major
If you want to use QOS tagging, you need to make sure that you 'somehow'
get all the packets tagged in your network. It is harder to do than it
sounds. DD-WRT routers seem to do it 'ok' but I have yet to solve it
perfectly. In my situation, my remote base is at a cottage and it works
perfectly
On 7/18/2014 12:29 PM, Michael Walker wrote:
The moral of the story is to stay wired unless you have to go wireless. A
single box of 1000ft of Cat 5 isn't very expensive and provides a much
better connection in such a solution.
I've actually used powerline adapters when wiring was inconvenient
Barry - I've been playing around with a RemoteRig at K4VV, where Mike W0YR
had set up remote operating using VNC and Mumble/Skype for audio. The
performance of the Internet connection there (which is wireless) is pretty
bad - audio dropouts making CW essentially impossible for any real contest.
Here's some real-world experience from the three of the six remotes we
operated this past weekend from WRTC:
Our Network at WRTC HQ: Either 100/9 Mbps WRTC-only or 20/20 Mbps shared
with the hotel network.
PR1T: ~384 Kbps using multiple technologies
Typical ping time: 170-190 mS Number of
Gerry - How does one measure jitter?
All - We have the CW issues worked out, using a VNC window and having the
transmitter connected directly to N1mm, rather than trying to send CW iover
the network.
My remaining question is - in the presence of a somewhat flaky Internet
connection, for whatever
Barry,
Do a long series of pings (ping address -n 500 will let it run 500 times)
Jitter is the difference between ping times (100ms ping and 120ms ping is
20mS jitter)
My remaining question is - in the presence of a somewhat flaky Internet
connection, for whatever reason - latency, jitter,
Hint: Don't turn knobs like audio or power fast. Each pulse from the knob
is sent as a UDP packet...
I'm late to join this thread, but was curious so read a couple before
deleting. What I bring up below may have been discussed before.
I'm not much of a network person, but I believe UDP
On Wed, Jul 16, 2014 at 12:13 PM, AG0N-3055 mcduf...@ag0n.net wrote:
Hint: Don't turn knobs like audio or power fast. Each pulse from the knob
is sent as a UDP packet...
I'm late to join this thread, but was curious so read a couple before
deleting. What I bring up below may have been
Barry and others,
I have been following the discussion and want to add the description of a
problem and its solution that I encountered with my remote operation.
My set-up:
Control site: Manhattan, New York; k3/0 mini to RemoteRig with wireless to
WiFi router to Cable ISP (ping 10ms;
On 7/16/2014 12:13 PM, AG0N-3055 wrote:
I'm not much of a network person, but I believe UDP packets are tossed
out with no error correction at all (like unproto X25 packet).
I am a network person. When you use UDP, it is up to the protocol layer
above to handle dropped packets.
For
Keep in mind too that WiFi channels overlap quite a bit. If the problem
is WiFi activity on channel 6, you'd have to go to 3 or 9 to be
completely clear.
73 -- Lynn
On 7/16/2014 1:51 PM, James Beitchman wrote:
What I learned is that
most WiFi equipment as-delivered is set for channel 6 as
I think you mean channels 1, 6 or 11 to avoid overlap on the 802.11 2.4 GHz
band. Other WiFi bands may differ.
http://en.wikipedia.org/wiki/List_of_WLAN_channels
Regards,
David McAnally
WD5M
On Wed, Jul 16, 2014 at 4:40 PM, Lynn W. Taylor, WB6UUT
k...@coldrockshotbrooms.com wrote:
Keep in
There are only actually 3 wifi channels at 2.4ghz for 20mhz spacing, and
they are 1, 6 and 11.
By using any of the other numbers you are overlapping the adjacent channel.
Whey they let you pick 2,3,4,5, etc., is beyond me.
By using 8, you will be getting interference from both channels 6 and
Fortunately, this is one group I DON'T have to explain to about
overlapping frequencies. See the picture--it will make it clear as day.
There are fundamentally (in the US) only 3 frequencies that correspond
to channels 1,6, and 11. In Europe, you also get a 4th frequency on
channel 14.
Another solution if your hardware and router support it is to move to 5ghz.
Much less chance of interference but wireless range is less.
Original message
From: Eric Ross e...@evross.com
Date: 16/07/2014 6:05 PM (GMT-05:00)
To: elecraft@mailman.qth.net
Subject: Re:
RemoteRig/RRC uses UDP (Realtime Data Protocol) for Audio, and I'm sure a
lot of other stuff. This is the best mode for most of what we are doing
with remote ham radio.
Signaling is modified Session Initiation Protocol (SIP), also UDP.
All that you need to know is that it will do fairly well
Barry,
The RemoteRig system generates its own CW using an internal protocol,
which solves latency issues. You use your key at the control end and the
radio side RRC generates a clean CW without hiccups. It has error
control and is (I believe) very robust. I know of someone doing 40 wpm
full
A while back we tried Remoterig with a Kenwood radio and the CW generated was
poor on the other end. This was presumably from dropped packets and or
latency issues (Comcast on one end and a terrestrial microwave connection on
the other end). Some dits/dahs were lost and others were prolonged,
Run pingtest.net and make sure you have a grade A rating. You don't need much
bandwidth as 1mbs in each direction is lots if you are the only user. However,
latency issues will cause problems.
As I understand it, the K3/remote uses a remoterig interface.
The problem may not be your ISP, but
33 matches
Mail list logo
