Hello Luca,
We are still playing with visualization of your data, but I didn't want
you to wait any longer for some results. I think I blame both DT and
the Pi :)
First, a look at the phone side of your Banana Pi. The first thing we
noticed is there were a LOT more packets in one direction (north towards
DT) than the other (towards the phone):
jeff@jasper:~/Personal/StratusTalk/wotinder/Luca/tmp$ tcpdump -nr
testPhone.pcap src 192.168.200.10 | wc -l
reading from file testPhone.pcap, link-type EN10MB (Ethernet)
7951
jeff@jasper:~/Personal/StratusTalk/wotinder/Luca/tmp$ tcpdump -nr
testPhone.pcap dst 192.168.200.10 | wc -l
reading from file testPhone.pcap, link-type EN10MB (Ethernet)
3981
Note there are almost twice as many packets headed out. Our tool takes
a shot at it:
jeff@jasper:~/Personal/StratusTalk/wotinder/Luca/tmp$ wotinder -I
testPhone.pcap
input: testPhone.pcap
2020/06/16 10:47:16.047401 INVITE 192.168.200.10:25572 (Luca) ->
192.168.200.1:25572 (sip:035014649215)-(81b17560-c0a80101-0-1798,10000)
2020/06/16 10:47:16.112866 DUPINVITE 192.168.200.10:25572 (Luca) ->
192.168.200.1:25572 (sip:035014649215)-(81b17560-c0a80101-0-1798,10000)
2020/06/16 10:48:43.690647 BYE 192.168.200.1:25572(sip:035014649215)
-> 192.168.200.10:25572(Luca)
Session: 81b17560-c0a80101-0-1798
RTP 10000 -> 10030
Source total pkts: 7899 (avg err 15934.774414)
Dest total pkts: 3943 (avg err 8307.511719)
The "average error" is the average departure from exactly 50hz, in
microseconds. Basically we are wanting to see a packet every 20,000us,
and if it arrives early (because the last one was late) or late, then
the absolute value of how far off it was is accumulated, and in the end
averaged. Its a bit misleading in this case, because there has clearly
been packet loss in one direction, and I am still wrapping my head
around why the error isn't much higher (some kind of bug in our packet
loss penalties).
It does show that from the BPi's perspective, the stream from the phone
is NOT very steady. The *average* error was almost a full packet length
late (16,000us). Now our tool spits out the raw data (time between
packets in us) and we can quickly graph it. I lined up the two legs,
but of course you are only seeing half of the second one, and it makes
an interesting visual:
What on earth is causing the very regular spikes? Roughly every second
there seems to be a delay introduced, EVEN FROM THE PHONE ON THE LAN!
This worries me that we have asked the Pi to do too much. Perhaps
capturing the data and writing it while also running asterisk is causing
something to back up regularly. We do prefer to do this kind of
analysis from a span port on a switch...
But that doesn't explain the missing packets from DT.
Similar results on that side:
jeff@jasper:~/Personal/StratusTalk/wotinder/Luca/tmp$ tcpdump -nr
testDSL.pcap src 91.49.58.181 | wc -l
reading from file testDSL.pcap, link-type LINUX_SLL (Linux cooked)
8048
jeff@jasper:~/Personal/StratusTalk/wotinder/Luca/tmp$ tcpdump -nr
testDSL.pcap dst 91.49.58.181 | wc -l
reading from file testDSL.pcap, link-type LINUX_SLL (Linux cooked)
4076
I'm making an assumption that 91.49.58.181 is your side of the DSL, and
the packets towards you seem to be missing a lot! I can't explain that
as a Pi issue *unless* something funny is happening on the kernel
handling inbound public traffic. You mention you are traffic shaping -
that could easily be causing something like this. Running our tool on
that trace:
jeff@jasper:~/Personal/StratusTalk/wotinder/Luca/tmp$ wotinder -I
DSL.pcap
input: DSL.pcap
2020/06/16 10:47:16.196746 INVITE 91.49.58.181:25572
(00493514977290) -> 217.0.27.53:5060
(sip:035014649215)-(765cb6164b1c122a3b9c8303600ea367,10036)
2020/06/16 10:47:16.296309 DUPINVITE 91.49.58.181:25572
(00493514977290) -> 217.0.27.53:5060
(sip:035014649215)-(765cb6164b1c122a3b9c8303600ea367,10036)
2020/06/16 10:47:16.357971 DUPINVITE 91.49.58.181:25572
(00493514977290) -> 217.0.27.53:5060
(sip:035014649215)-(765cb6164b1c122a3b9c8303600ea367,10036)
2020/06/16 10:47:16.457280 DUPINVITE 91.49.58.181:25572
(00493514977290) -> 217.0.27.53:5060
(sip:035014649215)-(765cb6164b1c122a3b9c8303600ea367,10036)
2020/06/16 10:48:43.680671 BYE 217.0.27.53:5060(sip:035014649215) ->
91.49.58.181:25572(00493514977290)
Session: 765cb6164b1c122a3b9c8303600ea367
RTP 10036 -> 6300
Source total pkts: 7898 (avg err 15771.558594)
Dest total pkts: 3943 (avg err 6995.069824)
The DUPINVITE packets I think are probably negotiations. I didn't dive
into a SIP analysis, but it may be good to look at the SDP and confirm
codec selection, etc.
Funny enough, a visual of THAT side looks exactly the same:
This really is telling I think about the Pi's ability to keep up with
everything you are asking it to do, when looked at from the
*microsecond* perspective.
Still doesn't explain the lack of traffic from DT... I would call them,
send them the trace you sent me, and this message.
Good luck!
Cheers,
j
On 6/15/20 3:27 PM, Luca Bertoncello wrote:
Am 15.06.2020 um 21:50 schrieb Luca Bertoncello:
What do you mean now? If I can use the full available band or if I can
download exactly 50Mbs?
The answer to the first question is: YES! That's why I use a traffic
shaper... ;)
The answer to the second question is: NO. I made a speedtest right now
and I get only ~18Mbps download.
And some other information, too.
I checked the xDSL-statistics of my DSL-Modem (which use the BananaPI to
establish the PPPoE connection):
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 2
Last initialization procedure status: 0
Max: Upstream rate = 1709 Kbps, Downstream rate = 19888 Kbps
Bearer: 0, Upstream rate = 1626 Kbps, Downstream rate = 20113 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
So it seems, that my connection is about the half of the theorical one...
I think, I must call Deutsche Telekom, but since I'll change my contract
at 18.06., I'll wait some days. Then I'll have a "business" contract,
and I hope I don't must speak with someone that can just say "you have
to reboot your Fritzbox. What? You don't have a Fritzbox? That's not
possible. Please check your Fritbox, I can't reach it"... ;)
Bye
Luca Bertoncello
(lucab...@lucabert.de)
--
*Jeff LaCoursiere*
STRATUSTALK, INC. / CTO
Phone: *+1 703.496.4990 x108*
Mobile: *+1 815.546.6599*
Email: *j...@stratustalk.com* <mailto:j...@stratustalk.com>
Website: *https://www.stratustalk.com*
Address: *One Freedom Square
13th Floor
Reston, VA 20190*
<https://www.facebook.com/jeff.lacoursiere>
<https://linkedin.com/in/jeff-lacoursiere-884361>
<https://www.twitter.com/stratustalk>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
