any improvements is a great step forward on the existing platform which is great just FYI With 3 towers on mt tops that all face inward to the metro GPS is a must and it makes
frequency planning easy and scalable to do other things with.

On 10/4/2014 9:53 AM, Bill Prince via Af wrote:
Depends on the load on both that SM and the other SMs. It will take time slots, so it will have an impact on aggregate throughput, but it will have no impact on how other SMs modulate.
bp
On 10/3/2014 10:30 PM, That One Guy via Af wrote:
if you have a 10mb unit running in mimo a is it going to pull 10 mb or whatever mimo a correlates to on that unit? if it has less throughput is it still consuming 10mb of ap capacity? If it still pulls 10mb, how much of the ap aggregate capacity is consumed?

On Fri, Oct 3, 2014 at 11:46 PM, Bill Prince via Af <af@afmug.com <mailto:af@afmug.com>> wrote:

    In theory, if an SM has to do MIMO-A, the total throughput would
    be half of what you could do in dual payload mode.  It should not
    cause another SM to modulate down at all.

    bp

    On 10/3/2014 9:41 PM, That One Guy via Af wrote:
    how bad is the overall throughput hit in MIMO-A, did you notice
    if it cause the other SMs to modulate down?

    On Fri, Oct 3, 2014 at 11:34 PM, George Skorup (Cyber
    Broadcasting) via Af <af@afmug.com <mailto:af@afmug.com>> wrote:

        Yes, I have a sector loaded that needed MIMO-A. And I found
        some minor GUI issues and the Moto binary data GPS bug that
        has now been fixed in build 32. But obviously I don't have
        things configured like others, such as PPPoE, NAT, VLANs,
        etc. I just do bridge, no auth/RADIUS, very few APs doing
        VLAN. So I would encourage more folks to test it out and
        give feedback to Cambium so they can get any remaining
        issues ironed out and get 13.2 official out. From the
        improvements I've seen so far, I want it on every 450 AP and
        SM, right meow!


        On 10/3/2014 9:55 PM, Bill Prince via Af wrote:
        On 13.2 already George?ן¿½ I am happy to let you others get
        the bleeding done before I step over the edge.

        I think I will wait about a week before I give it a rip;
        and then only only low-population APs.


        bp
        On 10/3/2014 6:28 PM, George Skorup (Cyber Broadcasting)
        via Af wrote:
        I was just discussing with Aaron offlist about build 32
        AutoSync selecting the on-board GPS instead of timing port
        at boot. The deployed AP I have been testing on has a
        Parasitic SyncPipe, no power port sync and the iGPS on
        this AP usually always has a good lock. Prior to build 32,
        it would always boot up and use the timing port. Now build
        32 wants the on-board at boot, at least every time I've
        had a chance to reboot the AP, which has only been the
        update from build 30 to 32 and one reboot afterwards so far.

        I would like to know if anyone else sees the same thing
        happening with build 32. Maybe it's just me, but I would
        prefer it to come up on the timing port before the
        on-board GPS for tracking GPS status of the attached SyncPipe.

        BTW, I've seen a very nice improvement in 13.2 beta for
        both throughput and session issues during multipath
        events. I think 13.2 is going to be a major leap forward
        for the 450.

        On 10/3/2014 6:19 PM, Aaron Schneider via Af wrote:

        Since the last Open Beta load (Build 30), this also contains:

        ן¿½

          * Fix for negative VC count on home page
          * New OID to see NAT table size in use
          * Fix for Active FTP with NAT
          * PPPoE Control Message High Priority with VLAN Enabled

        ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ Added missing OIDs for IPv6
        packet filtering configuration

        ן¿½

        We are very close to release, so please give this load a try!

        ן¿½

        Regards,

        ן¿½

        -Aaron

        ן¿½

        *From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of
        *John Mehling via Af
        *Sent:* Friday, October 03, 2014 6:10 PM
        *To:* af@afmug.com <mailto:af@afmug.com>
        *Subject:* [AFMUG] 13.2 (Build32) Beta Software is Now
        Available!ן¿½ן¿½

        ן¿½

        Folks,

        Software version 13.2(Build32) has been added to the
        Cambium Open Beta program for PMP450, PMP430, and PTP230.

        Please go
        here:ן¿½https://support.cambiumnetworks.com/betaן¿½if you
        would like to test the new load and offer feedback on the
        Beta Forum.

        ן¿½Fixes in this release include:

        ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ Fix for Motorola
        Binary GPS based devices (CMM2, SyncPipe, etc)

        ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ן¿½ Fix for PTP450
        link test with small packets causing session drop and/or
        invalid readings

        ן¿½

        This version also adds OID support for IPv6 packet filtering.

        As always, we look forward to your feedback.ן¿½ Thank you!

        -John

        ן¿½

        ן¿½

        *John Mehling*

        Senior Engineer - Support


        *Cambium Networks*
        3800 Golf Rd.,ן¿½ Suite 360

        Rolling Meadows, IL 60008

        www.cambiumnetworks.com <http://www.cambiumnetworks.com>


        v_large_blue_noBG.png

        ן¿½







-- All parts should go together without forcing. You must remember
    that the parts you are reassembling were disassembled by you.
    Therefore, if you can't get them together again, there must be a
    reason. By all means, do not use a hammer. -- IBM maintenance
    manual, 1925




--
All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925


--

Reply via email to