Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Zico on December 11, 2017, 01:16:34 PM
-
I've recently had a new phone line and 80/20 FTTC service fitted (IDnet) and I am querying the FTTC sync speed of the line.
The DSL checker prediction stats (full snippet attached):
High Low High Low
VDSL Range A (Clean) 80 59.9 20 19 53.4 Available -- -- Yes --
VDSL Range B (Impacted) 77.6 54.1 20 16 40.3 Available -- -- Yes --
A few years ago I had PlusNet FTTC and synced at ~78/20 speeds back to the same ECI cabinet using an ECI Openreach modem / PlusNet Technicolor tg582n router combo. The predicted speed ranges were a reflection of what I had before (as far as I can recall) and were what I had expected on the new service (looking at the clean range for reasons below).
On the date of the phone line install, I provided the Openreach engineer a brand new 350m roll of 0.9mm BT Dropwire 12 - CW1406 spec. https://www.btcables.com/documents/CW1406-Dropwire-12.pdf (https://www.btcables.com/documents/CW1406-Dropwire-12.pdf). I had purchased this for two reasons; 1) our property is served by overhead power lines on the same telegraph poles and 2) the other drop wire serving the property has a few joints in it due to tree rub damage (and also runs to the opposite side of the property with another phone and FTTC service - running ~60/20).
The new line was installed from the property back to the DP pole at the edge of the road covering approx. ~125m. From the DP back to the cabinet is another ~180m (line traced using google maps - snippet attached) making an approx. line length of ~300m rounding up. Finally the fibre port was connected a few days after (was supposed to be a simultaneous provide but original engineer turned up was from MJ Quinn's and couldn't work with the overhead power lines - this was passed on by myself to IDnet in turn to Openreach).
Anyway, onto the connection stats. Full connection stats from DSLstats attached, snippet below:
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 11726 Kbps, Downstream rate = 56972 Kbps
Bearer: 0, Upstream rate = 12093 Kbps, Downstream rate = 56169 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.9 6.1
Attn(dB): 13.3 0.0
Pwr(dBm): 1.2 1.2
As you can see, I'm synced at the bottom end of the Impacted range for Download and below that for the Upload speed. This has surprised me based on the new spec drop wire cable and my historical connection through PlusNet (and even comparing my upload to the other FTTC service on the other drop wire syncing at 20 compared to my 12).
I'm not sure what to think as it shouldn't be a fault (at least on the line from the DP to the house), might be crosstalk with the other FTTC service (though again not on the last ~125m drop wire span) or even crosstalk back at the ECI cabinet with more connections over the last few years.
**Edit**
Re-uploaded DSLstats as file was empty, woops :)
[attachment deleted by admin]
-
Maybe it's just me but for your line attenuation I feel that the speed is lower than expected for sure. Based on your power levels I'd assume you're on a line card running version b206. Some ECI line cards have been known to run version d086 (like my first line is on b206, my second line is on d086) which for some gives improved speeds and for some others terrible speeds. My second line is significantly better than that first, I also had four SFI engineers working on the second line of which three of them did some pair swaps to find me the best pair along the route (and some lift and shifts). My attenuation is 16 dB downstream (450 meters approx to cabinet) and I'm getting an attainable rate of around 82/24 currently, but this line is connected to a line card running version d086 and is on an extremely good pair so isn't a really fair comparison I guess.
EDIT: Forgot to mention I'm running a DrayTek Vigor 2860Vac which has reed solomon coding 'R' on the downstream even on fastpath. This reduces the attainable rate. On a HG612 I think I recall getting something like 90/24.
-
I'm using a Billion 8800NL R2 (was lazy and got it supplied from IDnet) and here are the stats confirming the DSLAM/MSAN:
Stats recorded 11 Dec 2017 16:23:36
DSLAM/MSAN type: IFTN:0xb206 / v0xb206
Modem/router firmware: AnnexA version - A2pvI042j1.d26q_rc1a
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 6 days 3 hours 15 min 20 sec
Resyncs: 0 (since 11 Dec 2017 10:59:33)
Downstream Upstream
Line attenuation (dB): 13.3 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 56169 12093
SNR margin (dB): 6.0 6.0
Power (dBm): 1.2 1.2
Interleave depth: 1 1
INP: 0 0
G.INP: Not enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): N/A 0.0002
RSUnCorr/RS (%): N/A 0.0000
ES/hour: 0.18 2.96
**Edit**
If it's the ECI line card firmware as the issue, how hard would it be to request this to be swapped to a d086 port if there is one available?
-
I wonder if by supplying the drop wire, you have compromised the ability to call on Openreach?
-
I'm using a Billion 8800NL R2 (was lazy and got it supplied from IDnet) and here are the stats confirming the DSLAM/MSAN:
Stats recorded 11 Dec 2017 16:23:36
DSLAM/MSAN type: IFTN:0xb206 / v0xb206
Modem/router firmware: AnnexA version - A2pvI042j1.d26q_rc1a
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 6 days 3 hours 15 min 20 sec
Resyncs: 0 (since 11 Dec 2017 10:59:33)
Downstream Upstream
Line attenuation (dB): 13.3 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 56169 12093
SNR margin (dB): 6.0 6.0
Power (dBm): 1.2 1.2
Interleave depth: 1 1
INP: 0 0
G.INP: Not enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): N/A 0.0002
RSUnCorr/RS (%): N/A 0.0000
ES/hour: 0.18 2.96
**Edit**
If it's the ECI line card firmware as the issue, how hard would it be to request this to be swapped to a d086 port if there is one available?
I see. Pretty sure that Billion is good but best to wait to see what other forum members here say. While I highly doubt your problems are related to the line card version, it was merely an observation I had that for me d086 seems to perform better than b206. I believe b206 is far more common than d086 for some reason. There's no way to get this changed I'm afraid. More likely something else is causing you to have a lower than expected speed, heavy crosstalk, an underlying fault, well.. quite a few other possibilities I imagine. I'm sure someone else on here can be a bit more insightful than me :).
-
I wonder if by supplying the drop wire, you have compromised the ability to call on Openreach?
I don't think that should cause an issue. If it was going to be an issue then I would have imagined the Openreach engineer would have simply said no to putting it up in the first place. It's proper BT cable (stamped on the drum BT Cables as the original supplier) just purchased through a networking reseller Blue Helix - http://www.bluehelix.co.uk/Product.aspx?id=1724.
-
With that attenuation, speeds do indeed look a bit low. The next step is to figure why:
- Is it DLM stealing bandwidth?
- Is it high error behaviour?
- Is it high crosstalk, from other subscribers (from a "quiet line" graph)?
- Is it a bad copper line (from a Hlog graph)?
- In the absence of these issues, then power can be a question mark.
The stats as given in the text file look fine. There's no intervention from DLM (but, of course, there's no G.INP either).
The stats for "Previous 1 day" and "since Link time" show low levels of CRC and ES. There's no problem there.
The remaining issues really need a graph of the "quiet line" behaviour and the "Hlog" measurement of the line. They can be acquired from software that reads the stats from the modem.
That leaves power. Getting values of 1.2dBm for both up and down is, on the face of it, strange. But it is hard to debug; the only other indication of power comes from the output to the "--pbParams" option.
Note that while you are synced under the bottom of the clean range, you haven't fallen into the "handback" range yet. Remember that 20% of lines end up below the bottom of the range, and that 10% below the handback range. The latter is the threshold to get an engineer out.
-
I've just dumped a copy of all graphs from a few minutes ago.
Is QLN the 'quiet line' graph that you refer to (not used DSLstats before so not overly familiar with the importance of some of the tabs).
-
A G.993.2 (VDSL2) based circuit, as currently used in the UK, has 4096 sub-carriers numbered from 0 to 4095.
Unfortunately, for the QLN (quiet line noise) and Hlog plots, you haven't adjusted the scale of the X-axis so we are only seeing the first 800 (or so) sub-carriers. :(
-
Yes, just realised that the graphs are wider. Will re-scale and re-upload :D
Right, hopefully this will be better. QLN and Hlog only.
-
Quick answer for now, explanation later...
Hlog shows a few signs of a bridge tap, but it doesn't look to be having much impact on the line.
QLN shows that your line is seeing a lot of "noise", which in reality is other VDSL2 subscribers. This is probably the main reason for the low downstream.
There isn't likely to be a lot you can do.
I'll post more explanation later. In the meantime, can you post the graphs for the SNR-per-tone and Bits-per-tone?
-
I'll post more explanation later. In the meantime, can you post the graphs for the SNR-per-tone and Bits-per-tone?
I'll be interested with these explanations. I'm also with IDNet as it happens, and my QLN is quite noisy as well and my HLOG has a slightly more interesting shape to it than I remember. Don't want to pollute Zico's thread so will look and learn from what you post for him.
-
Quick answer for now, explanation later...
Hlog shows a few signs of a bridge tap, but it doesn't look to be having much impact on the line.
QLN shows that your line is seeing a lot of "noise", which in reality is other VDSL2 subscribers. This is probably the main reason for the low downstream.
Assuming the two textual files attached to Reply #7 are the data files for the most recent Hlog and QLN plots . . .
The circuit electrical length equivalent (cele) is -23.7 dB per sub-carrier. (The more positive the value of cele the better.)
The average noise floor (anf) is -112 dBm/Hz per sub-carrier. (We would typically expect a "good" circuit to have an anf value of -140 dBm/Hz per sub-carrier or lower (i.e. more negative).)
-
Quick answer for now, explanation later...
Hlog shows a few signs of a bridge tap, but it doesn't look to be having much impact on the line.
QLN shows that your line is seeing a lot of "noise", which in reality is other VDSL2 subscribers. This is probably the main reason for the low downstream.
There isn't likely to be a lot you can do.
I'll post more explanation later. In the meantime, can you post the graphs for the SNR-per-tone and Bits-per-tone?
SNR-per-tone attached. Not sure if you mean Bit Loading or Bitswap so will attach both.
I'll be interested with these explanations. I'm also with IDNet as it happens, and my QLN is quite noisy as well and my HLOG has a slightly more interesting shape to it than I remember. Don't want to pollute Zico's thread so will look and learn from what you post for him.
Hi Jaydub. You're welcome to join in on the thread. If the admin prefer otherwise then I'm sure that you will be advised accordingly.
Assuming the two textual files attached to Reply #7 are the data files for the most recent Hlog and QLN plots . . .
The circuit electrical length equivalent (cele) is -23.7 dB per sub-carrier. (The more positive the value of cele the better.)
The average noise floor (anf) is -112 dBm/Hz per sub-carrier. (We would typically expect a "good" circuit to have an anf value of -140 dBm/Hz per sub-carrier or lower (i.e. more negative).)
The text files in post #7 are for the graphs posted last night.
-
Text files for BitLoading and SNR and graph of Bitswap per min.
-
I was slightly loathe to risk taking his thread off track, as I am not suffering from his lower than expected sync issues nor his interesting looking bit loading graph. However, as Zico has invited me to join this thread, I have attached my QLN, Hlog, DNT per tone and bit loading graphs. (Bit loading to follow in another reply as not allowed more than 3 attachments)
I sync at 80/20, which is no great surprise having our ECI cabinet the other side of our garden wall, however I would welcome views on my QLN graph as there seems to be a greater variation between downstream and upstream figures than most of the data I have compared against. (e.g Chrysalis: different ISP but max sync on an ECI cab).
I'm really posting just to improve my understanding of what can be gleaned from these graphs. If the mods want to seperate this off into another thread, that's fine with me.
-
..... and the Bit Loading graph.
-
It's good either way to get a rough idea of good, bad and ugly examples of the data being posted :D
-
jaydub -- Purely by visual inspection I can say that the QLN plot shows your circuit is operating with an elevated noise floor. There is no obvious source of interference. By eye, I estimate that your circuit's average noise floor (anf) is around -108 dBm/Hz per sub-carrier. (We would typically expect a "good" circuit to have an anf value of -140 dBm/Hz per sub-carrier or lower (i.e. more negative).)
The Hlog plot tells me that there is something peculiar about the metallic pathway making up your circuit. Notice the undulations? They are abnormal. A good Hlog plot "decays" smoothly when "read" from left to right.
-
Thanks, B*cat.
My recollection is that a few months ago my Hlog graph was quite linear apart from the downturn at the end. Unfortunately I have only just paid mu dues, so don't have any history any further back than the 4th December, which looks almost identical.
Is this something I could or should take up with IDNet.
What impact is this likely to have on performance?
I get quite inconsistent single thread speeds on the TBB Tester. Is this likely to due to the elevated noise floor?
-
My recollection is that a few months ago my Hlog graph was quite linear apart from the downturn at the end.
I believe you are referring to what I describe as "tail-end droop". That is quite common on those circuits which terminate in an ECI equipped cabinet.
Is this something I could or should take up with IDNet.
No. There is nothing that they could do . . . other than offer to arrange for an Openreach visit at your expense.
What impact is this likely to have on performance?
Very little, if anything is actually noticed.
I get quite inconsistent single thread speeds on the TBB Tester. Is this likely to due to the elevated noise floor?
No. Not at all. The "TBB Tester" is concerned with the throughput -- the broadband experience -- as provided by an ISP/CP.
The Hlog and QLN plots are telling us something about the physical infrastructure of the metallic pathway -- of the G.993.2 link (and the environment in which it is situated) -- between your CPE and the cabinet based MSAN (configured as just a lowly DSLAM).
-
Thanks for the clarification (and education), B*cat.
-
Yes, thanks for the info B*cat.
-
You are both welcome. :)
I believe WWWombat will, when time permits, make some detailed comments about what can be deduced regarding the circuit's operational behaviour.
-
I'm grateful for any and all assistance but I am in no hurry so there is no need for any rush.
-
Apologies... Family commitments got in the way. Hopefully I'll get a mo this evening!
-
No need to apologise, you're time comes before anyone else.
-
I believe you are referring to what I describe as "tail-end droop". That is quite common on those circuits which terminate in an ECI equipped cabinet.
Tail end droop it is.
Having disconnected and reconnected over the weekend, I know have significantly more droop than before. Too much alcohol over the weekend?! ::)
-
Started to upload to mydslwebstats under my Kitz username Zico.
I might pick up a Pi so I can leave that uploading rather than leaving my main pc on.
-
Quick answer for now, explanation later...
Hlog shows a few signs of a bridge tap, but it doesn't look to be having much impact on the line.
QLN shows that your line is seeing a lot of "noise", which in reality is other VDSL2 subscribers. This is probably the main reason for the low downstream.
There isn't likely to be a lot you can do.
I'll post more explanation later. In the meantime, can you post the graphs for the SNR-per-tone and Bits-per-tone?
Just had a thought about the reference to a bridge tap. The neighbouring farmhouse, barn conversion and new build all have dropwires that run back to the same DP pole. Of the three properties, only the farmhouse has ever been occupied (un-occupied now for a number of months) and likely to have had a phone/broadband service. If the other two properties have never been occupied, could it be possible that dropwire has been run to them but never terminated?
I've made a tweak to the earlier posted dropwire picture.
-
Well the last few days at work were fun dealing with a VM cab being relocated from one location to another 8 metres along the footway. I would love a VM fibre cab where I am :'(.
Still, the weird FTTC connection that I have has been up and stable for 17 days and 9 hours. I'm curious now to see if anything changes if I were to reboot the router and see if the Tx/Rx power and sync may change for the better.
-
Little bump.
Had a power cut just over a week a go. Before this the line had be up and functioning fine aisde of the strange sync stats.
Took a small hit on both downstream and upstream connection speeds.
@WWWombat, wondered if you had the chance to expand on the earlier posts. I've also been uploading to MyDSLWebStats under the same username of Zico.
-
Another bump.
Well about a week ago 8800NL R2 decided to reboot itself and on re-connecting both down and upstream connections had dropped a little further.
This morning at 8:31am the sync dropped.
Looking at the stats, the Upstream sync has taken a massive hit from ~11500 to ~6919 and Downstream from ~56000 to ~52000.
Downstream CRC's hit ~2500 from near enough (consistently) nothing since the line was installed. Upstream had a spike of 28 SES, whereas Downstream had a spike of ~750 ES.
I've pretty much been keeping MyDSLWebStats updated since mid December and have had almost no errors or issues until today.
:(
-
I wonder if today's problem is weather related . . . high loads on the electricity distribution system, sudden switching as routes become unavailable, odd spikes and/or brown-outs? :-\
-
No power issues. Locally the weather and snow has been bad all week. Today was no different from the beginning of the week.
-
Happened to notice that things appeared to be better this evening/morning. Took the decision to update the firmware on the router and then allow the reboot/resync this morning to be the benchmark for Saturday.
Will see what happens tomorrow and if the mysterious errors knock the line off again.
-
Two further resyncs this morning. 7:19am and 11:04am. Interleaving depth of 1049 was added to the Downstream at 7:19am : (but yet downstream attainable went from ~57 to ~64 and upstream from ~11.4 to ~12.3).
SRNM for down and upstream have been weird over the last week or so with them snaking up and down throughout the day.
-
but yet downstream attainable went from ~57 to ~64 and upstream from ~11.4 to ~12.3).
INP + Interleaving causes the max attainable to be artificially inflated by roughly 10%.
That seems to match your figures.
-
To clarify on the post j0hn made above this one, I'm fairly certain it's the 'delay' parameter which increases the attainable rate while the 'INP' parameter then reduces the sync rate at which the connection can be established at without also affecting the attainable rate.
I know this because when I was playing around with the DSL-AC68U via the TC Console I was able to modify the INP/delay parameters for the downstream, something which no other modem outside of a Mediatek chipset can do and under normal circumstances shouldn't happen, when I increased only the 'delay' parameter my attainable rate increased along with my sync rate and when I added various levels of 'INP' then my sync rate decreased while the attainable rate remained the same. Despite the stability issue of the DSL-AC68U I'm fairly certain it was giving me correct stats at the time.
-
It's probably possible to enable the "improved" attainable rate calculation somehow so that it does take into account the INP requirement.
-
I wouldn't trust anything from the Mediatek chipset.
The fact you can play with UPBO, override the DSLAM, tweak various power settings, etc, shows me they have a very loose attitude to following ITU standards.
The way they calculate the attainable is way off how Broadcoms do. They over inflated the attainable with G.INP the same way they do with interleaving. There's no delay with G.INP, not on Bearer 0 anyway.
Only when my line was on Fastpath was the attainable anywhere near accurate.
My attainable on my DSL-AC68U was some 30Mb+ over inflated at times.
-
I wouldn't trust anything from the Mediatek chipset.
The fact you can play with UPBO, override the DSLAM, tweak various power settings, etc, shows me they have a very loose attitude to following ITU standards.
The way they calculate the attainable is way off how Broadcoms do. They over inflated the attainable with G.INP the same way they do with interleaving. There's no delay with G.INP, not on Bearer 0 anyway.
Only when my line was on Fastpath was the attainable anywhere near accurate.
My attainable on my DSL-AC68U was some 30Mb+ over inflated at times.
G.INP we know was flawed on the Mediatek however so that's very true, however I didn't find my attainable rate to be way off (I didn't have G.INP). But my own experiences can differ from others. I'll leave that there as I don't want to go into a debate over Mediatek and potentially derail this thread :).
-
Well another few fun developments.
After several re-syncs on the line a few days ago I ended up with interleaving on the downstream. After a couple of days another re-sync and I'm back to no interleaving.
Still appear to be getting the odd spike of errors that appear from nowhere.
Now, as of approx. 22:05 on Tuesday evening, I am getting ~200,000 FEC errors on the upstream that have almost been constant. There are several points at which the FEC errors simply stop before returning back to ~200,000. Screen snip attached from MDWS.
-
I agree that something weird is occurring but I can't deduce any possible causes. ???
-
Fec log as of 22:00 tonight.
I'm not sure if it's worth contacting IDnet to see if they can see any error on the line or not.
-
Have you checked within, and close by, your own domain for any strong RFI emitters?
-
I've nothing to check with for any local RFI issues unfortunately.
The only things that I can think of that could have an impact on the line all occured months back:
- Our internal oil boiler was replaced in October with an external oil boiler that is beneath the dropwire going back to the main DP. The line wasn't installed until after this so I would be none the wiser if there was any RFI from the boiler looking back at the earlier error free logs.
- The washing machine (located in the rear of the house relatively near the dropwire which passes by kitchen) had an issue with a PCB which was replaced on Wednesday. Again, if there wasn any RFI issues from that, it's not something that I would have expected to carry on now.
- The rest of the overhead line goes back along the main road where several months back the street lamps were upgraded to LED. Again, don't believe the most recent blips are linked with that.
I'll see what happens over the next few days. It's unfortunate that MWDS is coming to a close at this time as the logs are a great help at seeing things in detail over time. I'm keeping DSLstat graphs but it's not quite the same.
**Edit**
Even as I type this reply, I've seen that the FEC errors are back at just after 22:02.
-
Another fun mystery is happening on my line now. Sunday both the down and upstream SNRM took severe hits and dropped from ~6.2db to ~3db from around midday to late evening. Without reason they both returned to ~6db and carried on. CRCs started in single digit figures and FECs carried on doing there strange ~200,000/~100,000/nothing movements upstream only.
Unfortunately for some reason DSLstats stopped capturing logs from the 14th March so I've nothing to look at over the last few days. Luckily for me, it's all started again at just before 2am this morning. Downstream SNRM is 5.4db but upstream is 2.9db, CRCs ~10/min, FECs as before, some ESs >10/hour (no SES).
I'm on an ECI cab (now that MDWS is no longer there to view) and pretty sure that it's not related to the 3db changes.
-
I can't think of anything that would give rise to such an experience. However from the text file that you have made available, I note --
ES: 177 1352
SES: 46 0
UAS: 156 110
AS: 1282302
All UAS, ES and SES should be viewed with a degree of concern.
-
The upstream sharp dip could indicate an emerging HR fault. The down spike then back up at lower level is something I've observed on several lines usually occurring when the phone rings and whilst on a call. However with it being 1:45 I doubt this would be the case.
Failing that a short burst of SHINE followed by REIN. Both HR faults and REIN are hard to track down unfortunately :( Sorry that I can't add anything else of much use :/
-
I can't think of anything that would give rise to such an experience. However from the text file that you have made available, I note --
ES: 177 1352
SES: 46 0
UAS: 156 110
AS: 1282302
All UAS, ES and SES should be viewed with a degree of concern.
Looking at the stats, that appears to be the total over the last 17 days and 6 hours.
The figures for the last 6 hours on the log are better reading I gather:
Latest 1 day time = 6 hours 20 min 30 sec
FEC: 0 70160831
CRC: 46 39
ES: 46 38
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
-
The upstream sharp dip could indicate an emerging HR fault. The down spike then back up at lower level is something I've observed on several lines usually occurring when the phone rings and whilst on a call. However with it being 1:45 I doubt this would be the case.
Failing that a short burst of SHINE followed by REIN. Both HR faults and REIN are hard to track down unfortunately :( Sorry that I can't add anything else of much use :/
I'm not sure when the SRNM dropped the other night but it was late. The landline that this service is on doesn't receive many (if any) calls and is connected in the same room where I sleep (so I would have thought a 1:55am call would have woken me :D).
I've tried a few quiet line tests over the last few days and I have had the odd bit of noise on the line. This might be a sharp burst and nothing more or a few crackles over a second or two then nothing. I've tried to check the stats after I have tried the tests and believe that there has been a small (single digits) spike of ESs (can't tell with the CRCs being in the hundreds of thousands).
I have a Raspberry Pi 3B+ coming in a few days so will reconfigure DSLstats on that and upload some results in due course.
Thanks for the continued input people!
**Edit**
SNRM graph for the day so far.
Line appears to return to normal levels around 9:40am.
Apparently I had a call on the line at 12:51 this afternoon from god knows who (03303136748 - no sensible results from Google that I can find). Doesn't appear to have impacted the SNRM though.
-
A quick bump on my thread after having a surprising split second power outage.
At about 17:00 hours, the power went off and came back on within about 15 seconds.
I was sat watching a youtube video and once power had came back on I fired up VNC viewer to check out DSLstats after the router had reconnected.
To my surprise, the connection was reading 80,000kbps down and 20,000kbps up with health SNR readings of 6db up and down. Attainable speeds were reading at ~86,000kbps and ~25,000kbps respectively.
I've never seen these connection speeds since the line was installed. Unfortunately this was short lived. On wondering away from my desk for a few minutes, I came back to find that DSLstats reporting the typical ~56,000kbps / ~12,000kbps connection stats (same SNR figures of ~6db and attainable figures slightly hire than actual connection).
I'm guessing that the massive drop back down is crosstalk at the ECI cabinet kicking in after neighbouring lines have re-connected. If that is the case, I'm slightly annoyed at the large drop off on my line as a result. While I've lived with the connection for 8 months (which has been pretty much stable all the way through) I've paid IDnet for a full year up front for the 80/20 package.
I've fired off a support ticket to IDnet a few moments ago to get them to check their records to see the connection and take a look at what might be happening with line.
-
Connection speed snapshot attached to prove I wasn't dreaming.
-
I've seen big increases on our connection at work during power cuts, unfortunately unless you can get a pair swap there's nothing you can do about it, even then there is no telling if or when the new pair will be affected.
-
If it's something that may help, it could be worth enquiring about. It's just a shame that being connected to an ECI cab, thing are likely to stay like this for the next 5-10 years until full fibre is in place.
Oh, on something off topic, it looks like I might be coming down with shingles :no:.