Kitz Forum
Broadband Related => Broadband Technology => Topic started by: ColinS on August 07, 2013, 11:14:19 AM
-
Not sure if this is in the right section, so please move it if not.
This is just a discussion about the conundrum of how line-plant maintenance can be done in the age of (so-called) always-on broadband, and more particularly, various flavours of DLM.
I think that a significant number of people, here and elsewhere, are only too aware of the use by CSPs of DLM in xDSL DSLAMs. There are various flavours (including 'none'), but generally, the ever watchful DLM keeps an eye on what it perceives is the performance (error rates, unforced resyncs) of our lines, and doesn't take kindly to lines that don't 'behave' themselves.
At the same time, line-plant needs to be maintained. Preferably, IMO, pro-actively, rather than reactively as it is now, but that's another debate.
But as many of us have found to our dismay, line-plant maintenance affects our lines (even if it wasn't our line which reported a fault), and DLM then 'punishes' us accordingly. This happens because maintenance is done on line-plant with complete disregard to 'live' broadband connections monitored by DLM.
When the line-plant only supported voice, this (generally) did not have a long-term effect. You might be disconnected for a period, or get a noisy connection, but generally, once your voice service was restored, it had no long-term effect on your service (at least until the next time).
However, now with 'always-on' broadband (or more accurately, always-on DLM monitoring) line-plant maintenance can, and frequently does, have a long-term impact on our broadband service.
So, is there a better way? Could/should DLM be switched off for those lines affected when maintenance is being done on a particular piece of line-plant. If not, why not? Are CSPs aware of the detrimental effect that line-plant maintenance can have on broadband services, if it is carried out while DLM is still active for the affected lines? Don't they know, or are they simply ignoring that? Do they simply have 'faith' that their DLM algorithms will restore the thing back to where they were previously, and if so, how are they measuring it's success, when most of the time they don't know which lines have been affected by these works?
I would be interested to read others' thoughts (yes, that means you too BS! ;D), but if anyone wants to debate the merits of FTTH (again), would they please do it in a different thread. This is not what is under discussion here (I hope!).
-
Good question!
This is the one thing I really miss about the Be* DLM. It actually gave the EU control of their own line.
However whilst its good for the more experienced user who understands that tweaking to some of the lower settings may perhaps not be a good idea for longer and more unstable lines... I could imagine its not perhaps such a good system for a more novice user.
I think the main grumble about the BTw DLM is that how it can affect throughput for quite a while after the line has recovered, and its often not so easy to get a reset. Sky is another system that I dont like and how it can permanently keep a low profile and no option to turn off interleaving.
>>> Could/should DLM be switched off for those lines affected when maintenance is being done on a particular piece of line-plant.
If its on the ISP level or backhaul then hopefully the line should still remain in sync and the more experienced user could perhaps try for another PPP session without having to resync.
I guess the problem occurs when local line plant works are in effect and this could always cause an issue, but with the possibility that this could affect several different DSLAMs and various DLMs which they probably have no control over.
This, along with other variables that can affect the DLM such as power cuts/power outages/ thunder storms etc are always going to be an issue on DLM systems in particular those that affect throughput speed :(
-
Kinda forced my hand there, Colin. ;) ;D
I'm not sure how you would go about doing 'Pro-active repair' ?? It isn't like machinery, whereby we could run daily/weekly/monthly 'routines' to 'pro-actively' keep it in working order. We can only act when a fault scenario is presented to us. This is what the A1024 process is about ................ replacing defective plant.
We did (not sure we still do, as I've not had one for donkeys years) run a blanket test system, that operated during the small hours. it would auto-RAT test (Low frequency Test) a block of numbers and report back it's findings. the theory, and it actually did work, was that we would 'see' the battery contact, earth contact etc etc, before the EU knew it was there !! However, with the advent of Broadband, this wouldn't be frugal as the RAT is an intrusive test and synch would be lost.
It is nigh-on impossible to reactively work on plant without disruption. We do have 'no-break' crimps, but they are unwieldly, awful to use, and greatly add to the mass of the joint making it difficult to put closures back together after.
I'm no expert in DLM ...... see BE and B*Cat for that, but I personally wouldn't see a 'one-off' occurrence (whilst working on plant maintenance) being of any great detriment ??
-
Good question!
Glad you like it!
This is the one thing I really miss about the Be* DLM. It actually gave the EU control of their own line.
But it didn't make it any easier to convince them if you did have a fault though.
However whilst its good for the more experienced user ... I could imagine its not perhaps such a good system for a more novice user.
Personally, whether I'm a noobie or otherwise, I'm not actually against DLM for 'normal' day-to-day managment of line-faults.
I think the main grumble about the BTw DLM is that how it can affect throughput for quite a while after the line has recovered, and its often not so easy to get a reset.
Yes, it is, expecially since it remains deliberately opaque, but it is all the more infuriating when the EU knows, for example, that the CSP has been fixing someone else's fault, and caused faults on theirs! With (some flavours of) DLM, it can cause a sufficient number of resyncs (for example) in a short interval to induce DLM to intervene. It then takes a long time to return to normal even when it is obvious that the causation has been removed (the engineer has gone elsewhere!)
Sky is another system that I dont like and how it can permanently keep a low profile and no option to turn off interleaving.
No comment.
>>> Could/should DLM be switched off for those lines affected when maintenance is being done on a particular piece of line-plant.
If its on the ISP level or backhaul then hopefully the line should still remain in sync and the more experienced user could perhaps try for another PPP session without having to resync.
OK, but I had local line-plant in mind - anywhere from the exchange out to the EU. It helps to make that clarification.
I guess the problem occurs when local line plant works are in effect and this could always cause an issue, but with the possibility that this could affect several different DSLAMs and various DLMs which they probably have no control over.
Well, clearly they couldn't control somebody else's DSLAM without agreement, but I could envisage a notification system for appropriate tasks, as BS refers to them, and the use of TR069, for example, to inform the DLM that there would be 'work-in-progress' during these times, so expect (i.e. ignore) performance may be affected for that period.
This, along with other variables that can affect the DLM such as power cuts/power outages/ thunder storms etc are always going to be an issue on DLM systems in particular those that affect throughput speed :(
I believe that (at least) the (patented) OR DLM algorithm specifically includes analysis across the DSLAM to (try to) identify 'wide area' effects impacting more than one line on the same DSLAM in the same time frame.
-
Kinda forced my hand there, Colin. ;) ;D
How else do we benefit from your experience? :friends:
I'm not sure how you would go about doing 'Pro-active repair' ?? It isn't like machinery, whereby we could run daily/weekly/monthly 'routines' to 'pro-actively' keep it in working order. We can only act when a fault scenario is presented to us. This is what the A1024 process is about ................ replacing defective plant.
Well, one way to start might be by defining proactive as scheduled and having DLM go 'deaf' during such times; but I think you're starting to touch on some ideas below (albeit you are raising the perceived difficulties of doing so with the current toolsets).
We did (not sure we still do, as I've not had one for donkeys years) run a blanket test system, that operated during the small hours. it would auto-RAT test (Low frequency Test) a block of numbers and report back it's findings. the theory, and it actually did work, was that we would 'see' the battery contact, earth contact etc etc, before the EU knew it was there !! However, with the advent of Broadband, this wouldn't be frugal as the RAT is an intrusive test and synch would be lost.
However it might be done, I think that there would be a great deal of merit if the CSP created and maintained a record of every line's characteristics and subsequent performance. The availability of such a thing would allow deterioration to be identified and addressed (that's proactive). However, clearly it's a whole lot cheaper to ignore the deterioration in your asset-base (line-plant) until such times as it has already reached failure point. After all there are the shareholders to think of. ;) :D
It is nigh-on impossible to reactively work on plant without disruption. We do have 'no-break' crimps, but they are unwieldly, awful to use, and greatly add to the mass of the joint making it difficult to put closures back together after.
Of course, I understand. I think I was really arguing that DLM should be inhibited for affected lines while that goes on. Not that it shouldn't go on, or that there is some cumbersome difficult way of trying (and probably failing anyway) to avoid DLM seeing that you are working on it! ;)
I'm no expert in DLM ...... see BE and B*Cat for that, but I personally wouldn't see a 'one-off' occurrence (whilst working on plant maintenance) being of any great detriment ??
You're far too modest. :) However, you only have to imagine somebody working on a pair somewhere to realise that there may be several contacts/breaks of contact over a time period, and DLM, like the little shed in Bill & Ben, will see them all, and it doesn't know it was the kindly engineer fixing the fault wot done it! ;D And if (s)he has to come back to it again, then that will only make matters worse, and could to consign the EU to months of pulling their feathers out trying to get back to normal again. ;)
Perhaps it would be simpler if I asked the question, do CSPs give any thought to the potential impact on a line's performance record of not inhibiting DLM for the affecting line(s) while they are being worked on?
-
The 'pro-activeness' you touch upon, ie: "Making DLM go deaf", is a bit closing the stable door after the horse has bolted. DLM will have done its deed already, ergo switching it off during faulting wouldn't really have much impact at all.
Define 'deterioration', Colin ?? If it's a lessening of DSL signal since 'switch on', then for the most part that will be down to cross-talk, or aggressive DLM behaviour due to lightning strikes, nearby road-works, Openreach engineering maintenance (joint remakes etc) ................. just because the speed has dropped it does not immediately follow there is a deterioration of our asset-based access network. Far from it in fact.
For the record, the GEA WHOOSH system does capture 'Baseline' values (ie: when the circuit is switched on).
As I say, DLM is not my forte but we do know it acts on a 24hr basis. If it deems umpteen interventions in the network by an engineer to be detrimental, it will apply certain parameters. in the same breath, it should see the next 24hrs as being fault-free and act accordingly ??
I don't have the answers I'm afraid.
-
The 'pro-activeness' you touch upon, ie: "Making DLM go deaf", is a bit closing the stable door after the horse has bolted. DLM will have done its deed already, ergo switching it off during faulting wouldn't really have much impact at all.
I don't think so - not in the kind of situation I described: for example, it becomes necessary for an engineer to work on somebody else's line which is faulty - perhaps in the cabinet, or a joint box, or a DP - and in so doing disturbs (in any number of ways you can imagine) other people's lines. It would make a big difference to those people if DLM was inhibited for all pairs in the DP, cable bundle, cabinet while such problems were investigated - particularly for major works. I think you are thinking of individual line faulting, rather than the potential collateral impact on other lines that occurs (you know it does) whilst fault finding takes place. As you have already said, it is very difficult to do otherwise.
Anyhow, my personal opinion about CSPs doing proactive maintenance, rather than reactive maintenance, is separate from the original question, should necessary reactive maintenance be allowed to have a (potentially long-lasting) collateral effect on other lines?
'Define 'deterioration', Colin ??
Certainly. In order to define deterioration, you would first of all have to define and agree a set of line characteristics, and measure them. Subsequently, deterioration would be a significant change in one or more of those characteristics that suggests that service on that line may be negatively impacted, or may result in a fault condition if not addressed.
What is significant will probably vary according to each individual characteristic of the line.
What might such characteristics be?
Well they could be anything that was useful for such purposes, and which may change over time, and may cause the deterioration I refered to. Such as:
Loop resistance
Line attenuation (e.g. Hlog data)
AC balance
TDR plots
etc
Even more exotic things such as the type and poundage of cable sections
Whatever they are, they would be measured at (whatever) intervals and recorded, and (predefined) significant changes used as thresholds for (dare I say it again) proactive maintenance.
It could be done, if the will (and no doubt the money) was there. However, I don't see much debate about if it should be done.
As you also previously remarked, regular routine testing of lines used to be done, even when it was just a POTS. Now we have broadband, why does that appear to be less important?
If it's a lessening of DSL signal since 'switch on', then for the most part that will be down to cross-talk, or aggressive DLM behaviour due to lightning strikes, nearby road-works, Openreach engineering maintenance (joint remakes etc) ................. just because the speed has dropped it does not immediately follow there is a deterioration of our asset-based access network. Far from it in fact.
First of all, you should know I have no particular axe to grind about OR. That's why I have tried to carefully say CSPs. I don't know (because I don't use them), but I suspect, that similar things happen with other CSPs, e.g. Virgin's coax networks (they always seem to me to be in a terrible state, but that's another story). But if the cap fits, and all that. Nobody's perfect, and I'm sure you're not suggesting that OR has no room at all for improvement?
Next, DLM already takes (some) account of wide-area events impacting lines in the same cabinet, e.g. lightning strikes.
IMO Crosstalk, for the moment, is a convenient excuse for all sorts of problems that may have nothing at all to do with crosstalk, but just as soon as OR rolls out vectoring, we can all be relieved of chasing that particular ghost. (no technical pun intended!)
Openreach engineering maintenance (joint remakes etc) ... just because the speed has dropped it does not immediately follow there is a deterioration of our asset-based access network
Of course not, but it might. I don't think I mentioned speed at all in my original post. I do have personal experience of LOS and resyncs caused by just that though. The problem is that those things are potentially the collateral damage of maintenance on line-plant carrying 'live' broadband. The speed reductions may then follow as a consequence. Can you give me a good reason why nobody should be bothered about that?
As I say, DLM is not my forte but we do know it acts on a 24hr basis. If it deems umpteen interventions in the network by an engineer to be detrimental, it will apply certain parameters. in the same breath, it should see the next 24hrs as being fault-free and act accordingly ??
You see, I think that is the false assumption that lies at the heart of my original post (that it will recover quickly). Of course, it will 'act', but that could take 8 weeks for example. And if it was your line that was collateral damage, how happy would you be about that?
You could always experiment on yourself ;): create a dozen resyncs in say an hour one morning; then repeat that again the next day after DLM has acted; then wait to see how quickly it recovers?
I don't have the answers I'm afraid.
Nobody expects anyone to have (all) the answers. This is just an interesting discussion on what can happen, why it happens, what happens next, and is there a better way? I'm surprised nobody so far has said something like 'Well, we might be able to do something like that, but would you (all) be prepared to pay an extra £2/month on your line rental for it?' :-X
The floor is now open to others....
-
Colin ....
"I don't think so - not in the kind of situation I described: for example, it becomes necessary for an engineer to work on somebody else's line which is faulty - perhaps in the cabinet, or a joint box, or a DP - and in so doing disturbs (in any number of ways you can imagine) other people's lines. It would make a big difference to those people if DLM was inhibited for all pairs in the DP, cable bundle, cabinet while such problems were investigated - particularly for major works. I think you are thinking of individual line faulting, rather than the potential collateral impact on other lines that occurs (you know it does) whilst fault finding takes place."
Are you aware of the logistics behind that scenario ?? It would take longer to knock on every door affected, hope that they were at home, hope that they knew which ISP they were with (You'd be surprised with all the 're-sellers'), explain what was happening with the possibility of elongating that conversation should they question what DLM is, ............ that's before we then have to contact all the different ISP's to either request they switch off DLM, or tell them that WE (OR) were switching DLM off. Then, after what may have been just a 30-minute joint remake, we have to ring the ISP's back and request DLM be re-applied, or inform them that we have done so.
Even if it were as simple as just viewing our CSS data-base, to see what circuits are on the DP (which only shows BT Classic circuits .... not any LLU's), the time it would take to implement a DLM switch-off would make most simple jobs a mammoth task !! It's just not feasible ...... in any kind of situation.
Moving on, the reason 'overnight diagnostics' can't be carried out on Broadband circuits, is not that it is "Less important", it's simply down to the fact that each LLU would have to hand over their test systems to us ....... or, do the very same tests themselves. With POTS, we owned the whole kit and caboodle ....... ergo, very very easy to achieve.
Of course I'm not saying Openreach have it all squared off, and nothing more can be done by way of improvements. The laws of average dictate that not all issue will be down to crosstalk affecting VDSL circuitry, but it does affect a large proportion of circuits. BTOR are not in the business of spending millions on vectoring trials and implementation just to hope a problem goes away. The results thus far are very promising, and I personally foresee a lot of VDSL 'Slow speed' issues being a thing of the past. Just my thoughts.
I think the onus here should be directed more towards DLM's behaviour, and the possibilities of bettering its sampling rate and subsequent actions, pretty much like the 21CN ADSL DLM ?? Asking Openreach engineering staff to get involved in DLM activity on non-reported circuits, will never happen. There would be no audit trail, as there would be no activities raised to log actions against it , and as mentioned earlier, the timescales would be immense.
:)
-
Can only give a layman's perspective here, but the things that I can say do not change any of the noticeable performance stats affected by DLM for my line reported by the modem (a Fritz! on FTTC) or give any downtime on the connection between the cab and my modem:
repairs to neighbours connections on the local loop
BTw faults and repairs (including exchange faults, PoP issues and problems with the interface between BTw and my ISP)
lightning (or anything weather-related).
Actually for about two years I haven't found anything that does affect it yet, after the initial settling in with interleaving (required on my line). Oh, and I can disconnect the modem; but can't blame the DLM for that one. DLM just comes back as before on reconnection. (Occasionally I've done up to half a dozen reconnects in a morning when messing about with modem settings, but that didn't effect any change either).
-
BS, I seem to be giving you entirely the wrong impression. :( If so, then I am sorry for not making myself clearer, and with your help, I shall endeavour to clarify.
First and foremost, I am not trying to make an OR engineer's job any more difficult than it presumably already is. :no: You make a very good point about LLU'ed lines (ADSL ftm). Personally, I do not think OR should have any responsibility for another CSP's customers, beyond perhaps a requirement to notify them of works that may impact on their users. I suspect OR must already do that in certain circumstances, but it may not happen at the kind of local loop level I was speaking of. In any event I would not expect that to be part of an individual engineer's task, but rather a function of the 'system' when building that task. Thereafter, it should be another CSPs responsibility to their users whether or not they do anything for them as a consequence.
Secondly, (and from here on in with reference solely to lines that are wholly OR's responsibility), why do you feel it would be necessary to inform anyone at all that DLM monitoring would be inhibited on their cabinet for a period of time while work takes place? As that would have no detrimental effect on anyone AFAICS, who would care? Indeed I am sure that there is a rational body of opinion that might prefer if DLM were switched off permanently!
However, if temporary inhibition is too difficult to achieve, then, as you suggest, perhaps it would be easier to develop a better DLM (algorithm) instead? First question: how would the algorithm distinguish those unforced resyncs caused by engineering works from those caused by anyone or anything else? If error rates suddenly increased because someone had connected a tone-generator to my line whilst trying to identify someone else's, how would it know that had happened? And so on ... The more you go down that path, the more, it seems to me anyway, you would come to the conclusion that perhaps it was easier to switch the entire thing off permanently.
But it's there for a reasonable purpose, which is to prevent the unnecessary call-out of engineers, and the associated costs of that, for 'normal' transient line conditions. However, I am quite sure that it is just as capable of doing that job even with a subset of that day's data for any given line.
However, perhaps we are diving too soon in the how, rather than settling the why first? So, is it acceptable (and totally unavoidable) that some lines may just unfortunately be affected ('collateral damage') in the difficult job that engineers have while working near these lines? That's really a rhetorical question for EUs and CSPs/ISPs to think about, not for you, BS, to have to answer (although as an EU and an extremely experienced and helpful engineer you are perfectly entitled to continue to give us the benefit of that insight :))
Finally, of course crosstalk exists (it always has), and sure it affects lines, and it will be 'controlled' better with vectoring. However, atm it seems to be the 'reason-du-jour' in more circumstances than there is any objective proof for. But that's simply my personal opinion, and need not be of any concern. Again I must reiterate, this thread is about the potential collateral impact of important and necessary engineering activity that may inadvertantly affect lines other than the one under investigation, not about the effects of crosstalk.
-
Actually for about two years I haven't found anything that does affect it yet
I'm pleased to hear that you have such a desirable and bullet-proof service. :)
-
Colin, AFAIC this is just a debate my friend, and as such there are always going to be differing takes on what can, or can not be achieved. I sort of see my role here as giving the bigger picture, as well as helping where possible with engineering terminology, and anything else I feel others may benefit from knowing.
With that in mind, I'm not sure what you mean by, 'Lines that are wholly OR's responsibility' ?? We are solely responsible (as I'm sure you are aware), for all the wires from PCP to EU. The equipment plonked on either end of those wires are not ours, the 're-sellers' own them. So I'm struggling to understand which circuits you are alluding to, when you mention blanket ceasing of DLM for maintenance purposes ?? This is a genuine puzzlement, I'm not being deliberately evasive.
Just a guess, but are you basically saying that if a job drops in to our systems, we should have the ability to switch the Openreach DLM off (Obviously VDSL only), carte-blanche ?? If that is what you're pointing towards, I would again say that this would be impractical. If you can imagine, the average Cabinet will have approx. 500-600 connections running through it. Each time we enter this Cabinet we are performing either provision or maintenance tasks ...... both generally require 'Network Intervention'.
Again, imagine the logistics of having to look at each 100pr 'Node', work out which circuits within that 'node' were VDSL activated, find their corresponding card ports at the VDSL Cabinet, then request DLM switch-off. I dare-say with LLU co-operation in order to 'view' their circuits, there could be a software programme written that may achieve this ?. But, multiply this scenario by approx. 19,000 engineers who perform on average, between 3-6 jobs per day and it becomes a nightmare to police.
Why not get together with Asbo, BE, and B*Cat and invent an alternative to DLM. The brain-power in that 'Four hand', should be suffice to conjure up something workable !! ;D ;D ;D
-
invent an alternative to DLM.
Fair enough. :)
I've just though of one! Let's do without it entirely? ;) Worked fine with BE. Doesn't prevent faults, but doesn't penalise you for extended periods for faults caused by transient external factors that are outside of the EU's control either. Each time you resync, you get whatever it's actually capable of at the time, for better or worse. ;)
Wouldn't cost much, and you'd only have to switch off once, ever. :D
:drink:
-
The last bit ?? Could you engineer the spec to work on women ..... in particular, my wife ?? ;) ;D
-
The last bit ?? Could you engineer the spec to work on women ..... in particular, my wife ?? ;) ;D
Sorry. :( too difficult - approx. 19,000 engineers who perform on average, between 3-6 jobs per day
:lol:
Not that you're boasting, I understand ....
-
?? Tis true .......... the noobies do 6 jobs a day most days. I'll leave it at that. ;)
-
>>> Let's do without it entirely? ;) Worked fine with BE.
My thoughts entirely - I like BE's DLM, no complicated algorithms & No IP profiles.
Just a straight forward set of various target SNRMs and levels of interleaving.
Tiscali used to have a huuuge range of profiles, but even they were transparent and easily configurable by the SP.
The problem with the BTw DLM is that no-one really knows for sure what can trigger it.. and no other system seems to have had so much problems with stuck profiles - although admittedly it is better than it was. But theres still instances where the DLM seems to have a mind of its own and over-rides interleaving status.
As mentioned above the main gripe by the EU's is the IPprofiles and the limiting of throughput speed. The idea of the IPprofile is that it stops un-necessary traffic at the bRAS from going down the backhaul pipes and clogging up at the exchange. Years ago I could perhaps understand the necessity more than what I do today. Afterall the internet is full of routers/switches/links which are going to have different speed limitations... even on our LAN outgoing traffic is very often limited by upstream dsl speeds.
More investigation would be needed to find out how much of a bottle-neck the backhaul is... and this is unlikely to be the same for different exchange sizes.
Sky's DLM (to me) seems the worst of the bunch in that you are assessed during a short time frame, then thats practically it. But then again sky have always been a bit tight on their profiles. 2Mb was never 2Mb.. it was 2000kbps and they didnt allow for certain overheads which at least BTw did.
...... and on that subject... when I get some free time I need to do a bit of digging about Plusnets profiling system and overheads. This is something I raised many moons ago on maxdsl and iirc something satisfactory was put in place which I see no sign of now on FTTC... but I need to look again properly before I go spouting my trap off.
-
?? Tis true .......... the noobies do 6 jobs a day most days. I'll leave it at that. ;)
and Kellys & Quinns do 6 to 8.... and the top boffins at BT wonder how.... ::)
but how many of those are done right first time... plus dont they normally get sent the simple stuff?
-
My own experiences of the contractors, is that they get issued the simpler skilled installation tasks. Not their fault to some degree, as they aren't allowed to work on more than one span of wire.
The problem is they get paid-per-job ......... that is, a fully completed job. So, it doesn't take a genius to work out how the aesthetics of a job may end up ?? If it looks like the job may take time, IMO the job will end up winging its way back to an Openreach engineer.
Poor, or should I say virtually no training, coupled with what in effect is bonus-related pay, makes for a poor service IMO. We trialled two flavours of BRP with in-house engineers years ago (FRS and SMT). We made an absolute mint, but the state of the network was disgraceful, as one would beg, borrow and steal to get a job 'completed'. I believe we are still recovering from that period in our history ??.
As such, I kind of sit on the fence with our contractor friends.
-
Not all Quinns get payed per Job...
-
Only 'Exchange/E-side' engineers, or their 'Hoist' engineers appear to be salaried. Everyone else afaik get paid-per-task. I have friends (ex-BT) who are managers for both Quinns and Kellies, and that has always been the case.
-
@ BS :friends:
Researching, following on from your important point about LLU'ed lines, I found this interesting link http://www2.alcatel-lucent.com/techzine/vdsl2-vectoring-in-a-multi-operator-environment-separating-fact-from-fiction/ (http://www2.alcatel-lucent.com/techzine/vdsl2-vectoring-in-a-multi-operator-environment-separating-fact-from-fiction/) about how it's possible to achieve some things even in a 'multi-operator' environment.
Apologies that it's all in French :(
-
Good link. It backs up what I've read and stated in another thread, in that (according to your link) it's possible to work with vectoring in a multiple owner environment, but absolute best results need ALL circuits to be vectored.
This is why they run trials and keep them confidential, until they're certain it does what it says on the tin. No point releasing data on a weekly basis that may end up differing or contradicting itself, as the trial progresses and further 'disturbers' are introduced into the bundle. Plus, all the data is in French and I don't understand it ?? Luckily, I know a man who can. ;) :D
-
but absolute best results need ALL circuits to be vectored.
Of course. Which is why some of us oppose the idea of VDSL2 sub-loop unbundling to Sky or anyone else, where potentially it would have the highest effect. As far as ADSLx sub-loop unbundling goes, the cat is already out of the bag, but fortunately this has only has a very small impact on vectored VDSL2.
As those clever Frenchies already know, and no doubt the Chinese too :-X, but the good old Brits have still to confirm. ::)
I can see the headline now, "Openreach trial confirms what everybody else already knows". ;):lol:
-
As far as ADSLx sub-loop unbundling goes, the cat is already out of the bag, but fortunately this has only has a very small impact on vectored VDSL2.
^-^ Meow?
Suppose all xDSL services were eventually migrated to originate from the nearest cabinet DSLAM to the EU (i.e. do away with exchange based DSLAMs/MSANs). At a stroke, that would eliminate numerous factors, for the benefit of all. (A banded profile could be applied so that the service is identical to that which was provided by the exchange based equipment.)
For example, the service provided to The Cattery is ADSL2+. It is possible to obtain a VDSL2 service on the line and if the 80/20 service was used, the Beattie 'guesstimator' suggests that 60/20 could be obtained. Suppose my service was migrated to be served from the cabinet DSLAM. I would be perfectly happy to have a banded profile applied to it so that I received the 24/0.95 ADSL2+ service equivalent and continue to pay the price of the ADSL2+ service.
-
Don't see why not in principle. Seems like a good idea to me. ;D But then someone wouldn't get the premium for 'Superfast' broadband! ;)
-
Only 'Exchange/E-side' engineers, or their 'Hoist' engineers appear to be salaried. Everyone else afaik get paid-per-task. I have friends (ex-BT) who are managers for both Quinns and Kellies, and that has always been the case.
My mums boyfriend works up in Birmingham for Quinns and gets paid per year. All he mainly does is FTTC installs with various other odd jobs.
-
Fair do's,
-
Perhaps its only a more recent thing?
Like since their contract to BT in 2011 (http://www.mjquinn.co.uk/case_studies/telecoms_services/bt_openreach__access_network), whereby BT pay Quinns/Kellys per completion of each job item.. hence them in turn only paying the engineer per job.
All new vacancies (https://jobsearch.direct.gov.uk/GetJob.aspx?JobID=2979807) appear to be advertised as per job
Be flexible with regard to working hours as you are paid on a job completion and appointment completion basis.
Certainly all mentions Ive seen recently are per job completion. They also seem to have a pretty high staff churn rate due to various factors such as travel/distance/not getting paid if they turn up for a job and the EU isnt in.
-
Do Quinns/Kelly use OR branded vans?
I recently had an engineer arrive in an OR branded vehicle to fix a broadband fault which he did quite competently. However a couple of throw away comments he made did make me wonder if he were actually was employed by OR itself.
-
All contractors vans have to be liveried that they are 'Working on behalf of BTOR'. But, the larger sign-writing will be advertising their own name. If the van is purely Openreach liveried, it will be a an actual Openreach employee. :)
-
Thanks for the clarification BS, and the guy turned up with an OR liveried wagon.
His beef was that he was being given lots of jobs which he could not "complete" so was not earning "points". He said he had just come from a job where he was expected to reconnect a subscriber who had lots of building work done. The subscriber was fed by overhead wires. However the building work meant that the only new way to enter the house was about 2 metres further from where the connection into the house had been made previously. He therefore could not do a simple reconnection because the existing overhead wire was too short, and he was not qualified to run new overhead cable. He also told me about the geographic area he covered - I won't provide details as it might identify the guy. Suffice it to say he was covering a very very large area in the Home Counties. He said he was therefore spending lots of time travelling for which he did not get paid.
That's why I wondered at the time whether he might be a sub contractor rather than an OR employee.
-
He sounds like one of the new guys taken on within the last couple of years. Their contact sees them travelling for up to 2hrs from their base, all unpaid. But, they are bone-fide Openreach engineers. :)
-
All contractors vans have to be liveried that they are 'Working on behalf of BTOR'. But, the larger sign-writing will be advertising their own name. If the van is purely Openreach liveried, it will be a an actual Openreach employee. :)
The guy who turned up at mine arrived in a white van with a very prominent Openreach logo. Closer inspection showed something like MJ Quinn contractor for.... just above the Openreach and BT livery. I could be wrong, but I didnt see any larger sign advertising their own name.