tag:blogger.com,1999:blog-3993498847203183398.post8775394603094041192..comments2024-03-28T09:19:27.451+00:00Comments on RevK<sup>®</sup>'s ramblings: What is Packet Loss?RevKhttp://www.blogger.com/profile/12369263214193333422noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-3993498847203183398.post-8771400077492614882014-02-25T14:24:42.397+00:002014-02-25T14:24:42.397+00:00You can only do that from a PPP endpoint. It is no...You can only do that from a PPP endpoint. It is normal for the PPP endpoint to send them periodically.RevKhttps://www.blogger.com/profile/12369263214193333422noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-48092541934036226662014-02-25T14:10:53.658+00:002014-02-25T14:10:53.658+00:00What do you use to issue the LCP requests? Is ther...What do you use to issue the LCP requests? Is there a command line tool like ping which does similar?Anonymoushttps://www.blogger.com/profile/00879293303825549216noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-36197572885464622022014-02-10T16:08:22.705+00:002014-02-10T16:08:22.705+00:00It's believable that 21CN backhaul (which is a...It's believable that 21CN backhaul (which is a requirement for FTTC) is much, much larger than 20CN backhaul to the same exchange.<br /><br />An exchange with 34 Mbit/s backhaul in 20CN can (for similar costs) have 1 gigabit/s 21CN backhaul; 155 Mbit/s 20CN backhaul ends up closer to 10 gigabit/s 21CN backhaul in costs to BT, and 622 Mbit/s 20CN backhaul costs BT the same as somewhere between 40 and 100 gigabit/s 21CN backhaul.<br /><br />This is a huge disparity in costs; it's why the 21CN project happened at all - basically, the cheapest 21CN backhaul link was larger than the majority of 20CN links.Simon Farnsworthhttps://www.blogger.com/profile/15190608047563530091noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-31676421695240183332014-02-10T10:38:06.381+00:002014-02-10T10:38:06.381+00:00I have passed this on to support for you.I have passed this on to support for you.RevKhttps://www.blogger.com/profile/12369263214193333422noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-41746228423587835562014-02-10T01:39:37.307+00:002014-02-10T01:39:37.307+00:00Could you ask someone to take a look at my constan...Could you ask someone to take a look at my constant packet loss? many thanks -cwcc@aCecil Wardhttps://www.blogger.com/profile/16477035597238561739noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-25653777838379971492014-02-09T22:28:49.442+00:002014-02-09T22:28:49.442+00:00Clearly A&A providing better insight into a pr...Clearly A&A providing better insight into a problem than the average ISP again! :-) <br /><br />With respect to throttling I was referring to the dubious practice of deliberately targeting specific destinations e.g. I read about connections to AWS being hit by a particular ISPs policy.... Just giving a more general category for Andrews excellent piece covering the issue.<br /><br />I've always been a bit suspicious regarding the backhaul on the BT network from a local exchange... nothing A&A can do about it... but I do wonder if a quiet rural exchange like mine which missed out on 21CN and now is being listed as FTTC this calendar year (believe it when I see it!) really has appropriate bandwidth upstream..... <br /><br />Good luck with getting your link fixed :-)Chrishttps://www.blogger.com/profile/11182959617649002778noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-16337221967874801132014-02-09T13:26:59.460+00:002014-02-09T13:26:59.460+00:00Throttling shouldn't impact an idle link, unle...Throttling shouldn't impact an idle link, unless they're trying to throttling traffic down below the c 10 bytes per second of the 1 Hz LCP echo A&A use - and even then, only if the ISP is trying to throttle their own link to the customer, rather than the customer's IP traffic as would normally happen.<br /><br />I'd like to think no ISP would try throttling "broadband" down below 80 bps in either direction!<br /><br />Of course, even when the end user's link is idle, there will be some traffic on the other network sections - something A&A specifically monitor for and report - so if you were to see packet loss on, say, an idle Plusnet line, it could just indicate that Plusnet's own connection to BT is congested.<br /><br />Unfortunately, the use of PPPoE means there is only a single visible network hop between end users and the ISP: either the PPPoE packets get through that hop, or not. A&A then do some detective work to analyse which groups of links are losing packets: all the lines on a particular exchange, for example, or all the lines through a particular BRAS.<br /><br />In my case, we can tell the problem is not between my exchange's Ethernet switch and A&A, because packets to/from other customers on the same switch are getting through OK. Unfortunately, I'm the only A&A customer on this cabinet, so there's no easy comparison to rule that out without help from BT.jas88https://www.blogger.com/profile/05563592458314214904noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-41065644141140781392014-02-09T12:41:23.596+00:002014-02-09T12:41:23.596+00:00Then there is packet loss due to deliberate action...Then there is packet loss due to deliberate action by the ISP, throttling certain connection types...(not suggesting AA do this!) this is a variant of "link full" but could certainly happen on an idle link.<br /><br />Something I would add to your explanation is that the corrupted packet will not be delivered all the way to the end point as the checksum is verified at each router along the way. <br />It may be possible by playing with a variant of traceroute to see approximately which section of the link has the most traffic loss.... <br />Chrishttps://www.blogger.com/profile/11182959617649002778noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-86892560498795949552014-02-09T09:51:06.044+00:002014-02-09T09:51:06.044+00:00I am wondering if it is a "dirty fibre"....I am wondering if it is a "dirty fibre". The uplink will typically be two fibres, one for tx, one for rx, so loss in one direction is perfectly sensible. Even when using one fibre for both ways, the possibility of a faulty emitter or receiver can give one way errors. The fact that LCP is showing so much lower loss suggests it is a raw bit level fault rather than a packet levee bug, IMHO.RevKhttps://www.blogger.com/profile/12369263214193333422noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-58322125157833439402014-02-09T09:41:11.065+00:002014-02-09T09:41:11.065+00:00I had wondered about bugs, particularly since the ...I had wondered about bugs, particularly since the loss seems to be upstream only - mis-measuring the line and giving a "perfect" sync wrongly, or just mangling certain packets like the HG612 bug RevK found last year. That, or the extensive construction work around the cabinet recently (it's on one end of a bridge which has just been replaced!) having damaged it or its backhaul fibres.<br /><br />Interestingly, while (some of) BT seems to dismiss it as trivial at present, packet loss and latency are the key measurements the Samknows devices track for Ofcom's official broadband monitoring programme, along with measured throughput and link uptime, even publishing comparisons of ISPs on these metrics, so BT can expect extra pressure to reconsider this attitude soon from other ISPs who fear being penalised in ratings for it.jas88https://www.blogger.com/profile/05563592458314214904noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-43991442142912366952014-02-09T09:01:21.837+00:002014-02-09T09:01:21.837+00:00Yes, bug based loss is another category I did not ...Yes, bug based loss is another category I did not go in to here and can be a bugger to find.RevKhttps://www.blogger.com/profile/12369263214193333422noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-73724806131898210772014-02-08T22:51:37.876+00:002014-02-08T22:51:37.876+00:00I'd be wary of predicting packet loss of one s...I'd be wary of predicting packet loss of one size packet to another. This is because packet loss due to a bug can be packet size dependent, for two reasons: 1) there can be different code paths for different sized packets, and 2) there can be a different code path when you get near the end of a circular buffer, and the alignment of packet to buffer is affected by its size. <br />This isn't a theoretical comment: this kind of bug has been present in DLSAMs which you probably have had to work with. <br />Of course, that's not the only kind of bug. a DSL line failing to adapt when the noise level has increased will act in the way you describe.Anonymousnoreply@blogger.com