After having just loaded Sims into a bunch of 8K's my current biggest
complaint is with that silver colored plug that would rather cross
thread than screw in straight... and if you do cross thread it good luck
unscrewing it again without chipping the crap out of that too-shallow
slot, to the point where you just can't unscrew the stupid thing. Argh.
Ian
On 22/12/2016 3:54 AM, Nathan Anderson wrote:
Argh, brain fart:
:%s/bearing/bearer/g
You say potaeto, I say potahto.
-- Nathan
*From:*[email protected] [mailto:[email protected]] *On
Behalf Of *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]>
[mailto:[email protected]] *On Behalf Of *Nathan Anderson
*Sent:* Thursday, December 22, 2016 12:14 AM
*To:* [email protected] <mailto:[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]>
[mailto:[email protected]] *On Behalf Of *Jeremy Austin
*Sent:* Wednesday, December 21, 2016 10:22 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [Telrad] More CPE8K woes
On Wed, Dec 21, 2016 at 7:44 PM, Nathan Anderson <[email protected]
<mailto:[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] <mailto:[email protected]>
Heritage NetWorks
Whitestone Power & Communications
Vertical Broadband, LLC
Schedule a meeting: http://doodle.com/jermudgeon
<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
