Re: [WISPA] Test

[Judd Dare]

Reply

On Aug 26, 2017 12:11 AM,  wrote:

Test
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] If you can service any of these hit me off list

[Judd Dare]

Sorry it looks like I replied to everyone. I meant for that follow-up to go
direct to Scott.
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] If you can service any of these hit me off list

[Judd Dare]

Scott did you find what you needed for these locations?  I have an MSA with
Comcast.  We can deliver fiber to many metro areas with SLA.

I'd be happy to see what areas we could deliver and at what cost.

If you're interested, get me a list of addresses and I'll get my guy on it
ASAP.

Judd Dare
Massive Data Networks LLC



On Jul 20, 2017 9:29 PM, "Scott Carullo" <sc...@flhsi.com> wrote:

OMG - you guys sure wine a lot I'm trying to send you business lol

Due to popular demand, and because I don't want to have a price on my head,
here is the complete list in one email.

I figured it was easier for someone to only read my email if the subject
was in their area.  I won't make that mistake again...

If you can service these just send me the install fee, MRC and any terms.
Prefer wireless but in the end they need service at these locations so if
you can servie the location tell me what you provide need 10Mb service.
DOes it have to be dedicated, no but needs static IP and minimum 5Mb up.  I
have not decided whether I am managing all these locations for my customer
or if I will simply refer them to you.  So assume I'm the customer for now
so you have to be sweet to me

Thanks  appreciate your time and SORRY for the mass individual emails
the other day :)

*Location* *Address*
ATL - Atlanta
1000 Toffee Terrace
 Atlanta, GA 30354
ATL-P - Atlanta
1000 Toffee Terrace
 Atlanta, GA 30354
BOS - Boston
152 Harborside Drive
 Building 56
 East Boston, MA 02128
BUR - Burbank
4209 West Empire Drive
 Burbank, CA 91505
CLT - Charlotte
4732 West Blvd.
 Suite H
 Charlotte, NC 28208
DCA - Washington,DC
106 Air Cargo Road
 Washington, DC 20001
DEN - Denver
7850 Henry B. Combs Parkway
 Denver, CO 80249
DFW - Dallas Fort Worth
1910 W. Airfield Drive
 Bldg. B Suite 200
 DFW Airport, TX 75261
DTW - Detriot
31705 East Service Drive
 Building 530
 Detroit, MI 48242
DTW-P - Romulus
Detroit Metro Airport
 Building 514 Door 14
 Romulus, MI 48174
EWR - Newark
Newark Liberty International Airport
 3 Brewster Road
 Terminal A, Ramp 18
 Gate 30
 Newark, NJ 07114
HPN - White Plains
240 Airport Road
 Hanger  C1, 2nd Floor
 White Plains, NY 10604
JFK - Jamaica
JFK International Airport
 Building 151
 East Hangar Road Room 283
 Jamaica, NY 11431
LGA - Flushing
Hangar 7 North Drive
 Bowery Bay Blvd
 Flushing, NY 11371
MCI - Kansas City
716 Mexico City Ave.
 Kansas City, MO 64154
MDW - Chicago
5923 S. Central Ave
 Signature Flight Support Bldg.
 Chicago, IL 60638
MSP - St Paul
4300 Glumack Drive
 Terminal 1 - Lindbergh
 Suite E-1380
 St. Paul, MN 55111
MSP-P - Minneapolis
Hangar Front Desk
 7500 Airline Dr.
 Building C
 Minneapolis, MN 55450
MSY - New Orleans
 900 Airline Drive
 Room C102-130 Gate C2
 Kenner, LA 70062
NAS - Nassau
Lynden Pindling Int'l Aiport
 Windsor Field Road
 Suite B1-519
 Nassau, BS
OMA - Omaha
1817 Fort Ct.
 Omaha, NE 68110
PHL - Philadelphia
10 Tinicum Island Road
 Cargo City, Building C2 Suite 10
 Philadelphia, PA 19153
PHX - Phoenix
1301 S 27th Street
 Bay 6
 Phoenix, AZ 85034
RNO - Reno
2890 Vassar Street
 Suite 15A
 Reno, NV 89502
RSW - Fort Myers
1100 Terminal Access Road
 Room 1D49
 Fort Myers, FL 33913
SLC - Salt Lake City
3431 South 500 West
 Suite C
 South Salt Lake City, UT 84115
TTN - Trenton
150 Control Tower Road
 Hanger C5
 Trenton, NJ 08628

