I'm not using the OpenReach modem, I have a Cisco 2901 with EHWIC-VA-DSL-M card.
Everything is logged so I can see what's going on 🙂
The issue here is the OoO packets, the Openreach modem will not show these stats, and to be honest from what I've seen from the OpenReach modem - it should be binned.
For testing, the Cisco router is far superior than the OpenReach modem - but then again it does have a far superior price-tag!
Anyway, here's the 18:00PM results
If this is not a sign of congestion, I don't know what is!
With the queue length set to the standard recommended 16, just look at all the dropped packets that need to be resent.
Are you seeing a reduction in throughput? If so swap to the openreach modem, do you still see a reduction in throughput?
FWIW my OR moden has no trouble sustaining 75 Mb at any time of the day.
He stated you can't see those type of statistics on the modem.
The out of order packets will be due to bitswaps of the dsl for the metallic path segment.
The short line modulates the ADSL much as any other line ... so if any impulse noise is blinding certain frequencies (even temporarily), and those frquencies aren't available, the data bins for the ADSL discreet multitone may not always get loaded fully, forcing part packets to bitswap to other data bins. The TCP forces them together at demodulation, and if it unsuccessful implements a cyclic checksum and resend of the packet. That linked with RS codewords is normal for error corrected lines. They will go up and down, depending on the level of bitswapping reqd. I don't see a connection with congestion ...
Simply because, as with all ADSL, impulse noise becomes a challenge after nightfall as environmental conditions condusive to the technology subside .... like say .... radio stations come in from abroad, radiation from sodium street lamps etc. and a lot of the radio interference is also bounced of the ionosphere and affects digital information bitstreams that way. As would say ... a solar flair.
It's one of the main reasons DLM negotiates its target margin .... because once it's trained for a few days and seen both day and night conditions it stabilises the line control to set a suitable margin to take into account a line that will control for the longterm .... and not just drop when it sees or breaks error threshold. That's why line training and running ADSL permanently 24/7 is so important .... as line conditions cannot be guaranteed, and do change with environmental conditions.
But I thought this would cause the CRC errors, to which I'm getting very few since the line has gone back up in speed!
I'm thinking of this, probably wrongly as though I would be configuring switches in a datacenter, together with something like a F5 load-balancer.
The CRCs you are seeing are the result of full header corrections taking place, multi-bit packets and not just the occasional single or double bit error. If header corrections are seen a full cyclic redundancy checksum will check the TCP packet handling and ack flags, and totally resend packets, rather than just bitswap