Define too expensive...

If operators can buy it, sell a service and be profitable than I don't
think it's too expensive.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Nov 9, 2015 10:25 AM, "Mathew Howard" <[email protected]> wrote:

> I can't disagree that PMP450 is too expensive, but slow? ...compared to
> what? and what is less buggy than ePMP, other than PMP450?
>
> On Mon, Nov 9, 2015 at 8:47 AM, Josh Luthman <[email protected]>
> wrote:
>
>> like nearly everything from
>> Cambium..it is too expensive and soo low Bandwith for the customers.
>>
>>
>> Too expensive or slow :P
>>
>> Josh Luthman
>> Office: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> Suite 1337
>> Troy, OH 45373
>> On Nov 9, 2015 9:44 AM, "Adam Moffett" <[email protected]> wrote:
>>
>>> He didn't say ePMP was too expensive, he said it had too many bugs.
>>>
>>> On 11/9/2015 9:40 AM, Josh Luthman wrote:
>>>
>>> Dude he thinks EPMP is way too expensive.  Doesn't read like a very
>>> rational post to me.
>>>
>>> Josh Luthman
>>> Office: 937-552-2340
>>> Direct: 937-552-2343
>>> 1100 Wayne St
>>> Suite 1337
>>> Troy, OH 45373
>>> On Nov 9, 2015 9:35 AM, "Sean Heskett" <[email protected]> wrote:
>>>
>>>> You must be doing something wrong because our experience is the
>>>> complete opposite with PMP450.
>>>>
>>>> What does your noise floor look like?
>>>>
>>>> -Sean
>>>>
>>>> On Sunday, November 8, 2015, Daniel Gerlach < <[email protected]>
>>>> [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]>:
>>>>> > 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]>
>>>>> 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.
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>
>

Reply via email to