*Scott Carullo*
Technical Operations
Florida High Speed Internet
(321) 205-1100 x102 <(321)%20205-1100>
<http://twitter.com/flhsi>

<https://twitter.com/flhsi> <https://facebook.com/flhighspeed>



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Prayers for Mac Dearman

[Judd Dare]

You're in our thoughts and prayers Mac.  You know that you've been a great
help to many of us over the years, don't hesitate to ask if there is
anything at all we can do to help.

Judd

On Apr 17, 2017 10:57 AM, "John Scrivner"  wrote:

> I am certain he does not want any big attention about this but I am
> posting it anyway. Mac Dearman is having heart bypass surgery this morning.
> I know many of you know Mac on here so please say a prayer for an old
> friend to be healed. Mac was one of the founding members of WISPA and led
> the efforts to put Mississippi and Louisiana back together post-Katrina. He
> is still operating his WISP in Rayville, LA and he is a dear friend to me
> and many others.
> Thank you,
> John Scrivner
>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Static IP Pricing

[Judd Dare]

Typical cost is around $1-2/IP/Month with various fiber providers.

I've been planning to charge something like $10-20/IP/Mo for commercial in
order to only sell to people who really need it.

On Wed, Feb 1, 2017 at 7:22 PM, Colton Conor  wrote:

> How much do you charge business customers for static IPs?
>
> Comcast Business class cable internet charges
>  *1 - $14.95/mo.*
> * 5 - $19.95/mo*
> * 13 - $34.95/mo*.
>
> What do fiber providers charge?
>
> I have a potential client that currently has a /27 with his current
> provider, and would like at least a /27 or preferably a /26 from us.
>
> We only have a /21 worth of space from ARIN.
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Switch causing packet loss?

[Judd Dare]

Just to follow up on this.  I'm working on a network at the moment,
diagnosing port issues on the Netonix. We had some bad crimps (I'm 6000
miles away) and we've been seeing some CRC errors and intermittent
connection loss on AF5x links.  Pretty sure it's the ethernet connections
and finally getting 1G connections instead of 100M like we've had the last
few weeks.

Anyway, while in the Netonix, I notice the UBNT 100M AP's are running at
100M with flow control negotiated by default.  The AF5x's are not flow
control enabled and are running at GigE.  I won't claim this is optimal,
because I still haven't fine tuned this network, work in progress.

But there is a thread here where UBNT chimed in and said they suggest flow
control on AF5x, etc.

I think the need for flow control may vary by switch manufacturer and
ethernet chipset as well as by implementation from the vendor.  So YMMV,
try some FC and see what happens.

https://community.ubnt.com/t5/airFiber/Flow-Control-is-Off/m-p/1157296

On Mon, Nov 7, 2016 at 9:50 AM, Josh Reynolds <j...@kyneticwifi.com> wrote:

