We are on 0606.04753 firmware. The Sub-Frame 1, SSF 2 had been working great. No issues at all with 5 eNBs running this config. Single Carrier 2x4 is selected.
I saw an increase in upload speeds (which we really needed). Have 50 UE's on one of our eNB's and its running 55Mbit down (AVG) and 2Mbit Upload at night. Matt Carpenter Amarillo Wireless On Sat, Dec 31, 2016 at 4:24 PM, Nathan Anderson <[email protected]> wrote: > Oh, I'm not seeing on the CPE (I wish). I'm just talking about what MCS > the average number of received blocks is at as observed at the eNB. > > > > -- Nathan > > > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Adam Moffett > *Sent:* Saturday, December 31, 2016 9:33 AM > *To:* [email protected] > *Subject:* Re: [Telrad] Uplink capacity > > > > By the way, where are you seeing the MCS on the CPE? > I might be brain dead, but I can't find it. > > We are still fighting upload capacity problems on our more loaded sectors. > > > > To catch y'all up, we are running 15MHz channels and subframe profile 2. > > > > Some observations I have made: > > > > 1. Those eNBs running 6.6 seem to peak out on upload capacity at around > 85% utilization, according to BreezeView. Has anyone else noticed this? > When upload is getting hammered, the KPI graphs flatline uplink utilization > at 85% and it NEVER crosses that line. eNBs on 6.5 will still approach > 100%. Is this just a reporting bug or what? > > > > 2. With the combination of 15MHz channels + subframe profile 2, we seem > lucky if we can ever push a total combined uplink rate of 2Mbit/s from all > attached CPEs. Does this sound right to anyone? This seems very low to > me. And as I said in an earlier post, our retransmits are below 2% and > uplink MCS is staying at 20 or higher > 90% of the time. (I am currently > observing the same eNB as I referenced in that earlier post.) > > > > Also, what are current best practices as of 6.6? With the introduction of > weak UE protection, is it advisable to turn that on and then go back to > EqualRate scheduling? > > > > I have set this particular Compact (30 CPEs) to EqualRate on both down and > up, and activated weak UE @ level 2 with the default MCS indexes for level > 2. It's probably too early to tell, but I don't think this is making a > signficant difference. > > > > -- Nathan > > > > *From:* Nathan Anderson > *Sent:* Thursday, December 22, 2016 12:31 AM > *To:* [email protected] > *Subject:* RE: [Telrad] More CPE8K woes > > > > As a follow-up to the iperf bit, there is an "accept" rule at the top of > the iptables firewall input chain on the EPC for its *management* IP. > Maybe Telrad expects you to run iperf traffic between ENB and EPC across > the management VLAN and not the main EPC interface/bearing VLAN. You > should be able to have iperf explicitly bind to the management interface on > both ends (iperf -B A.B.C.D where A.B.C.D is the management IP for either > the EPC or ENB in question that you are invoking this on) and then on the > client side specify the other end's management IP for the -c parameter. > > > > However, this only works if you don't have 'switching vlan-assignment > epc-access-if-list' defined on your EPC, as we do. If you are using that > for whatever reason (e.g., site-based EPC instead of centralized, although > there are other scenarios), you cannot send management traffic directly > between the EPC and ENB. This isn't being blocked by iptables, but is > something happening at a lower level (something to do with how VLANs are > being tagged and forwarded between the various ports and the internal CPU > port by the switch chip). Telrad may have failed to consider this when > adding the iperf feature. > > > > -- Nathan > > > > *From:* [email protected] [mailto:[email protected] > <[email protected]>] *On Behalf Of *Nathan Anderson > *Sent:* Thursday, December 22, 2016 12:14 AM > *To:* [email protected] > *Subject:* Re: [Telrad] More CPE8K woes > > > > Is it possible to get retransmission rates for uplink? I thought only > downlink stats were available from the eNB (which makes sense, since the > eNB would have no idea how many times each CPE had to retransmit unless the > CPEs were reporting that information back to it somehow). Are you talking > about pulling figures from the CPE somehow, or getting this information > elsewhere? > > > > On the sector I'm looking at, single retransmit blocks in the DL direction > are about 1.4% of total blocks. According to old notes I have, 1% is > supposed to be good. I don't know whether I should worry about the extra > .4%, but I'm also not sure how this relates to uplink health (if at all). > > > > As far as percentages go for uplink modulation, 87% of all uplink bits > were sent MCS 23, if we include MCS 20 + 23 together that rises to 91%, and > if we include 19 + 20 + 23 together, that accounts for 94%. Are those good > numbers? They seem fairly good to me. (I sure would love to see what > individual CPEs are doing for modulation in either direction at any given > time...) > > > > We have also been raising uplink AMBRs as well to help deal with this. > Which seems to help some, and which I think is weird that it helps. For > example, if I have uplink limited to 1.5Mbit/s, a radio on this sector > might be able to average 300-400kbit/s. If I change that radio to an AMBR > profile that has the uplink limit set to 10Mbit/s, then all of a sudden in > the same conditions (minutes later, after changing that UE's profile and > kicking it off the EPC) I see more like 800-1000kbit/s from the same CPE! > These numbers are the same with both iperf TCP (on the radio) or RouterOS > bandwidth-test (router behind the radio), 5 parallel streams in either > case, very repeatable (at that same time of day). > > > > What the...? If roughly 1Mbit/s of capacity is available, and a given UE > is set to 1.5Mbit/s of upload, why can't it achieve that 1Mbit/s unless I > raise it to some crazy high number first? Why does throughput instantly > double when I lift that AMBR value? > > > > So it sounds like you are telling me that you are doing a similar thing > and just cranking those AMBR numbers way up on the EPC, but then you are > using something else (RouterOS?) to queue packets up upstream? And you get > better performance this way? I believe it based on what we have > experienced (above), but it seems to me that this really shouldn't be the > case. Shouldn't the EPC be working in tandem with the eNB to provide the > best and most efficient airtime utilization possible? > > > > I don't think the issue with iperf is with you. I cut my teeth on iperf2 > and even I can't get it to work right on the Compacts and BreezeWay. From > what I can tell, problems appear to be multi-fold. BreezeWay has a "drop > all TCP connections indiscriminately" rule at the end of its iptables > firewall input chain. That's the primary problem as far as I can tell. > Once that is out of the way, or an exception is added for TCP port 5001 > earlier, it works, but the bundled iperf binary is somewhat buggy. The -r > and -d options don't work right and the device that is playing the iperf > server role fails to connect back to the other in client mode and crashes > out when it is time to run a reverse-direction test. So you have to > individually launch iperf as a server on both ends separately in order to > test both directions. I remember running into a similar problem with the > iperf2 binary packaged with some version of Ubuntu a while back, and I had > to grab the iperf sources, patch them, and rebuild them before that switch > worked right. It appears Compact and BW both have unpatched 2.0.5 with at > least this bug present. > > > > -- Nathan > > > > *From:* [email protected] [mailto:[email protected] > <[email protected]>] *On Behalf Of *Jeremy Austin > *Sent:* Wednesday, December 21, 2016 10:22 PM > *To:* [email protected] > *Subject:* Re: [Telrad] More CPE8K woes > > > > > > On Wed, Dec 21, 2016 at 7:44 PM, Nathan Anderson <[email protected]> wrote: > > but this upload capacity thing is what caused me to try pushing 6.6 out to > more Compacts, even though I have read reports of similar-sounding issues > from others here who have fully upgraded...just wanted to make sure I have > all bases covered. > > > We haven't had stability issues per se with 6.6. We've had some success > raising upload AMBR, and shaping upstream. > > > > What kind of retransmission rate are you seeing on the constrained sectors > in the upload direction, in extended stats? We have one in particular that > — despite having a verified clean channel — acts as if it's experiencing > interference. Despite a very high SINR! And some truly bizarre spectrum > analyzer results that aren't corroborated by other, colocated ENBs. > > I'm also not finding it easy running iperf between EPC and ENB, at > Telrad's recommendation. I must be more used to the syntax of iperf3, > because I don't have it correct yet. > > > > > > -- > > Jeremy Austin > > > > (907) 895-2311 > > (907) 803-5422 > > [email protected] > > > > Heritage NetWorks > > Whitestone Power & Communications > > Vertical Broadband, LLC > > > > Schedule a meeting: http://doodle.com/jermudgeon > > > > > _______________________________________________ > > Telrad mailing list > > [email protected] > > http://lists.wispa.org/mailman/listinfo/telrad > > > > _______________________________________________ > Telrad mailing list > [email protected] > http://lists.wispa.org/mailman/listinfo/telrad > > -- *Matthew Carpenter* *806-316-5071 office* *806-236-9558 cell*
_______________________________________________ Telrad mailing list [email protected] http://lists.wispa.org/mailman/listinfo/telrad
