[HamWAN PSDR] Haystack Site Outage

Nigel Vander Houwen nigel at nigelvh.com
Tue Mar 14 09:32:50 PDT 2017


Bear in mind that client speeds have their own limitations separate from the site itself. I’m not sure (without actually going to look at what modems you have connected) if you’re using single or dual polarity modems, but 5-10 isn’t unexpected from a single polarity, and 5-10 on dual is a bit low, but depends on your signal strength as well.

I didn’t see the speeds on the Paine link, which are worse than should be expected for the signal. And fixing the Westin<->QueenAnne link isn’t a Haystack issue, though it will improve haystack throughput. The victoria link is an interesting one due to the wild signal fluctuations, and if we can set up a site that improves that, that will be a significant benefit.

Capitol Park has historically been a difficult site to get much access to, and unfortunately has a good view of a lot of things if we could get some site time to improve connectivity. It has languished a bit, so I’d agree that if we can get there, that would be a larger benefit to the network as well.

Nigel

> On Mar 14, 2017, at 07:43, Rob Salsgiver <rob at nr3o.com> wrote:
> 
> Thanks Bart.  Laid out well and makes perfect sense – even to a “weak sector” like me <g>.  I thought we had been  having some issues.  My throughputs from endpoints have been usable, but nothing to brag about (lucky to get over 5-10Mbps).  To be fair, I haven’t looked lately so I need to get back onto them and check them out.
>  
> Let me know what I can do.
>  
> Rob
>   <>
> From: PSDR [mailto:psdr-bounces at hamwan.org] On Behalf Of Bart Kus
> Sent: Tuesday, March 14, 2017 2:34 AM
> To: psdr at hamwan.org
> Subject: Re: [HamWAN PSDR] Haystack Site Outage
>  
> I'm not sure that's a fair assessment.  The link to SnoDEM is only -77dBm and only on hpol (vpol is -90 ish).  Here's the perf that link gets:
> 
> [eo at SnoDEM.Haystack <mailto:eo at SnoDEM.Haystack>] /interface wireless registration-table> /tool bandwidth-test 44.24.242.6 direction=receive
>                 status: running
>               duration: 30s
>             rx-current: 4.4Mbps
>   rx-10-second-average: 4.7Mbps
>       rx-total-average: 4.4Mbps
>           lost-packets: 478
>            random-data: no
>              direction: receive
>                rx-size: 1500
> 
> [eo at SnoDEM.Haystack <mailto:eo at SnoDEM.Haystack>] /interface wireless registration-table> /tool bandwidth-test 44.24.242.6 direction=transmit
>                 status: running
>               duration: 30s
>             tx-current: 11.9kbps
>   tx-10-second-average: 27.6kbps
>       tx-total-average: 26.4kbps
>            random-data: no
>              direction: transmit
>                tx-size: 1500
> 
> That TX path makes the link useless.  Better to turn it off!  Or maybe ditch the weak polarity.
> 
> Then there's Nigel's + my link (I'm NOT uplinking right now), both sitting @ -81dBm, which is pretty low.  Or at least we were.  I see Nigel's @ -68dBm right now.  I don't know how to explain that.  Here's the link speed:
> 
> [eo at Haystack-S3] /interface wireless registration-table> /tool bandwidth-test 44.24.241.78 direction=receive
>                 status: running
>               duration: 30s
>             rx-current: 21.3Mbps
>   rx-10-second-average: 19.4Mbps
>       rx-total-average: 18.8Mbps
>           lost-packets: 1720
>            random-data: no
>              direction: receive
>                rx-size: 1500
> 
> [eo at Haystack-S3] /interface wireless registration-table> /tool bandwidth-test 44.24.241.78 direction=transmit
>                 status: running
>               duration: 30s
>             tx-current: 25.2Mbps
>   tx-10-second-average: 26.7Mbps
>       tx-total-average: 24.4Mbps
>            random-data: no
>              direction: transmit
>                tx-size: 1500
> 
> But of course that's on S3, so he'll be sharing time domain with NR3O's uplink, so cut that speed at least in 1/2, and probably more when the -81dBm conditions return.  Then we have a link to QueenAnne:
> 
> [eo at QueenAnne.Haystack <mailto:eo at QueenAnne.Haystack>] > /tool bandwidth-test 44.24.242.39 direction=receive
>                 status: running
>               duration: 30s
>             rx-current: 113.9Mbps
>   rx-10-second-average: 124.3Mbps
>       rx-total-average: 104.6Mbps
>           lost-packets: 6234
>            random-data: no
>              direction: receive
>                rx-size: 1500
> 
> [eo at QueenAnne.Haystack <mailto:eo at QueenAnne.Haystack>] > /tool bandwidth-test 44.24.242.39 direction=transmit
>                 status: running
>               duration: 30s
>             tx-current: 76.2Mbps
>   tx-10-second-average: 76.7Mbps
>       tx-total-average: 58.4Mbps
>            random-data: no
>              direction: transmit
>                tx-size: 1500
> 
> Which as you can see is pretty sweet, but it's then choked by the QueenAnne-Westin link when it comes to reaching the Internet:
> 
> [eo at QueenAnne.Seattle <mailto:eo at QueenAnne.Seattle>] > /tool bandwidth-test 44.24.242.35 direction=receive
>                 status: running
>               duration: 30s
>             rx-current: 3.2Mbps
>   rx-10-second-average: 2.9Mbps
>       rx-total-average: 2.9Mbps
>           lost-packets: 28
>            random-data: no
>              direction: receive
>                rx-size: 1500
> 
> [eo at QueenAnne.Seattle <mailto:eo at QueenAnne.Seattle>] > /tool bandwidth-test 44.24.242.35 direction=transmit
>                 status: running
>               duration: 30s
>             tx-current: 4.5Mbps
>   tx-10-second-average: 4.3Mbps
>       tx-total-average: 4.3Mbps
>            random-data: no
>              direction: transmit
>                tx-size: 1500
> 
> The Victoria link doesn't have direct peering to the Internet, it VPNs back to the Westin.  Last time I measured, it does 15Mbit one way and 30Mbit the other way, and I don't know what the limits are on the cable modem VPN.
> 
> So no, I would not consider Haystack as having good connectivity.  We need to get Victoria onto a different cell site (yet to be constructed) so we can point the dish back at SnoDEM.  Having the dish pointed back @ SnoDEM will also allow K7NVH's uplink to be collinear and get out of the -81dBm muck.  We also need to fix QueenAnne's connectivity.  This might have some chance of success as we get more access to the Capitol Park site.  We could either up CP's connectivity with CA and Baldi, and route via Tukwila, or we could connect CP directly to Haystack and route via Tukwila.  QueenAnne may also be able to link with Gold.
> 
> So if you're seeing slow connectivity, on the order of 5Mbit or so, now you know why.
> 
> PS: I disabled ch1 on Haystack.SnoDEM and the slow Haystack->SnoDEM transfer speeds didn't stop.  Now I suspect it's the brand new 5GHz WiFi that got installed all over that building.  Need to do more research and maybe find a better frequency.
> 
> --Bart
> 
> 
> 
> On 3/13/2017 11:27 PM, Rob Salsgiver wrote:
>> Cool – thanks.  Once again it seems my mind is the item suffering the outages these days….
>>  
>> Sigh
>>  
>> Cheers,
>> Rob
>>  
>> From: PSDR [mailto:psdr-bounces at hamwan.org <mailto:psdr-bounces at hamwan.org>] On Behalf Of Nigel Vander Houwen
>> Sent: Monday, March 13, 2017 11:21 PM
>> To: Puget Sound Data Ring
>> Subject: Re: [HamWAN PSDR] Haystack Site Outage
>>  
>> Haystack is pretty well connected as well, it has links to Vancouver, Paine, and Queen Anne, as well as Bart and myself are uplink nodes connected to Haystack.
>>  
>> Nigel
>>  
>>> On Mar 13, 2017, at 23:19, Rob Salsgiver <rob at nr3o.com <mailto:rob at nr3o.com>> wrote:
>>>  
>>> I was thinking more about the strength/stability of Haystack.  When I was connecting up the hospital in Monroe I thought I remembered being told that Haystack was marginal due to the split from Paine and one of the other links being interfered with (Amazon?) – I might be mixing my site memories.  If it’s marginal I would like to see Haystack solidified (if possible) as I have Evergreen on there and it’s my #1 option for Everett Clinic.
>>>  
>>> Cheers,
>>> Rob
>>>  
>>> From: PSDR [mailto:psdr-bounces at hamwan.org <mailto:psdr-bounces at hamwan.org>] On Behalf Of Nigel Vander Houwen
>>> Sent: Monday, March 13, 2017 10:48 PM
>>> To: Puget Sound Data Ring
>>> Subject: Re: [HamWAN PSDR] Haystack Site Outage
>>>  
>>> Rob,
>>>  
>>> That’s correct, the dish at haystack was turned a few degrees farther north to better connect Victoria. However, the link to Paine remains up, and has fairly good signal strength. Adding in the East Tiger<->Paine and Gold<->Paine links, the site is pretty well connected. Adding another dish to gain a few dB on an already decent signal isn’t currently on the plans.
>>>  
>>> Nigel
>>>  
>>>> On Mar 13, 2017, at 14:21, Rob Salsgiver <rob at nr3o.com <mailto:rob at nr3o.com>> wrote:
>>>>  
>>>> Nigel,
>>>>  
>>>> If memory serves me correctly I think we swung the Paine dish to cover the new Victoria site last year.  Are there any plans to install a separate dish to optimize both links once the weather and access improve?
>>>>  
>>>> Cheers,
>>>> Rob / NR3O
>>>>  
>>>> From: PSDR [mailto:psdr-bounces at hamwan.org <mailto:psdr-bounces at hamwan.org>] On Behalf Of Nigel Vander Houwen
>>>> Sent: Sunday, March 12, 2017 11:24 PM
>>>> To: Puget Sound Data Ring <psdr at hamwan.org <mailto:psdr at hamwan.org>>
>>>> Subject: Re: [HamWAN PSDR] Haystack Site Outage
>>>>  
>>>> Evening Everybody,
>>>>  
>>>> Today Bart and the site owner took another run at getting up to haystack and managed to fight their way up to the site. They managed to get a lot done, and Haystack is in much better shape.
>>>>  
>>>> They found some misbehaving equipment that had a huge draw (>400W continuous) on the power system up there, overwhelming the solar generation capacity, draining the batteries, and causing the generator to run more than it should have been needed, and then run out of fuel.
>>>> They brought up 40 gallons of fuel that was brought partway up the mountain on the last trip.
>>>> Bart replaced the Haystack-S3 modem to see if it would fix an issue we’re seeing with non-symmetric signal strengths. It didn’t resolve the issue, so we’ll revisit that issue again later.
>>>> Replaced the RJ45 connector for the Haystack-S3 modem that may have been the cause for the earlier Haystack-S3 outage.
>>>>  
>>>> All together, with the misbehaving loads removed from the system, and the generator refueled to get the batteries recharged so it’s not all on solar to bring things back up, things are looking much better.
>>>>  
>>>> We’ve powered back online all of the HamWAN equipment at the site, so the sectors and backbone links are all up and operating normally.
>>>>  
>>>> I’d like to thank again the folks who made the previous attempt and got the fuel most of the way up the mountain, as well as bart and the site owner for making the run today to finish the job. All the efforts are appreciated, and are paying off in the site being back online.
>>>>  
>>>> Nigel
>>>>  
>>>>  
>>>>> On Mar 4, 2017, at 23:41, Nigel Vander Houwen <nigel at nigelvh.com <mailto:nigel at nigelvh.com>> wrote:
>>>>>  
>>>>> Hello All,
>>>>> 
>>>>> Our site at Haystack has been having some trouble with the solar charging setup, and has not been able to get much energy with the limited solar that remains working onsite, as such, the site owner has been intermittently running the generator to keep the batteries charged. Unfortunately, as of Friday the generator is out of fuel.
>>>>> 
>>>>> Bart, Bruce, and one or two others (I didn’t catch the names), made a heroic effort today to get onsite with snowmobiles and a snow cat to refuel the tanks, and repair the solar charging problems, but were stymied by snow conditions, and were not able to reach the site today.
>>>>> 
>>>>> Considering the limited solar functioning, and the clear weather today, we had a pretty good day, but the forecast doesn’t look promising for keeping that up.
>>>>> 
>>>>> I’ve shut down our sectors at Haystack to try and conserve some power, so if you normally connect to Haystack, or were looking to try, please be aware that for the moment, the Haystack sectors are offline.
>>>>> 
>>>>> We’ll let you know when we’re able to get the sectors back online. Hopefully soon we’ll be able to get more fuel up there, and the extra solar capacity repaired.
>>>>> 
>>>>> Thanks again for the efforts of the volunteers that tried to reach the site today. It was a real slog, and the efforts are appreciated.
>>>>> 
>>>>> Nigel
>>>>> _______________________________________________
>>>>> 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>
>>>  
>>> _______________________________________________
>>> 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> 
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.net/mailman/listinfo/psdr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20170314/37d80498/attachment-0001.html>


More information about the PSDR mailing list