> In addition, imagine the following scenario:
>
> 8 port switch at a tower. Gigabit Ethernet port. 7 ports on the switch,
> all have 100Mbps links to APs.
>
> Buffer architecture is a shared memory design, with say 4MB available.
>
> Do the math. The buffer on that switch is going to fill up very quickly,
> increasing latency across the board with tons of retransmissions upstream
> due to the lost data.
>
> Sadly, this is every switch in the WISP space!
>
> Switches are needed in this scenario that:
> (A) Are managed
> (B) have sufficient per port buffers
> (C) are dscp / tos aware
> [Optionally]
> (D) support buffer monitoring via SNMP, including queue drops
>
> On Nov 7, 2016 10:39 AM, "Josh Reynolds" <j...@kyneticwifi.com> wrote:
>
>> I would agree, but sadly WISP networks are full of 100Mbps links AND a
>> ton of variable bandwidth ptp and ptmp links.
>>
>> You will have to buffer to have any kind of meaningful throughput,
>> otherwise Bandwidth Delay Product calculations will drive your throughout
>> into the dirt.
>>
>> Buffer BLOAT is bad. Buffering is not inherently bad, and is often
>> necessary.
>>
>> On Nov 7, 2016 10:35 AM, "Fred Goldstein" <f...@interisle.net> wrote:
>>
>>> On 11/7/2016 11:05 AM, Josh Reynolds wrote:
>>>
>>> Sorry, correction layer 4. TCP slow start and window sizing.
>>>
>>> Allowing l2 to control your drops in a willy nilly fashion though is not
>>> a good idea... And random "pauses" on your backbone is also a poor idea.
>>>
>>> The idea is to smooth out the flow end to end; it's the big bursts that
>>> cause trouble.
>>>
>>> I'm of the opinion that WISP networks likely need to move to deep buffer
>>> data center switch designs, simply because of the number of variable speed
>>> links.
>>>
>>>
>>> No, I prefer the opposite. Bufferbloat is bad! The math shows that you
>>> basically don't need a buffer bigger than 10 packets or so. But with QoS
>>> classmarking, you may need multiple buffers.
>>>
>>> On Nov 7, 2016 9:53 AM, "Fred Goldstein" <f...@interisle.net> wrote:
>>>
>>>> On 11/7/2016 10:40 AM, Josh Reynolds wrote:
>>>>
>>>> Negative, layer2 flow control is an axe when you need a scalpel. Turn
>>>> it off everywhere!
>>>>
>>>> Layer3 has automatic mechanisms to help handle bandwidth saturation,
>>>> and packet loss is part of that process. Furthermore, proper ToS/DSCP
>>>> queueing is equally important.
>>>>
>>>>
>>>> Well, technically no, Layer 3 has NO mechanisms to deal with capacity.
>>>> It was a known issue among the network working group members in 1973 and a
>>>> known issue in 1974 when TCP v1 was written, but the team had turned over
>>>> by 1978 when TCP/IPv4 came out, and that group forgot about it until 1986
>>>> when things fell apart. The temporary short-term not very good fix was in
>>>> layer 4 (TCP Slow Start) and that doesn't even apply to all streaming,
>>>> though many do cooperate. Of course it was "good enough", so 30 years later
>>>> it is taken as gospel. TCP/IP is the *chabuduo *of protocol stacks.
>>>>
>>>> There could be issues with using flow control on the Ethernet port, but
>>>> really flow control should have been part of every layer. Loss should
>>>> generally be localized.
>>>>
>>>> On Nov 7, 201

Re: [WISPA] Switch causing packet loss?

[Judd Dare]

Not an expert at this level of switching, but my understanding, as your
suggesting is to enable Flow Control on the ports, possibly more on the 1G
ports because they are the bottle neck.  If the 10G port is receiving full
speed and passing on to a 1G port which can't pass fast enough, then the
buffers fill up instantly.

If flow control is enabled, it will signal to the 10G port that the buffers
are full and things should pause while the 1G port catches up.

I've read similar examples between Netonix and AirFibers.  I forget which
devices needed the flow control enabled on the switch, but it seems like it
was the slower port, thus allowing the slow port to signal when their
buffers were full.

I don't remember exactly which devices should have flow control enabled to
avoid the problems, but this sounds like one of those cases.

Definitely interested in better understanding what to do here.

On Mon, Nov 7, 2016 at 8:52 AM, Fred Goldstein <f...@interisle.net> wrote:

