[HamWAN PSDR] HamWAN PSDR Internet performance
John D. Hays
john at hays.org
Tue Apr 5 09:56:19 PDT 2016
David,
Be advised there are 16 million 44.x.x.x addresses -- most do not have
anything attached. An exhaustive list of hosts and servers would be very
difficult to achieve.
This might help with an individual address
http://mxtoolbox.com/ReverseLookup.aspx
John
On Tue, Apr 5, 2016 at 9:48 AM, David Giuliani <David at giuliani.org> wrote:
> 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/
>
> 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/
>
> 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
>
> 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 < <me at bartk.us>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> 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 listPSDR at hamwan.orghttp://mail.hamwan.net/mailman/listinfo/psdr
>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.net/mailman/listinfo/psdr
>
>
>
>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.net/mailman/listinfo/psdr
>
>
--
------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20160405/2c1cf403/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/2c1cf403/attachment-0001.tiff>
More information about the PSDR
mailing list