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]

[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.