> On 11/7/2016 10:40 AM, Josh Reynolds wrote:
>
> Negative, layer2 flow control is an axe when you need a scalpel. Turn it
> off everywhere!
>
> Layer3 has automatic mechanisms to help handle bandwidth saturation, and
> packet loss is part of that process. Furthermore, proper ToS/DSCP queueing
> is equally important.
>
>
> Well, technically no, Layer 3 has NO mechanisms to deal with capacity. It
> was a known issue among the network working group members in 1973 and a
> known issue in 1974 when TCP v1 was written, but the team had turned over
> by 1978 when TCP/IPv4 came out, and that group forgot about it until 1986
> when things fell apart. The temporary short-term not very good fix was in
> layer 4 (TCP Slow Start) and that doesn't even apply to all streaming,
> though many do cooperate. Of course it was "good enough", so 30 years later
> it is taken as gospel. TCP/IP is the *chabuduo *of protocol stacks.
>
> There could be issues with using flow control on the Ethernet port, but
> really flow control should have been part of every layer. Loss should
> generally be localized.
>
> On Nov 7, 2016 9:36 AM, "Judd Dare" <judd.d...@gmail.com> wrote:
>
>> So you're saying, make sure Flow Control is enabled on the ports?
>>
>> On Mon, Nov 7, 2016 at 8:22 AM, Josh Reynolds <j...@kyneticwifi.com>
>> wrote:
>>
>>> Microbursts causing buffer drops on egress ports to non-10G capable
>>> destinations. The switch wants to send data at a rate faster than the 1G
>>> devices can take it in, so it has to buffer it's data on those ports.
>>> Eventually those buffers fill up, and it taildrops traffic. TCP flow
>>> control takes over and eventually slows the transfer rate by reducing
>>> window size. It doesn't matter if its only sending 100M of data, its the
>>> RATE that it is sending the data.
>>>
>>> On Nov 7, 2016 8:58 AM, "TJ Trout" <t...@voltbb.com> wrote:
>>>
>>>> I have a 10G switch that is switching everything of mine at my NOC,
>>>> including peers, router wan, router lan, uplink to tower, etc
>>>>
>>>> During peak traffic periods ~2gbps I'm seeing 1% packet loss and
>>>> throughput will drop to 0 for just a second and resume normal for a few
>>>> minutes before dropping back to zero for just a second. doesn't seem to be
>>>> affecting the wan side of my router which connects to peers through the
>>>> same switch. Doesn't happen during the day with low periods of traffic.
>>>>
>>>> I've enabled / disabled STP, Flow control.
>>>>
>>>> I believe I've isolated it to not be a single port, possibly have a bad
>>>> switch but that seems hard to believe...
>>>>
>>>> Port isn't flapping, getting small amounts of fcs errors on receive and
>>>> lots of length errors but i think those shouldn't be a problem?
>>>>
>>>> It's an IBM G8124 10G switch
>>>>
>>>> Ideas?
>>>>
>>>> ___
>>>> Wireless mailing list
>>>> Wireless@wispa.org
>>>> http://lists.wispa.org/mailman/listinfo/wireless
>>>>
>>>>
>>> ___
>>> Wireless mailing list
>>> Wireless@wispa.org
>>> http://lists.wispa.org/mailman/listinfo/wireless
>>>
>>>
>>
>> ___
>> Wireless mailing list
>> Wireless@wispa.org
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>>
>
> ___
> Wireless mailing 
> listWireless@wispa.orghttp://lists.wispa.org/mailman/listinfo/wireless
>
>
>
> --
>  Fred R. Goldstein  k1iofred "at" interisle.net
>  Interisle Consulting Group
>  +1 617 795 2701
>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Switch causing packet loss?

[Judd Dare]

So you're saying, make sure Flow Control is enabled on the ports?

On Mon, Nov 7, 2016 at 8:22 AM, Josh Reynolds  wrote:

> Microbursts causing buffer drops on egress ports to non-10G capable
> destinations. The switch wants to send data at a rate faster than the 1G
> devices can take it in, so it has to buffer it's data on those ports.
> Eventually those buffers fill up, and it taildrops traffic. TCP flow
> control takes over and eventually slows the transfer rate by reducing
> window size. It doesn't matter if its only sending 100M of data, its the
> RATE that it is sending the data.
>
> On Nov 7, 2016 8:58 AM, "TJ Trout"  wrote:
>
>> I have a 10G switch that is switching everything of mine at my NOC,
>> including peers, router wan, router lan, uplink to tower, etc
>>
>> During peak traffic periods ~2gbps I'm seeing 1% packet loss and
>> throughput will drop to 0 for just a second and resume normal for a few
>> minutes before dropping back to zero for just a second. doesn't seem to be
>> affecting the wan side of my router which connects to peers through the
>> same switch. Doesn't happen during the day with low periods of traffic.
>>
>> I've enabled / disabled STP, Flow control.
>>
>> I believe I've isolated it to not be a single port, possibly have a bad
>> switch but that seems hard to believe...
>>
>> Port isn't flapping, getting small amounts of fcs errors on receive and
>> lots of length errors but i think those shouldn't be a problem?
>>
>> It's an IBM G8124 10G switch
>>
>> Ideas?
>>
>> ___
>> Wireless mailing list
>> Wireless@wispa.org
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] 60 Ghz gear

[Judd Dare]

Make sure your mcs rate is set to auto, not locked at one speed.

Judd

On Aug 30, 2016 3:23 PM, "Dan Parrish"  wrote:

