I can't think of a WISP product that is more feature rich and has fewer problems than Canopy. I'm not sure why we would call the 450 "slow" either. It's exactly the speed it should be for 256QAM and 20mhz.

On 11/9/2015 5:30 AM, Stefan Englhardt wrote:

> and which vendors actually meet that expectation in a consistent manner?

This is a symptom of the WISP-Industry. Most gear is usable but at permanent beta state. I guess Daniel is pissed of as he had other expectations from cambium gear. It is more expensive than Mikrotik and UBNT so it should have less bugs.

An AP with 35 customers which does not work gives some bad phone calls … this is something you dont want to have for christmas.

*Von:*Af [mailto:[email protected]] *Im Auftrag von *Forrest Christian (List Account)
*Gesendet:* Montag, 9. November 2015 10:14
*An:* af <[email protected]>
*Betreff:* Re: [AFMUG] 450 frame utilization and performance issues

Just curious....

What would you consider a reasonable timeline to fix a recently discovered bug, and which vendors actually meet that expectation in a consistent manner?

-forrest

On Sun, Nov 8, 2015 at 10:39 PM, Daniel Gerlach <[email protected] <mailto:[email protected]>> wrote:

    the 450 is a 4 years old pointless product like nearly everything from
    Cambium..it is too expensive and soo low Bandwith for the customers.We
    have thrown it out of the Network..The epmp serie has only bugs( we
    have found last week a new with heavy traffic and more than 35 CPE´s
    on a AP) and Cambium told me that they can not fix it before
    Christmas.



    2015-11-08 4:21 GMT+01:00 Eric Kuhnke <[email protected]
    <mailto:[email protected]>>:
    > Same on any half duplex TDD platform with PtMP and low
    modulation (QPSK)
    > subscribers. If you have a ubnt 5 GHz AP with a bunch of clients
    in 64QAM
    > 3/4 to 64QAM 5/6 and a few are on the air using QPSK 1/2, it's
    going to drag
    > down the performance of that whole radio and sector
    significantly. It can be
    > as much as from 80 Mbps aggregate to 20 Mbps. Looking at the RSL
    thresholds
    > needed to operate at 1X in 450 terms, it sounds like a few of
    those client
    > radios are "just barely hanging on"...
    >
    > On Fri, Nov 6, 2015 at 10:37 AM, George Skorup
    <[email protected] <mailto:[email protected]>> wrote:
    >>
    >> If those 1X and 2X downlink SMs are even moderately active,
    that really
    >> throws a wrench into the sector performance. This is true on
    any PMP
    >> platform. We've seen our fair share of it. We've moved a couple
    back to FSK
    >> which is something I never, ever want to do, but it was
    unfortunately
    >> necessary.
    >>
    >>
    >> On 11/6/2015 11:50 AM, Eric Muehleisen wrote:
    >>>
    >>> We have a few 450 AP's with 30-40 subscribers and have been
    getting
    >>> several slow speed complaints lately. I just chaulked it up to
    issues
    >>> with the SM since the AP rarely got over 20mb/s downlink. We
    upgraded
    >>> to 13.4 recently so we could watch our frame utilization. We
    started
    >>> graphing it over night and as you can see, we are hitting 100% for
    >>> sustained periods of time. During that time the AP is only doing
    >>> approx. 23mb/s. This particular AP has 34 registered SM and the
    >>> majority show 6x and 4x with 4 or 5 SM's at 2x and 1x. The
    performance
    >>> is a major disappointment. Anyone else have similar experiences?
    >>>
    >>> AP configuration: 20mhz channels, 2.5ms frame, 10 miles, 75%
    downlink,
    >>> 3 contention slots.
    >>>
    >>> Attached is a screenshot of the utilization and sector throughput
    >>> calculator from the Capacity Planner R13.
    >>
    >>
    >



--

*Forrest Christian*/CEO, PacketFlux Technologies, Inc./

Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602

[email protected] <mailto:[email protected]> | http://www.packetflux.com <http://www.packetflux.com/>

<http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> <http://twitter.com/@packetflux>


Reply via email to