As you may well have realised, William, this forum has been here for a very long time. It has, amongst its members, many people with deep technical backgrounds. Some here work or have worked for companies including Openreach and others associated with UK broadband. They mostly cannot reveal their affiliation, but those of us who have been here long enough know who they are and something of their background or experience. Others, including myself, have experience that speaks to UK broadband - I am a former software engineer for a company that worked on early ATM implementations, also I have contributed code and bug fixes to pfSense as well as a few small contributions to FreeBSD.
My knowledge of ATM is essentially useless now, as the ATM that remains in public networks is rapidly being replaced by "pure IP" / Ethernet technologies such as MPLS. In particular, what is left of the ATM based 20CN is being replaced by the MPLS based 21CN. Nevertheless, that professional experience and my subsequent involvement in the open source community gives me 'real life' experience of working with supposed standards and how actual implementations diverge from standards in sometimes surprising ways. These divergences are often hidden from public view by commercial confidentiality, sometimes because companies don't want to admit to the embarrassing shortcomings of their products. In one case, a software product I was working on kept failing on a subset of servers my former employer had manufactured. It turned out that the reason was a subtle firmware bug in a particular range of hard disks that the (well regarded at the time) drive manufacturer admitted was a known bug only when I had carefully worked out the failure scenario with the help of a logic analyser hooked up to a hard disk and my colleagues had engaged in a Friday afternoon software lab exercise of "who can get the most errors per second out of the hard disk" to verify my results. Points scoring, of the sort you seem to enjoy, would have got us nowhere - the last thing we needed was further levels of untested speculation obscuring our thinking. It was a case of using the scientific method: setting up a reasonable hypothesis, collecting data and seeing whether the data supported the hypothesis or whether a new hypothesis was needed.
It turned out that there was a firmware bug affecting the hard disk's caching on the last physical track leading to it throwing a bus error if you carried out too much random I/O on the last few hundred sectors (it could well have been an 'off by one' type bug, though that's speculation on my part). In most usage scenarios this bug would have been benign but our product used the last portion of the disk as a staging area for print jobs so these disks flaked out when printing. The answer was to deploy an (unfortunately non-backward compatible) change in our partitioning strategy to move the print staging area to between the first and second partition, rather than placing it at the end of the disk. These were the days before flash memory; the drive firmware was on a plug in PROM and the only other version the manufacturer would offer us was PROMs for an earlier version that we already knew from previous work to have totally broken caching, so deploying fixed drive firmware was a non-starter.
These days, there are lots of publicly viewable examples of these surprises. You only need to delve into the source code repositories and bug databases of open source projects such as the open source routers pfSense and OpenWRT to see how the code is littered with work-rounds for surprises which include:
- divergent implementations of a standard, often as a result of lax wording of the standard or an unforeseen case
- incorrect implementation of a standard
- multiple ways of implementing the same thing (for example the number of different ways that IPv6 connectivity is provided at the moment: DHCP-PD, 6RD, statically routed IPv6, various flavours of IPv6 in IPv4 tunnelling)
- the 'reference implementation' being wrong, but everyone feels compelled to replicate the error in order to provide interoperability (particularly vile, as the 'reference implementation' should be fixed, but it happens)
- continuing need to support an earlier, incompatible version of the standard
Your enthusiasm about DSL and broadband is not in doubt, but your contributions to threads such as this one which are short and not carefully thought through do not help the discussion. You scored a point off me by tricking me into placing my reply in a part of the thread that was about BTw's IP Profile - but I read in flat view, as I find the threaded view on this ancient forum software to be intolerably clunky to use and got confused by the divergence from the main topic of the thread. Rather than focusing on the (entirely meaningless) point you scored off me, I suggest you reflect on the substance of the post. You have been quick to suggest that any posted statistics showing a 3dB SNR margin are an example of a 3dB downstream target SNR margin, ignoring:
- SNR margin changes over time
- the SNR margin shortly after the router has resynchronised is not necessarily the target SNR margin
- Openreach's (proprietary) DLM implementation is believed to reach a 3dB target SNR margin in 1dB steps, starting from 6dB
- the rollout of <6dB target SNR margin is currently believed to be Huawei only and not to have spread that far from the trial area in Devon and Cornwall
- statistics copied and pasted from many router web interfaces contain errors - command line interfaces are typically more reliable
We are trying to understand the extent and behaviour of this new departure in DLM. Jumping to unwarranted conclusions that throws everyone off the scent does not help in this task.
In
another thread you asked some entirely reasonable questions about IPv6. I attempted to answer those questions in ways that provided information, sparked your interest and potentially gave you a basis for experimentation. IPv6 isn't going to go away; it is the future of the Internet, yet it is an area that many of us still understand poorly. These days, you have a wealth of tools for self-education available free of charge: packet sniffing software (Wireshark), hypervisors (such as Virtualbox) together with a wealth of pre-configured VMs (routers such as pfSense as well as client operating systems), IPv6 tunnels if you don't have native IPv6 (Hurricane Electric) as well as the IPv6 standards (any web site that carries RFCs) and related discussion (Google, used wisely, is your friend!) are all available to you. I doubt anyone will judge you for asking reasonable questions and making mistakes when trying to understand things; I've certainly made my share of mistakes and been willing to accept correction and criticism from others.
I encourage you to experiment and learn, as well as continuing to engage with these forums. Whilst some information, such as the behaviour of Openreach's FTTC DLM, is not freely available, there is a lot of freely available technical information and resources for self-learning. Meanwhile, I suggest that it would help everyone if your posts are a little more reflective, acknowledge lack of certainty whenever appropriate, do not jump to unwarranted conclusions, recognise that
correlation does not imply causation and that you focus less on "scoring points".
Pages in this thread: 
Print Thread