> Yeah, in a PTP situation, we get more than 500mbits/sec on the workbench.
> Replace one end with the "AP" and we get 25-30mbits/sec. I've adjusted the
> transmit power to compensate for the difference in gain. Seems like there's
> something not working correctly.
>
> --danp
>
>
>
> On 08/26/2016 04:03 PM, Faisal Imtiaz wrote:
>
> You had something not setup right.
>
> We have seen arguments about 600meg vs 800meg vs 1g type discussions.. but
> if you were seeing 30... then you had something totally off...
>
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
>
> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
>
> --
>
> *From: *"Dan Parrish"  
> *To: *"WISPA General List"  
> *Sent: *Friday, August 26, 2016 5:55:01 PM
> *Subject: *Re: [WISPA] 60 Ghz gear
>
> We've gotten some this week as well. Initial tests weren't too impressive,
> but I'm sure I can improve the RF alignment. At -55 on both sides, I was
> only able to pass about 30mbits/sec, which was much lower than I
> anticipated. How is everyone else faring in their tests? Please include
> RSSI and TCP performance if possible.
>
> --danp
>
>
>
> On 08/25/2016 03:13 PM, Chris Ruschmann wrote:
>
> Just got these in, smaller than I thought they would be…
>
>
>
> Sector on the left, CPE on the right. I’ll get them setup shortly.
>
>
> ___
> Wireless mailing 
> listWireless@wispa.orghttp://lists.wispa.org/mailman/listinfo/wireless
>
>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
>
> ___
> Wireless mailing 
> listWireless@wispa.orghttp://lists.wispa.org/mailman/listinfo/wireless
>
>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Resends of TowerCoverage Website Submissions

[Judd Dare]

I've been telling Jim the same thing for a long time. You've worded it
better than me. Their UI/UX needs some serious outside help, but while they
claim to be open to suggestions, they won't hire the help, or maybe they
just don't understand the difference they'd achieve with a quality user
experience.

I think they are stuck in the 90's when it comes to web design and layout.

I don't foresee this changing anytime soon.

Judd

On Jun 29, 2016 10:54 AM, "James Wilson"  wrote:

> I don't have all of the answers, but there are people that do web
> page design to make it more intuitive.  Here are some examples:
>
>
> http://www.creativebloq.com/web-design/5-ways-make-your-web-designs-more-intuitive-91516938
>
> http://www.designforfounders.com/web-app-ux/
>
> I don't know how to do this, but there are consultants that do.  The
> functionality of TowerCoverage is there, but the user interface is lacking.
>
> You can complain about people not reading directions or you can make its
> easier to read the directions - or make the flow so that they don't even
> need to read the directions.  The best sites guide people along with
> different pages for different steps - don't put too much information on
> each page.
>
> We spend an inordinate amount of time with people that just don't 'get'
> what the EUS form wants them to do.  We find that they don't why they need
> to move the pin to their location or have no idea what Captcha is.
>
> We could spend the money to have someone write (and maintain) a page to
> work with the API, but that's what we pay TowerCoverage for.
>
> The back end is there, now it just needs a better user interface.  Often
> the people writing web site backends are not the same people writing the
> front end, it's a whole different way of thinking.
>
> We give you the ability to edit the text in the landing page they get to
> explain what happens next.  You can also edit the text on the title of the
> iframe.  If you’re using the API and have your own form then obviously you
> can explain how it works there.  Not much we can do about users that don’t
> read the instructions and message text before just hitting back and
> resubmitting.
>
>
>
> We’re open to suggestions on better ways to do things.
>
>
>
> Jim
>
>
>
> *From:* wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] *On
> Behalf Of *James Wilson
> *Sent:* Wednesday, June 29, 2016 10:00 AM
> *To:* WISPA General List 
> *Subject:* Re: [WISPA] Resends of TowerCoverage Website Submissions
>
>
>
> Could be the prospective customer is expecting an instant reply about
> service availability and fills out the form and retries.
>
> I've watched people fill out the form.  It's unintuitive and confuses a
> lot of people.
>
> On Jun 29, 2016 10:50 AM, "Jim Patient"  wrote:
>
> Take a look at your EUS data.  Lanich hit submit 3 times about 30 seconds
> apart.   Did you get multiple emails for Cutlip EUS? Cutlip has a single
> submission.
>
>
>
> When a customer goes back to submit again they would need to re-captia so
> it’s not like they can just click and click again.
>
>
>
> Jim
>
>
>
> *From:* wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] *On
> Behalf Of *Josh Luthman
> *Sent:* Tuesday, June 28, 2016 9:05 PM
> *To:* WISPA General List 
> *Subject:* Re: [WISPA] Resends of TowerCoverage Website Submissions
>
>
>
> Here's my example:
>
> http://imgur.com/PyRgVoh
>
>
>
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
>
> On Tue, Jun 28, 2016 at 10:03 PM, Adair Winter <
> ada...@amarillowireless.net> wrote:
>
> We've never seen that.
>
> On Jun 28, 2016 8:59 PM, "Josh Luthman" 
> wrote:
>
> Is anyone else getting duplicates or triplicates of the email
> notifications?  It seems to come and go.  I really doubt customers are
> clicking it fast and it seems to come and go.  There is only one API push
> which I believe confirms customers are only clicking it once.
>
>
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>

