So far 3.2.1 looks pretty decent. GUI speed is much improved. I have it
running on a couple DFS and non-DFS sites now.
On 1/5/2017 2:17 PM, Josh Baird wrote:
It's mainly JS (client side) that makes the GUI so dreadful. But, I
think it's improved greatly in 3.x.
On Thu, Jan 5, 2017 at 2:52 PM, Stefan Englhardt <[email protected]
<mailto:[email protected]>> wrote:
I realy would not dare to do this with ePMP. Guess scrolling thru
120 entries with the webinterface will kill the AP ;-)).
*Von:*Af [mailto:[email protected]
<mailto:[email protected]>] *Im Auftrag von *Mathew Howard
*Gesendet:* Donnerstag, 5. Januar 2017 20:27
*An:* af <[email protected] <mailto:[email protected]>>
*Betreff:* Re: [AFMUG] epmp vs 450 comparison
Yes... this isn't airmax we're talking about...
I haven't heard of any problems related to the number of SM's with
ePMP. You're obviously going to run out of capacity if you have
too many, but I imagine if they were all low use connections it'd
handle 120 just fine.
On Thu, Jan 5, 2017 at 1:15 PM, Adam Moffett <[email protected]
<mailto:[email protected]>> wrote:
Right....IMO the number of subscribers the thing can
efficiently handle is basically irrelevant because you'll run
out of capacity before you hit that number. That's probably
true with a lot of stuff these days.
------ Original Message ------
From: "Josh Baird" <[email protected]
<mailto:[email protected]>>
To: "[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
Sent: 1/5/2017 2:08:32 PM
Subject: Re: [AFMUG] epmp vs 450 comparison
We have ePMP AP's with 55 subs that are doing just fine.
Probably won't load any more on it due to high downlink
utilization during peak usage.
On Thu, Jan 5, 2017 at 2:00 PM, Adam Moffett
<[email protected] <mailto:[email protected]>> wrote:
Over 20-30 subs not recommended by whom?
When I talked to Cambium about subscriber density,
they said they've tested with up to 120, but suggested
keeping it under 65. I do have an ePMP AP with 43
SM's at this point, no trouble that I'm aware of. It
hits abou 60% air utilization at peak times.
------ Original Message ------
From: "Trey Scarborough" <[email protected]
<mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
Sent: 1/5/2017 9:21:24 AM
Subject: Re: [AFMUG] epmp vs 450 comparison
Your biggest difference is your throughput per MHZ
your epmp will do less bandwidth in a 20mhz
channel than a 450. he other big difference is
subscriber density. It is not recommended to go
over 20-30 subs per AP on epmp without loss of
performance. I regularly see 450 APs with 70+ subs
per AP. With Medusa I have seen over 130. As far
as the Medusa not being field proven you may not
have field tested it yet, but I know for a fact it
has been tested and running on networks for some
time now and a viable solution.
If you have any more questions feel free to hit me
up off list.
On 1/5/2017 7:36 AM, David Milholen wrote:
The radios on these 2 are entirely different.
One is using std based
radio and the other completely proprietary.
Since framing will be slightly different and
so will processing delay.
The stds based radio gets close to mimicking the
450 series but thats strictly based on Cambium
magic. Capacity and
sustained rates per VC is the where you will
see a difference.
Latency will be very consistent from ap to
sub. PMP450i is where its at.
On 1/4/2017 2:55 PM, That One Guy /sarcasm wrote:
if im running 75/25, epmp is roughly 87mb
capacity, 450 93mb capacity
is this correct?
are efficiencies batter on 450 if
installation is the same? ie, if I
forlifted one AP with 17 epmps to 450,
where would my gains be
assuming everything stays installed in the
same spot. Its not like the
FCC gives 450 any more power than epmp, so
path loss should be the same.
Im looking at this epmp 1000 sector thats
running overall about 64-7%
efficient with 17 subscribers and
wondering what the gain is to move
to 450 (exclude medusa, as its not field
proven)
--
If you only see yourself as part of the
team but you don't see your
team as part of yourself you have already
failed as part of the team.
--
