Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[kitz]

The attainable is an estimate by the modem of what the line can achive based on target SNRM and current SNRM.  My view is that different modems and firmware will estimate differently depending on how they programmed e.g. I suspect the zyxel firmware will give a higher estimate than say the hg612.

Ummm. Surely that would because the Zyxel gives a better SNR Margin than the HG612.  The more SNRm then the of course the attainable will be higher.   All routers will calculate the attainable rate based on the surplus SNR margin.  As mentioned in my post above it will then use the number of bins in use to estimate just how much speed that will mean.


Currently the Zyxel is giving me an attainable of circa 83Mbps with an SNRm of 6.7dB.   None of the other routers I have will currently allow me to sync at the full 80/20.   Without doubt the Zyxel gives me a better sync speed regardless if that is actual sync speed or attainable sync.   Time and time again the Zyxel has proved itself to give better sync speeds on the vast majority of lines.  Therefore it follows if it gives better actual sync speeds then it will also give a higher attainable speed.   This is because the dsl_phy is supposedly better and more efficient.

Even before I got a recent x-talk hit the SNRm has always been better on the Zyxel than on the HG612.  In the same way that Lantiq chipsets give me less SNR margin and therefore less attainable than even the HG612.

[NewtronStar]

This is something i've been keeping a close eye on over the last few months, Zyxel, Asus DSL-A66U and Asus DSL-AC68U i am by far a non modem hardware expert but any of the above would be better than the HG612 

[jid]

I get an 84000 attainable on the HG612 but on the TalkTalk Super router I get around 90,000 with the same SNR margin.

Seems possible that the two devices calculate things differently? The Super Router is much more prone to errors though.

[Black Sheep]

Newt hopefully BS can make a comment on my thoughts here.

But given I have never been charged for a visit even when no fault found, I suspect the £150 fee you quoted is mainly there as a deterrent to stop people reporting faults repeatedly and seen to be wasting openreach's time.

BT your isp have to legally let you know the fee may be raised prior to the visit hence them warning you, but I think in many cases no fee is raised.

Any fee quoted will probably act as a deterrent but someone has to pay OR to attend site, so I'm guessing your ISP is footing the cost, Chrysalis ?? Again, second-guessing the ISP's protocols, I'd humbly suggest that they will only put up with 'so much' before passing those costs on ??

NS - I absolutely appreciate where you're coming from, but I have to say it as I see it from a business perspective. The guidelines that OR work to have been set in stone. We could all argue until the cows come home, whether those set parameters are sufficient and/or what other details should be included in the tests. However, as it is now you get the PQT, the Fast Test/Eclipse and a DSL test. If they all pass, and there is no audible noise on the PSTN side of the circuit ..... job done.

With the greatest of respect and only using your example as it is current, we can't have EU's dictating what they think should be checked. ie: your 25yr old drop-wire.
A) We see all kinds of legacy wiring, both internal and external. At what age should it be replaced, even if it tests ok ??
B) The PQT would not only test your drop-wire, but every other aspect of the circuit from premises to Exchange
Of course, the PQT is only one test, and can't always detect the miniscule HR's, so a visual check of the drop-wire along with other tests may be frugal, but that would be at the engineers discretion. It's incredibly hard to comment conclusively on a public forum, as every single scenario will be different.

Regarding your SNRm swings. Then that should be down to your ISP (not OR) to determine if it is worthy of a site-visit. Again, using the forum as an example the members on here have graphing scripts to collate data ...... they are in the low percentages compared to the total number of DSL users nationwide.
OR only have DSL access (28 days historic view) to classic BT lines, so we wouldn't be able to view the rest of the LLU circuits performance. I don't think any business worth its salt would just freely accept the EU's own-sourced data, as receipt of a fault ?? So I reiterate, your ISP should be the ones monitoring your circuit and they should decide if a visit is necessary. If so, they should make the appointment at the relevant time and add notes stating what they think the issues are. The moon is also made of cheese.

In closing, I am not disputing you may have issues with your circuit. I'm merely pointing out that there has to be a line drawn in the sand as to what is deemed an actionable fault or otherwise.

[Chrysalis]

If a fault is found OR foot the bill.

The issue is what happens when no fault is found.

But you are right, who footed the bill on those visits? possibly my isp yes.

[Black Sheep]

Caveat - If a fault is found on the OR-owned network, then they will foot the bill.

[Chrysalis]

Is it at the engineer's discretion to raise a fee, or is it automatic when no fault is found?