Re: [WISPA] Baicells - who's deployed it?

[Judd Dare]

Azure is far from reliable.
On Jun 19, 2016 11:03 AM, "Adair Winter" 
wrote:

> No, just authentication. Or at least that's the way it should be.
> They are hosting in azure and are supposed to have some good redundancy .
>
> On Sun, Jun 19, 2016 at 12:01 PM,  wrote:
>
>> So if their hosted core takes a sh*t, all your users are down?
>>
>> On Jun 19, 2016, at 09:57, Adair Winter 
>> wrote:
>>
>> probably possible but since it makes some sort of ipsec connection to
>> their hosted core, it would be more difficult.
>>
>> The other way around works great though.
>>
>> On Sun, Jun 19, 2016 at 11:53 AM, Matt Hoppes <
>> mattli...@rivervalleyinternet.net> wrote:
>>
>>> Since LTE is a standard  I wonder if you could hook a Telrad eNB to
>>> the baicells EPC??
>>>
>>> *gear spinning*
>>>
>>> On Jun 19, 2016, at 12:20, Adair Winter 
>>> wrote:
>>>
>>> Baicells is going to have cheaper hardware but there will be some trade
>>> offs to other vendors.
>>> for example, no 4x4, do dual carrier, etc.
>>> Also you'll pay per user per month to use their core unless you already
>>> have one. so look at the long term when pricing.
>>>
>>> On Sun, Jun 19, 2016 at 11:19 AM, Josh Luthman <
>>> j...@imaginenetworksllc.com> wrote:
>>>
 Baicells referred me to a distributor for pricing.  I asked last week.

 Josh Luthman
 Office: 937-552-2340
 Direct: 937-552-2343
 1100 Wayne St
 Suite 1337
 Troy, OH 45373
 On Jun 19, 2016 12:18 PM, "Matt Hoppes" <
 mattli...@rivervalleyinternet.net> wrote:

> I've said too much. I haven't said enough.
>
> Ask Patrick for more details on pricing.
>
> On Jun 19, 2016, at 11:59, CBB - Jay Fuller 
> wrote:
>
>
> He said "real" good ;)
>
>
> - Original Message -
> *From:* Matt Hoppes 
> *To:* WISPA General List 
> *Sent:* Saturday, June 18, 2016 7:18 AM
> *Subject:* Re: [WISPA] Baicells - who's deployed it?
>
> As opposed to bad? :P.
>
> On Jun 18, 2016, at 08:03, Josh Luthman 
> wrote:
>
> "Good"?
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> On Jun 18, 2016 8:02 AM, "Matt Hoppes" <
> mattli...@rivervalleyinternet.net> wrote:
>
>> True. It's good though. Real good.
>>
>> On Jun 18, 2016, at 02:24, Chris Ruschmann 
>> wrote:
>>
>> We all had to sign an NDA. So I'll let the baicells guys answer that
>> one.
>> On Jun 17, 2016 9:05 PM,  wrote:
>>
>> Whats the pricing like?
>>
>> On Jun 17, 2016, at 19:12, Matt Hoppes <
>> mattli...@rivervalleyinternet.net> wrote:
>>
>> https://www.facebook.com/thewirelessninja/videos/1017353051688688/
>>
>> On Jun 17, 2016, at 21:07, Christian Palecek 
>> wrote:
>>
>> Ours*  brain fart.
>>
>> We are deploying in one of our most difficult nlos areas, and another
>> in a small town center so we'll have a variety of testing.
>>
>>
>>
>> Sent from my Verizon, Samsung Galaxy smartphone
>>
>>  Original message 
>> From: Christian Palecek 
>> Date: 6/17/16 7:02 PM (GMT-07:00)
>> To: WISPA General List 
>> Subject: Re: [WISPA] Baicells - who's deployed it?
>>
>> We'll have ares up pretty quick, don't have a SU yet though.  Only
>> getting one I guess.
>>
>>
>>
>> Sent from my Verizon, Samsung Galaxy smartphone
>>
>>  Original message 
>> From: Chris Ruschmann 
>> Date: 6/17/16 3:58 PM (GMT-07:00)
>> To: WISPA General List 
>> Subject: Re: [WISPA] Baicells - who's deployed it?
>>
>> I should have mine deployed next week as well. Just received the gear
>> today.
>> On Jun 17, 2016 1:11 PM, "Mike Francis" 
>> wrote:
>>
>>> By: Douglas Adams
>>> "Man [has] always assumed that he was more intelligent than dolphins
>>> because he had achieved so much-the wheel, New York, wars and so 
>>> on-while
>>> all the dolphins had ever done was muck about in the water having a good
>>> time. But conversely, the dolphins had always believed that they were 
>>> far
>>> more intelligent than man-for precisely the same reason."
>>>
>>> John Michael Francis II
>>> JMF Solutions, Inc
>>> Wavefly Technologies
>>> Internet - Voip - Cloud
>>> 251-517-5069
>>> http://jmfsolutions.net
>>> http://wavefly.com
>>>
>>> On 6/17/2016 4:06 PM, Josh Luthman wrote:

