Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2 3

Author Topic: Maintenance and 'always-on' Broadband  (Read 12844 times)

ColinS

  • Reg Member
  • ***
  • Posts: 529
Maintenance and 'always-on' Broadband
« 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!).
« Last Edit: August 07, 2013, 11:17:20 AM by ColinS »
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Maintenance and 'always-on' Broadband
« Reply #1 on: August 07, 2013, 11:35:38 AM »

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 :(
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5717
Re: Maintenance and 'always-on' Broadband
« Reply #2 on: August 07, 2013, 12:05:52 PM »

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 ??
Logged

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: Maintenance and 'always-on' Broadband
« Reply #3 on: August 07, 2013, 12:34:58 PM »

Good question!
Glad you like it!

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

Quote
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!)
Quote
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.

Quote
>>> 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.
   
Quote
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.
Quote
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.
Logged

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: Maintenance and 'always-on' Broadband
« Reply #4 on: August 07, 2013, 12:56:55 PM »

Kinda forced my hand there, Colin.  ;) ;D
How else do we benefit from your experience? :friends:

Quote
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).

Quote
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

Quote
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! ;)

Quote
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?
Logged

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5717
Re: Maintenance and 'always-on' Broadband
« Reply #5 on: August 07, 2013, 06:35:39 PM »

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

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: Maintenance and 'always-on' Broadband
« Reply #6 on: August 07, 2013, 08:48:58 PM »

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?

Quote
'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?
Quote
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!)
Quote
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?

Quote
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? 

Quote
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....
Logged

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5717
Re: Maintenance and 'always-on' Broadband
« Reply #7 on: August 07, 2013, 10:02:39 PM »

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.
 :)
Logged

smurfuk

  • Member
  • **
  • Posts: 26
Re: Maintenance and 'always-on' Broadband
« Reply #8 on: August 08, 2013, 01:02:00 PM »

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).
« Last Edit: August 08, 2013, 01:04:35 PM by smurfuk »
Logged

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: Maintenance and 'always-on' Broadband
« Reply #9 on: August 08, 2013, 04:26:42 PM »

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.
« Last Edit: August 08, 2013, 04:38:44 PM by ColinS »
Logged

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: Maintenance and 'always-on' Broadband
« Reply #10 on: August 08, 2013, 04:28:39 PM »

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. :)
Logged

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5717
Re: Maintenance and 'always-on' Broadband
« Reply #11 on: August 08, 2013, 06:57:45 PM »

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



Logged

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: Maintenance and 'always-on' Broadband
« Reply #12 on: August 08, 2013, 07:34:20 PM »

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:
Logged

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5717
Re: Maintenance and 'always-on' Broadband
« Reply #13 on: August 08, 2013, 07:40:02 PM »

The last bit ?? Could you engineer the spec to work on women ..... in particular, my wife ??  ;) ;D
Logged

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: Maintenance and 'always-on' Broadband
« Reply #14 on: August 08, 2013, 09:06:20 PM »

The last bit ?? Could you engineer the spec to work on women ..... in particular, my wife ??  ;) ;D

Sorry. :( too difficult -
Quote
approx. 19,000 engineers who perform on average, between 3-6 jobs per day
:lol:

Not that you're boasting, I understand ....
Logged
Pages: [1] 2 3
 

anything