e.g. what happens if the engineer isnt convinced is no fault but cannot find whats wrong or isnt conclusive?

[Black Sheep]

Timescale Related Charges (TRC) ..... or 'The fee' as most would say, is largely dependant on the type of task built by the ISP.

There are too many scenario's to go into, but I'm certain the angle your coming from is the elusive intermittent fault ?? As I have said before, it all hinges on the conversation between the EU and the CP/ISP as to what task is raised (PSTN or DSL).
For the very most part, on PSTN faults the TRC is automatically built into the task when the engineer completes his task on his Laptop/i Phone via drop-down menu's.

On DSL tasks, the ISP will have already paid OR up-front for the visit ..... requesting which 'modules' they want the engineer to investigate. The more modules, the greater the cost.

We have a team of TRC 'Spotters' who are similar to konrado investigating attenuation/SNR values .......... in other words, no stone is left unturned and full scrutinisation is applied when they contact the engineer asking why a TRC was not raised, should that be the case ?


"e.g. what happens if the engineer isnt convinced is no fault but cannot find whats wrong or isnt conclusive?"
 

I can't get my head around that statement I'm afraid ? If 'we' think there is a fault, we have to keep going until we find it. If there is no evidence of a historic fault and all tests show the circuit to be fine, then there's a good chance the TRC will be passed to the EU.
It really is an in-depth subject as it all hinges on historic line-conditions, DSL performance and what one finds when attending site.

[Chrysalis]

So you have never attended a property, where its clear something isnt right but at the same time cannot find an issue?

I will give you a scenario.

Cabinet is outside the house and the actual cable route is direct lets say 10m underground.
The end user is using BT home hub 5, default settings, no home wiring issues etc.
The JDSU syncs at 14mbit instead of 80mbit but all the JDSU tests pass.

ISP has decided to be cheap and not told the customer they only booked minimum modules.

What happens in terms of charges? you cannot do more checks because modules not paid for and at same time you not found OR based fault, but you also know its not EU side.  This is far from an impossible scenario.

I am going to guess the answer.

The ISP may be to blame in the scenario because they asked the engineer to check the wrong things so as a result they are billed.

The more I think about this the more it shows how messed up this arrangement is, really the end user should be dealing with openreach direct or at the evry least they need to have control over what modules are ordered and the ISP should have to tell the end user what modules are ordered, its bonkers that basically the end user is kept completely out the loop.

Every public facing document I have seen makes no mention of modules, there is a openreach page which states a standard SFI fee which is payable when no fault is found or a fault found on end user equipment.  So even openreach's own site seems at odds with the truth.

[Black Sheep]

So you have never attended a property, where its clear something isnt right but at the same time cannot find an issue?

No.

[Black Sheep]

Every public facing document I have seen makes no mention of modules, there is a openreach page which states a standard SFI fee which is payable when no fault is found or a fault found on end user equipment.

The modules are nothing to do with the EU. The ISP decides which route to take ..... 1) Frames check only ...... or, 2) Minimum 'Base Module' whereby the engineer visits the EU's premises. The ISP can decide whether to pre-authorise other modules for the engineer to follow up on, if they feel it is needed.

[NewtronStar]

To me it's clear as day when i compare two QLN graphs seperated by 2 years it shows how my line has changed regarding RFI the only reason would it not be down to an HR fault and never had errored seconds 2 years ago when the phone rings.

[Black Sheep]

As mooted, NS ................... the onus is on you and your ISP to make the decision to proceed, should you wish to. If you are confident there is a 'HR' (and it does sound like it), and your ISP review the logs and concurs, you're laughing.
Make the call.

[NewtronStar]

As mooted, NS ................... the onus is on you and your ISP to make the decision to proceed, should you wish to. If you are confident there is a 'HR' (and it does sound like it), and your ISP review the logs and concurs, you're laughing.
Make the call.

I'm no BroadBand engineer but if i was and the EU printed out those two graphs and i would be happy to explore the customers line to find the cause.

Would the ISP when reviewing the logs see the QLN as we do when using stats moniters, and would the OR engineer know from the two printed QLN graphs help them understand the probable cause on the line ?

[Black Sheep]

The ISP's Tier 2 techs would definitely have vision of QLN, hLog, hLin etc etc .............. which is why they are best placed to make an informed decision as to whether an engineering visit is justified ?

As you're probably aware from reading these forums, it depends on which engineer turns up at your door as to the level of DSL understanding. Whatever the level though, the same basket of measures should be followed with regard to testing for a 'HR' or any other kind of fault.