[HamWAN PSDR] HamWAN PSDR Internet performance

David Giuliani David at Giuliani.org
Tue Apr 5 09:48:14 PDT 2016


Hmmm, lots of things to learn about here, Bart.  I’ll play with this when I have a few.  Anything we can do to have a solid network is greatly appreciated.  I’d like to learn more about HamWAN to make sure I can represent it will to our club (Mercer Island Radio Operators).

Where can I find out what is located at each 44…. address? Otherwise it’s just a bunch of numbers.  I wonder if you have a detailed system map somewhere on-line?



> On Apr 5, 2016, at 9:35 AM, Bart Kus <me at bartk.us> wrote:
> 
> 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:
> 
> [eo at WA6PXX-MercerIs] /tool bandwidth-server> /tool traceroute 8.8.8.8
>  # ADDRESS                          LOSS SENT    LAST     AVG    BEST   WORST STD-DEV STATUS
>  1 44.24.240.33                       0%    1   7.6ms     7.6     7.6     7.6       0
>  2 44.24.240.6                        0%    1   3.6ms     3.6     3.6     3.6       0
>  3 44.24.240.66                       0%    1  24.2ms    24.2    24.2    24.2       0
>  4 44.24.241.113                      0%    1  56.8ms    56.8    56.8    56.8       0
>  5                                    0%    1     0ms
> 
> [eo at WA6PXX-MercerIs] /tool bandwidth-server> /tool bandwidth-test direction=receive 44.24.240.33
>                 status: running
>               duration: 12s
>             rx-current: 7.1Mbps
>   rx-10-second-average: 7.0Mbps
>       rx-total-average: 6.9Mbps
>           lost-packets: 143
>            random-data: no
>              direction: receive
>                rx-size: 1500
> 
> and so on...  By the third hop, you may begin to notice the problems:
> 
> [eo at WA6PXX-MercerIs] /tool bandwidth-server> /tool bandwidth-test direction=receive 44.24.240.66
>                 status: running
>               duration: 7s
>             rx-current: 204.0kbps
>   rx-10-second-average: 921.8kbps
>       rx-total-average: 921.8kbps
>           lost-packets: 34
>            random-data: no
>              direction: receive
>                rx-size: 1500
> 
> Of course your throughput will be limited by existing network load.  You can monitor that using our public traffic graphs:
> 
> http://monitoring.hamwan.net/cacti/ <http://monitoring.hamwan.net/cacti/>
> 
> 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.
> 
> 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.
> 
> 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:
> 
> http://cam.westin.hamwan.net/ <http://cam.westin.hamwan.net/>
> 
> 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:
> 
>  <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 <http://monitoring.hamwan.net/cacti/graph.php?action=view&local_graph_id=439&rra_id=all>
> 
> 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.
> 
> 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.
> 
> --Bart
> 
> 
> On 4/4/2016 10:42 PM, David Giuliani wrote:
>> 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:
>> 
>> ~12 noon: had one recording of 6.5Mbps download - cool!
>> 2pm-3:15pm
>> 	ping 42-55mS
>> 	down: 1.3-1.74 Mbps
>> 	up: 1.45-1.6 Mbps	
>> 3:20: no connection possible
>> 3:23-3:35 similar performance to 2-3:15
>> 4:10: performance faltered, and within a couple minutes the routing adjusted and restored performance.  (Note time in file name)
>> <Mail Attachment.png><Mail Attachment.png><Mail Attachment.png>
>> 
>> 7:35pm: ping: 53mS, down = 1.06Mbps, up =0.9Mbps = lowest so far today
>> 
>> <Mail Attachment.png>
>> 
>> 8:44pm: ping: 86mS, down=0.8Mbps and erratic; up=1.1Mbps
>> <Mail Attachment.png>
>> 
>> 10:22pm: ping=24mS (fast!), down=1.46Mbps, up=2.0Mbps
>> <Mail Attachment.png>
>> Note the two “no response” entries, but similar link performance as earlier in the day, plus faster ping.
>> 
>> 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.
>> 
>> <PastedGraphic-3.tiff>
>> WA6PXX, Mercer Island
>> 
>>> On Apr 4, 2016, at 1:59 PM, Bart Kus < <mailto:me at bartk.us>me at bartk.us <mailto:me at bartk.us>> wrote:
>>> 
>>> This answer lacks a resolution for David's problem.  Let us come back to you with a better response.
>>> 
>>> --Bart
>>> 
>>> 
>>> On 4/4/2016 1:53 PM, Tom Hayward wrote:
>>>> On Mon, Apr 4, 2016 at 1:01 PM, David Giuliani <David at giuliani.org <mailto:David at giuliani.org>> wrote:
>>>> 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:
>>>> 
>>>> Connected to ess, CapitolPark-S2/AE7SJ
>>>> nv2
>>>> Signal: -68dBm
>>>> SNR 51dB
>>>> Tx: 16.2Mbps, 96% ccq, 16.2Mbps
>>>> Rx: 16.2Mbps, 96% ccq, 16.2Mbps
>>>> 
>>>> However, I get sporadic Internet performance, measured using Speedtest.net <http://speedtest.net/>.  Here are a few readings this morning:
>>>> 
>>>> ping    down  up   
>>>> 21ms   3.9      2.8
>>>> 35ms   <0.1  stopped
>>>> 77ms   0.27      0.46
>>>> 42ms   2.0      0.1 
>>>> 
>>>> I did check my cabling between the radio and the computer by substitution - no change.  
>>>> 
>>>> Two things:
>>>> 1.  Anybody have any suggestions? What data rate are others of you getting?
>>>> 2.  Is there a place to go to get help on subjects like this?
>>>> 
>>>> Hi David,
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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):
>>>> 
>>>> /tool traceroute use-dns=yes 8.8.8.8
>>>> 
>>>> (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.)
>>>> 
>>>> To run a speed test (this should work to all HamWAN routers--let me know if it doesn't):
>>>> 
>>>> /tool bandwidth-test protocol=tcp CapitolPark-S2.hamwan.net <http://capitolpark-s2.hamwan.net/>
>>>> 
>>>> This will test speed between your modem and CapitolPark-S2.hamwan.net <http://capitolpark-s2.hamwan.net/>. You can test the other direction by adding direction=transmit to the command.
>>>> 
>>>> This is a perfect forum to ask questions like this.
>>>> 
>>>> Tom KD7LXL
>>>> 
>>>> 
>>>> _______________________________________________
>>>> PSDR mailing list
>>>> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
>>>> http://mail.hamwan.net/mailman/listinfo/psdr <http://mail.hamwan.net/mailman/listinfo/psdr>
>>> 
>>> _______________________________________________
>>> PSDR mailing list
>>> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
>>> http://mail.hamwan.net/mailman/listinfo/psdr <http://mail.hamwan.net/mailman/listinfo/psdr>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20160405/062c46c6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-3.tiff
Type: image/tiff
Size: 7092 bytes
Desc: not available
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20160405/062c46c6/attachment-0001.tiff>


More information about the PSDR mailing list