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> > > >