Re: [WISPA] Any IgniteNet MetroLinq customers out there

[Judd Dare]

Try a different power brick.
On Jun 20, 2016 9:47 PM, "Chadwick Wachs"  wrote:

> One end is brick (the end that is having issues) and the other end is off
> a Netonix.
>
> On Mon, Jun 20, 2016 at 9:37 PM, Chris Ruschmann 
> wrote:
>
>> How are you powering them? Power brick or switch?
>> On Jun 20, 2016 7:35 PM, "Faisal Imtiaz" 
>> wrote:
>>
>> Are there the only two radios you have ? maybe there is a physical
>> hardware issue with one of the radios..
>>
>> we have seen something similar with on another link we were working on
>> for another WISP.  No conclusions yet, but one radio is definitely doing
>> hokey stuff...They have spares, will be trying another pair (the radios
>> linked up on the bench, but would not link nor go thru the alignment
>> process on a 400m link).
>>
>> Regards.
>>
>> Faisal Imtiaz
>> Snappy Internet & Telecom
>> 7266 SW 48 Street
>> Miami, FL 33155
>> Tel: 305 663 5518 x 232
>>
>> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
>>
>> --
>>
>> *From: *"Chadwick Wachs" 
>> *To: *"WISPA General List" 
>> *Sent: *Monday, June 20, 2016 12:47:43 PM
>> *Subject: *Re: [WISPA] Any IgniteNet MetroLinq customers out there
>>
>> Update to all on this.  We are running MCS1, the latest public firmware
>> and contacted Ignite support. They are responsive.  We did get the 60 GHz
>> radios to link up once - for about 30 minutes. Then, the 60 GHz radio on
>> the client end died. Can't open the 60 GHz aiming tool and the dashboard
>> acts like the radio is off.
>> We have been through a number of reboots to get the 60 GHz radio to wake
>> back up. No dice. Ignite is aware of the issue, acknowledges I am not the
>> only one who has seen this but so far no solutions.  Last night, the 5 GHz
>> link between these two radios died at 3am (not a production link).  We lost
>> all wireless and ethernet access to the client radio until a reboot.
>>
>> After rebooting, the 5 GHz would not pass any traffic until the 60 GHz
>> radios were turned off in the interface on both ends.  Both ends are on big
>> UPSs so I don't think power is the issue, I think there is buggy firmware.
>> While I have *some* time to deal with testing firmware and trouble
>> shooting, I don't have unlimited time to do this.
>>
>> It is back running on 5 GHz. It is aimed well - we did get a solid 60 GHz
>> signal but we never got the 60's to link back up after one mysteriously
>> stopped.
>>
>>
>>
>> On Sun, Jun 19, 2016 at 12:37 AM, Rob Genovesi 
>> wrote:
>>
>>> Aiming takes patience, the scopes aren't perfect but a huge help.  We
>>> found that turning off auto MCS and using fixed lower rate helped a
>>> lot.  Make sure you have the newest firmware, I believe there are more
>>> updates coming out soon as well.  IgniteNet support was responsive and
>>> very helpful when we had questions.
>>>
>>>
>>> Rob Genovesi • Coastside.Net • Owner
>>> 650-712-5900 • 525B Obispo Rd • Half Moon Bay CA
>>>
>>> On Wed, Jun 15, 2016 at 4:55 PM, Chadwick Wachs 
>>> wrote:
>>> > I have been trying for a couple days to get a new PTP60-35 60 GHz link
>>> up
>>> > and running with no luck. Looking for some help / suggestions from
>>> anyone
>>> > who has been successful getting links up. The 5 GHz link is working
>>> but 60
>>> > never trains up. I bought the spotting scopes and each end is dead
>>> center.
>>> > Good old fashioned up/down/left/right aiming methods do not seem to
>>> work
>>> > either and IgniteNet is lacking in the support department.
>>> >
>>> > Anyone want to contact me off list if you have any suggestions on what
>>> > worked for you?
>>> >
>>> > Thanks,
>>> > Chad
>>> >
>>> > ___
>>> > Wireless mailing list
>>> > Wireless@wispa.org
>>> > http://lists.wispa.org/mailman/listinfo/wireless
>>> >
>>> ___
>>> Wireless mailing list
>>> Wireless@wispa.org
>>> http://lists.wispa.org/mailman/listinfo/wireless
>>>
>>
>>
>>
>> --
>>
>> 
>>
>> AU Wireless (Golden Wireless)
>>
>> www.AUwireless.net 
>>
>> Facebook  |
>> @auwirelessnet 
>>
>> ___
>> Wireless mailing list
>> Wireless@wispa.org
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>>
>> ___
>> Wireless mailing list
>> Wireless@wispa.org
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>>
>> ___
>> Wireless mailing list
>> Wireless@wispa.org
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>>
>
>
> --
>
> 
>
> AU Wireless (Golden Wireless)
>
> www.AUwireless.net 

