<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks for the excellent data. If you'd like to have more fun, I'd
also like to point out that all of our routers should be running
bandwidth-server instances. This means you can make actual RF
throughput measures on a per-hop basis. Try it to your first hop:<br>
<br>
<tt>[eo@WA6PXX-MercerIs] /tool bandwidth-server> /tool traceroute
8.8.8.8</tt><tt><br>
</tt><tt> # ADDRESS LOSS SENT LAST
AVG BEST WORST STD-DEV STATUS</tt><tt><br>
</tt><tt> 1 44.24.240.33 0% 1 7.6ms
7.6 7.6 7.6 0</tt><tt><br>
</tt><tt> 2 44.24.240.6 0% 1 3.6ms
3.6 3.6 3.6 0</tt><tt><br>
</tt><tt> 3 44.24.240.66 0% 1 24.2ms
24.2 24.2 24.2 0</tt><tt><br>
</tt><tt> 4 44.24.241.113 0% 1 56.8ms
56.8 56.8 56.8 0</tt><tt><br>
</tt><tt> 5 0% 1 0ms</tt><tt><br>
</tt><tt><br>
</tt><tt>[eo@WA6PXX-MercerIs] /tool bandwidth-server> /tool
bandwidth-test direction=receive 44.24.240.33</tt><tt><br>
</tt><tt> status: running</tt><tt><br>
</tt><tt> duration: 12s</tt><tt><br>
</tt><tt> rx-current: 7.1Mbps</tt><tt><br>
</tt><tt> rx-10-second-average: 7.0Mbps</tt><tt><br>
</tt><tt> rx-total-average: 6.9Mbps</tt><tt><br>
</tt><tt> lost-packets: 143</tt><tt><br>
</tt><tt> random-data: no</tt><tt><br>
</tt><tt> direction: receive</tt><tt><br>
</tt><tt> rx-size: 1500</tt><tt><br>
</tt><br>
and so on... By the third hop, you may begin to notice the
problems:<br>
<br>
<tt>[eo@WA6PXX-MercerIs] /tool bandwidth-server> /tool
bandwidth-test direction=receive 44.24.240.66</tt><tt><br>
</tt><tt> status: running</tt><tt><br>
</tt><tt> duration: 7s</tt><tt><br>
</tt><tt> rx-current: 204.0kbps</tt><tt><br>
</tt><tt> rx-10-second-average: 921.8kbps</tt><tt><br>
</tt><tt> rx-total-average: 921.8kbps</tt><tt><br>
</tt><tt> lost-packets: 34</tt><tt><br>
</tt><tt> random-data: no</tt><tt><br>
</tt><tt> direction: receive</tt><tt><br>
</tt><tt> rx-size: 1500</tt><tt><br>
</tt><br>
Of course your throughput will be limited by existing network load.
You can monitor that using our public traffic graphs:<br>
<br>
<a href="http://monitoring.hamwan.net/cacti/"><tt>http://monitoring.hamwan.net/cacti/</tt></a><br>
<br>
The login / password is hamwan / hamwan. (I though I had gotten rid
of it, but it persists.) These only update once every 5 minutes, so
they're not as handy as they could be for manual testing. In most
cases though, the network is idle enough that you won't need them,
and bandwidth-test results will be highly indicative of link speed.
Be sure to give the links at least 30 seconds to come up to speed.
They default to sitting at a lower speed when they're not being
asked to move lots of data, and then they train up on higher speeds
as required. This is to maximize their reliability when only low
data rates are required.<br>
<br>
Oh, and you will not be able to do a bandwidth-test to the edge
routers. These have firewall rules that prevent bandwidth-testing.
We should really fix that at some point.<br>
<br>
Speaking of fixing, I've started writing some software last night to
help us optimize the QA-CP and QA-Westin links. Both of these
sometimes affect your connection. As Tom mentioned, QA-CP is
affected by a poor path to the side of a dish, but QA-Westin is
affected by Amazon constructing a new building right in the signal
path. You can view the path obstacle here:<br>
<br>
<tt><a href="http://cam.westin.hamwan.net/">http://cam.westin.hamwan.net/</a></tt><br>
<br>
If we can't get either of these links to perform acceptably, we can
manually give them a lower priority on the network. The QA-CP link
might be helped a lot just by installing a higher gain modem @ QA
and/or rotating/upgrading the dish @ CP. The QA-Westin problem is a
little harder. So far we've reduced the bandwidth of QA-Westin to
help it out, and you can see the signal increase in the associated
graph:<br>
<br>
<tt><a
href="http://monitoring.hamwan.net/cacti/graph.php?action=view&local_graph_id=439&rra_id=all"><a class="moz-txt-link-freetext" href="http://monitoring.hamwan.net/cacti/graph.php?action=view&local_graph_id=439&rra_id=all">http://monitoring.hamwan.net/cacti/graph.php?action=view&local_graph_id=439&rra_id=all</a></a></tt><br>
<br>
But it doesn't seem to have helped speeds at all, so now we need to
do some interference-avoidance work. I hope to have that software
finished this week.<br>
<br>
The last problem we should address here is the apparent route
flapping inside the network. We don't have any good tools in place
to monitor that, and it looks to be affecting your path. While this
shouldn't result in outages for you, it does indicate marginal
network stability, so it's a problem we need to look into. I do
have designs to monitor this and mitigate it, but they're slightly
longer-term.<br>
<br>
--Bart<br>
<br>
<br>
<div class="moz-cite-prefix">On 4/4/2016 10:42 PM, David Giuliani
wrote:<br>
</div>
<blockquote
cite="mid:A79B134B-BD9B-4DAA-A154-3FEF00E3547D@Giuliani.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Thanks for the suggestions today, guys. I used WinMTR to monitor
routes, and ran some speed tests during the day. 5.9GHz link has
remained strong at about 50dB SNR aimed at CapitolPark. Here’s a
performance report:
<div class=""><br class="">
<div class="">
<div class="">~12 noon: had one recording of 6.5Mbps download
- cool!</div>
<div class="">2pm-3:15pm</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>ping
42-55mS</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>down:
1.3-1.74 Mbps</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>up:
1.45-1.6 Mbps<span class="Apple-tab-span" style="white-space:pre"> </span></div>
<div class="">3:20: no connection possible</div>
<div class="">3:23-3:35 similar performance to 2-3:15</div>
<div class="">4:10: performance faltered, and within a couple
minutes the routing adjusted and restored performance.
(Note time in file name)</div>
<div class=""><img apple-inline="no"
id="C813E9FD-A90A-4FA2-BFAC-F4F81428D3B7"
apple-width="yes" apple-height="yes"
src="cid:part4.07040701.04030508@bartk.us" class=""
height="102" width="90"><img apple-inline="no"
id="67D1895B-F8AC-4F14-B509-E2F1421D9B7F"
apple-width="yes" apple-height="yes"
src="cid:part5.00060203.03050706@bartk.us" class=""
height="102" width="90"><img apple-inline="no"
id="32FCA735-3B57-4711-B086-89C8DE28EFCF"
apple-width="yes" apple-height="yes"
src="cid:part6.09090202.08030401@bartk.us" class=""
height="102" width="90"></div>
<div class=""><br class="">
</div>
<div class="">7:35pm: ping: 53mS, down = 1.06Mbps, up =0.9Mbps
= lowest so far today</div>
<div class=""><br class="">
</div>
<div class=""><img apple-width="yes" apple-height="yes"
apple-inline="no"
id="5E9C261B-2E4E-4EEF-A896-82490CCFE236"
src="cid:part7.01090804.01030502@bartk.us" class=""
height="102" width="90"></div>
<div class=""><br class="">
</div>
<div class="">8:44pm: ping: 86mS, down=0.8Mbps and erratic;
up=1.1Mbps</div>
<div class=""><img apple-width="yes" apple-height="yes"
apple-inline="no"
id="EE846ED5-6565-493D-9677-D1882F4BF0F9"
src="cid:part8.08050302.09060906@bartk.us" class=""
height="102" width="90"></div>
<div class=""><br class="">
</div>
<div class="">10:22pm: ping=24mS (fast!), down=1.46Mbps,
up=2.0Mbps</div>
<div class=""><img apple-width="yes" apple-height="yes"
apple-inline="no"
id="3EE31A6D-447F-4D2C-A8C1-D4155C02F4F0"
src="cid:part9.08080100.00050004@bartk.us" class=""
height="102" width="90"></div>
<div class="">Note the two “no response” entries, but similar
link performance as earlier in the day, plus faster ping.</div>
<div class=""><br class="">
</div>
<div class="">I hope this helps you guys figure out how the
system’s working. As far as I’m concerned, the 1.5Mbps
speeds are find for WINLINK, it’s just the availability
reliability that’s concerning.</div>
<div class=""><br class="">
</div>
<div class=""><img moz-do-not-send="true" apple-inline="yes"
id="90841B39-5F48-4336-8225-9CDE0D9C2A72"
apple-width="yes" apple-height="yes"
src="cid:04659C35-A5B9-4B6C-99CC-9F8074118DB8" class=""
height="105" width="125"></div>
<div class="">WA6PXX, Mercer Island</div>
<div class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Apr 4, 2016, at 1:59 PM, Bart Kus <<a
moz-do-not-send="true" href="mailto:me@bartk.us"
class=""><a class="moz-txt-link-abbreviated" href="mailto:me@bartk.us">me@bartk.us</a></a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class=""> This
answer lacks a resolution for David's problem. Let
us come back to you with a better response.<br
class="">
<br class="">
--Bart<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">On 4/4/2016 1:53 PM,
Tom Hayward wrote:<br class="">
</div>
<blockquote
cite="mid:CAFXO5Z3+CQjyDMvMw9z=2bMkCQetk+nOeQUz0qiO8kmDW9DEyA@mail.gmail.com"
type="cite" class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Apr 4, 2016
at 1:01 PM, David Giuliani <span dir="ltr"
class=""><<a moz-do-not-send="true"
href="mailto:David@giuliani.org"
target="_blank" class="">David@giuliani.org</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word" class="">Hi
- I’m new to the PSDR, and could use
some help getting my HamWAN connection
going. I installed a Poynting +
Mikrotik Router Board system on my roof,
and configured using the Wiki, no
problems. I’m getting strong signals
between my QTH at north Mercer Island
and the Capitol Park station:
<div class=""><br class="">
</div>
<div class="">Connected to ess,
CapitolPark-S2/AE7SJ</div>
<div class="">nv2</div>
<div class="">Signal: -68dBm</div>
<div class="">SNR 51dB</div>
<div class="">Tx: 16.2Mbps, 96% ccq,
16.2Mbps</div>
<div class="">Rx: 16.2Mbps, 96% ccq,
16.2Mbps</div>
<div class=""><br class="">
</div>
<div class="">However, I get sporadic
Internet performance, measured using <a
moz-do-not-send="true"
href="http://speedtest.net/"
target="_blank" class="">Speedtest.net</a>.
Here are a few readings this morning:</div>
<div class=""><br class="">
</div>
<div class=""><b class="">ping down
up</b> </div>
<div class="">21ms 3.9 2.8</div>
<div class="">35ms <0.1 stopped</div>
<div class="">77ms 0.27 0.46</div>
<div class="">42ms 2.0 0.1 </div>
<div class=""><br class="">
</div>
<div class="">I did check my cabling
between the radio and the computer by
substitution - no change. </div>
<div class=""><br class="">
</div>
<div class="">Two things:</div>
<div class="">1. Anybody have any
suggestions? What data rate are others
of you getting?</div>
<div class="">2. Is there a place to go
to get help on subjects like this?</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Hi David,</div>
<div class=""><br class="">
</div>
<div class="">Nice to see you have had some
success with HamWAN! -68 dBm is a great
signal strength and I'm sure many others
here envy your clear line-of-sight to a
HamWAN site.</div>
<div class=""><br class="">
</div>
<div class="">I took a look at this and the
slow hop between you and the Internet is
between our Capitol Park and Queen Anne
sites. That link is sub-optimal because
it's connected off the sidelobe of a dish
that is pointed at the SnoDEM site. It's
enough to work, but as you've found it's
not the fastest. There's nothing you can
do about it.</div>
<div class=""><br class="">
</div>
<div class="">The way I investigated this is
by doing speed tests to each of the hops
in your path. You can find the path like
this (from your modem):</div>
<div class=""><br class="">
</div>
<div class="">/tool traceroute use-dns=yes
8.8.8.8</div>
<div class=""><br class="">
</div>
<div class="">(8.8.8.8 is Google public DNS
servers. It's likely to always be up. Feel
free to use any other target depending on
the nature of your test.)</div>
<div class=""><br class="">
</div>
<div class="">To run a speed test (this
should work to all HamWAN routers--let me
know if it doesn't):</div>
<div class=""><br class="">
</div>
<div class="">/tool bandwidth-test
protocol=tcp <a moz-do-not-send="true"
href="http://capitolpark-s2.hamwan.net/"
class="">CapitolPark-S2.hamwan.net</a></div>
<div class=""><br class="">
</div>
<div class="">This will test speed between
your modem and <a moz-do-not-send="true"
href="http://capitolpark-s2.hamwan.net/"
class="">CapitolPark-S2.hamwan.net</a>.
You can test the other direction by adding
direction=transmit to the command.</div>
<div class=""><br class="">
</div>
<div class="">This is a perfect forum to ask
questions like this.</div>
<div class=""><br class="">
</div>
<div class="">Tom KD7LXL</div>
</div>
</div>
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
PSDR mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mail.hamwan.net/mailman/listinfo/psdr">http://mail.hamwan.net/mailman/listinfo/psdr</a>
</pre>
</blockquote>
<br class="">
</div>
_______________________________________________<br
class="">
PSDR mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:PSDR@hamwan.org" class="">PSDR@hamwan.org</a><br
class="">
<a class="moz-txt-link-freetext" href="http://mail.hamwan.net/mailman/listinfo/psdr">http://mail.hamwan.net/mailman/listinfo/psdr</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>