Missing packet from DT could be caused by MTU issue. Marek
2020-06-18 5:41 GMT+02:00, Jeff LaCoursiere <j...@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@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