Re: [WISPA] Any IgniteNet MetroLinq customers out there

[Judd Dare]

Almost sounds like a low voltage issue or faulty boards internally.
On Jun 20, 2016 10:48 AM, "Chadwick Wachs"  wrote:

> Update to all on this.  We are running MCS1, the latest public firmware
> and contacted Ignite support. They are responsive.  We did get the 60 GHz
> radios to link up once - for about 30 minutes. Then, the 60 GHz radio on
> the client end died. Can't open the 60 GHz aiming tool and the dashboard
> acts like the radio is off.
>
> We have been through a number of reboots to get the 60 GHz radio to wake
> back up. No dice. Ignite is aware of the issue, acknowledges I am not the
> only one who has seen this but so far no solutions.  Last night, the 5 GHz
> link between these two radios died at 3am (not a production link).  We lost
> all wireless and ethernet access to the client radio until a reboot.
>
> After rebooting, the 5 GHz would not pass any traffic until the 60 GHz
> radios were turned off in the interface on both ends.  Both ends are on big
> UPSs so I don't think power is the issue, I think there is buggy firmware.
> While I have *some* time to deal with testing firmware and trouble
> shooting, I don't have unlimited time to do this.
>
> It is back running on 5 GHz. It is aimed well - we did get a solid 60 GHz
> signal but we never got the 60's to link back up after one mysteriously
> stopped.
>
>
>
> On Sun, Jun 19, 2016 at 12:37 AM, Rob Genovesi 
> wrote:
>
>> Aiming takes patience, the scopes aren't perfect but a huge help.  We
>> found that turning off auto MCS and using fixed lower rate helped a
>> lot.  Make sure you have the newest firmware, I believe there are more
>> updates coming out soon as well.  IgniteNet support was responsive and
>> very helpful when we had questions.
>>
>>
>> Rob Genovesi • Coastside.Net • Owner
>> 650-712-5900 • 525B Obispo Rd • Half Moon Bay CA
>>
>> On Wed, Jun 15, 2016 at 4:55 PM, Chadwick Wachs 
>> wrote:
>> > I have been trying for a couple days to get a new PTP60-35 60 GHz link
>> up
>> > and running with no luck. Looking for some help / suggestions from
>> anyone
>> > who has been successful getting links up. The 5 GHz link is working but
>> 60
>> > never trains up. I bought the spotting scopes and each end is dead
>> center.
>> > Good old fashioned up/down/left/right aiming methods do not seem to work
>> > either and IgniteNet is lacking in the support department.
>> >
>> > Anyone want to contact me off list if you have any suggestions on what
>> > worked for you?
>> >
>> > Thanks,
>> > Chad
>> >
>> > ___
>> > Wireless mailing list
>> > Wireless@wispa.org
>> > http://lists.wispa.org/mailman/listinfo/wireless
>> >
>> ___
>> Wireless mailing list
>> Wireless@wispa.org
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>
>
>
> --
>
> 
>
> AU Wireless (Golden Wireless)
>
> www.AUwireless.net 
>
> *Facebook * |
> @auwirelessnet 
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless