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 (lucabert at lucabert.de)
On Monday 15 June 2020 at 22:27:51, Luca Bertoncello wrote:> 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 KbpsOh!> So it seems, that my connection is about the half of the theorical one...Right.> 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 Fritzbox, I can't reach it"... ;)Hehe :) Good luck, Antony. -- "A person lives in the UK, but commutes to France daily for work. He belongs in the UK." - From UK Revenue & Customs notice 741, page 13, paragraph 3.5.1 - http://tinyurl.com/o7gnm4 Please reply to the list; please *don't* CC me.
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 at 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 at 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 at 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 at 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 at 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 at 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
> (lucabert at lucabert.de)
>
--
*Jeff LaCoursiere*
STRATUSTALK, INC. / CTO
Phone: *+1 703.496.4990 x108*
Mobile: *+1 815.546.6599*
Email: *jeff at stratustalk.com* <mailto:jeff at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20200617/50f290ed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic1.png
Type: image/png
Size: 15375 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20200617/50f290ed/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic2.png
Type: image/png
Size: 15773 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20200617/50f290ed/attachment-0001.png>
Missing packet from DT could be caused by MTU issue. Marek 2020-06-18 5:41 GMT+02:00, Jeff LaCoursiere <jeff at stratustalk.com>:> 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 at 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 at 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 at 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 at 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 at 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 at 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 >> (lucabert at lucabert.de) >> > > -- > > *Jeff LaCoursiere* > STRATUSTALK, INC. / CTO > > Phone: *+1 703.496.4990 x108* > Mobile: *+1 815.546.6599* > Email: *jeff at stratustalk.com* <mailto:jeff at 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> > > >