|
|
Some of you may have read my continuing issue with speed drop since moving from a pretty stable Plusnet connection on 25th April to BT. Here and Here. From the second I migrated, I lost 10Mbps in speed, going from a sync speed of 68Mbps to 58Mbps. Next day, my sync dropped again and has slowly dropped every day since until the connection dropped dead on 7am this morning and I reconnected at 49Mbps with interleaving now turned off. Speedtests are abismal at around 40Mbps and the TAP3 test fails but BT are adamant there is nothing wrong.
Last week I purchased a HG612 to replace my Billion 8800nl (just to rule out modem issues) and my line was reporting an attainable of about 55Mbps even though the actual sync never got above 45Mbps and throughput was never above 40Mbps.
This morning's drop was the last straw so I plugged the 8800nl back in. Hey presto attainable no back up to 60218Kbps and sync'd at 60214Kbps with an snr of 6.2.
Not sure what is going on but think I might have bought a dodgy HG612. It definitely had the latest firmware.
I'm now hoping G.INP might kick back in now (got taken on on my migration) and I could regain the extra 8Mbps I had before I moved from Plusnet.
Latest stats incase anyone is interested in commenting or can see something strange:
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 17076 Kbps, Downstream rate = 60222 Kbps
Bearer: 0, Upstream rate = 17080 Kbps, Downstream rate = 60214 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): 6.1 6.1
Attn(dB): 19.2 0.0
Pwr(dBm): 12.6 7.5
VDSL2 framing
Bearer 0
MSGc: 18 21
B: 239 237
M: 1 1
T: 64 64
R: 0 16
S: 0.1268 0.4434
L: 15136 4583
D: 1 1
I: 240 127
N: 240 254
Counters
Bearer 0
OHF: 840724 241393
OHFErr: 8408 1
RS: 0 2562523
RSCorr: 0 1
RSUnCorr: 0 0
Bearer 0
HEC: 440 0
OCD: 0 0
LCD: 0 0
Total Cells: 198358854 0
Data Cells: 7094544 0
Drop Cells: 0
Bit Errors: 0 0
ES: 1259 1
SES: 0 0
UAS: 30 30
AS: 1710
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 2.03 7.12
OR: 94.23 30.32
AgR: 60308.42 17110.39
Bitswap: 25/25 4/4
Total time = 29 min 3 sec
FEC: 0 1
CRC: 8408 1
ES: 1259 1
SES: 0 0
UAS: 30 30
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 14 min 3 sec
FEC: 0 1
CRC: 4181 1
ES: 600 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 4227 0
ES: 659 0
SES: 0 0
UAS: 30 30
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 29 min 3 sec
FEC: 0 1
CRC: 8408 1
ES: 1259 1
SES: 0 0
UAS: 30 30
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 28 min 32 sec
FEC: 0 1
CRC: 8408 1
ES: 1259 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>
-------------------------------------------
Plusnet Unlimited Fibre Extra
Speedtest
My BQMEdited by WelshWArrior (Sun 15-May-16 11:32:13)
|
|
|
|
Post deleted by WelshWArrior
|
|
|
|
Looking on mdws after 7 am (DLM re-synch) your sync was 53,969 on the hg612, with no error seconds
sync on the billion 60,214 with LOADS of error seconds.
Try the hg612 again.
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
I'll give it a go once I get home.
|
|
|
|
I see you have interleaving (1121) after all the error seconds the billion caused yesterday.
You still had a reduction in error seconds at 7PM to 10 PM last night and I'm sure we will see a reduction in FEC's at the same time tonight.
Put the hg612 back on until you are back on fastpath (or interleaving = 1)
then resync at this "quiet time" (between 7 and 10 PM)
Ian
|
|
|
Hi Ian
Yes by the time I got back last night , all I wanted to do was go to sleep (kids had worn me out haha) so didn't get chance to swap them back over. I'll do it later.
I'm still puzzled about why G.INP hasn't kicked in? I've never had interleaving turned on until I migrated from Plusnet to BT - I always had G.INP and it not only increased my sync speed to 65Mbps, but seemd to keep all the errors at bay.
The errors have been happening since 20th November and die each night at exactly 19:00hrs until 22:30hrs when they appear again.
|
|
|
|
Some funny things going on, certainly.
I looked at MDWS for the last 10 days, where it is quite obvious the DLM had currently left FEC+Interleaving activated, with INP=3 and delay=8 quite consistently. It doesn't matter that the depth has altered - that results from a variety of calculations and compromises. The INP & delay values stayed consistent from the 8800 into the HG612.
The fact your speed dropped with the HG612 is strange ... as it ought to have resulted in a high SNR value, but it didn't. Your SNR stayed at 6dB. We don't know why this happened, but the result is an "artifically low" speed for your line, compared to previous expectations.
The other impact that an "artificially low" speed should have is a reduction in errors ... and you certainly seem to have seen that, all through the initial placement of the HG612. MDWS reports that, through the 12th, 13th and 14th, you suddenly lose almost all CRCs (there weren't many to start with) and the FECs reduce to 1% of what they were. A huge, huge reduction in FECs!
Things changed markedly as of 7am on the 15th (Sunday). Presumably as a consequence of this huge reduction in FECs, DLM has taken away the need for FEC+interleaving: INP gets set to 0, delay gets set to zero, and the line resyncs.
Up until 7am, this was certainly all good news - the HG612 was doing better, and (perhaps by that low speed) helped your line to reduce the error rate enough to get DLM to recover.
From 7am until 10:30am, the HG612 kept going at a new speed of 54Mbps, and with almost no errors again - obviously no FECs now, but still very few CRCs and therefore few ES's - only 30 accumulated in those 3+ hours. Things were looking promising, error-wise, even if this was not top speed ...
Unfortunately, as you say in you OP, "This morning's drop was the last straw so I plugged the 8800nl back in." Instead of seeing the HG612 behaviour as positive, you threw it out ... and quite possibly threw the baby out with the bathwater.
Once the 8800NL was plugged back in, it gave you that good speed - 60Mbps - but it also gave you a terrible error rate. Hundred of CRCs from 11AM to 7PM, and more from 22:30 onwards. You ended up accumulating over 22,000 ESs by midnight, and another 15,000 between midnight and 7AM. This is a long way over the 24hr threshold of (max) 2,880 that would apply to a Plusnet line.
The result isn't a surprise ... DLM kicked in again, immediately. INP=3, delay=8. FEC+interleaving turned on again, speed reduced again, and hundreds & thousands of FECs.
It looks to me like your line is inherently noisy, in a way that causes the 8800NL to see a lot of FECs, an awful lot of FECs, resulting in DLM giving you FEC+interleaving-style intervention. The HG612 seems to see the noise too, but treats it significantly differently - giving you a lower speed that can overcome the noise better, resulting in much lower error counts.
I think that plugging the 8800NL back in was a bad move.
Who knows ... if you had left the HG612 in place for longer (possibly much longer), DLM may have analysed your (free/open/non-interleaved) line differently, and chosen to activate G.INP and we'd see a completely different outcome.
I agree that the behaviour of your line is puzzling - and the seeming coincidence of migrating to Plusnet adds to the puzzle. But the behaviour I'm seeing has nothing to do with the ISP, or a switch of ISP.
As your line looks like it (now) picks up a lot of noise, you either
- Have to persuade BT of this fact, and get it fixed or changed
- Have to choose to use an 8800NL, which gives you higher speed with interleaving
- Have to choose an HG612 which gives lower speed, potentially without interleaving
- Try other modems.
|
|
|
Thanks for that WWWombat - must have taken a while to write  Very interesting though. I did plug the HG612 back in during my lunch break today but DSLstats seems to have crashed and I can't remote to it from work. Not sure if you even can remotely manage the HG612 like you can the 8800nl??
I think I'll leave it plugged in for a few weeks and see what happens. I'll try ian007jen 's suggestion above initially - wait for interleaving to switch back off and then resync during the quiet time to see it that gives me some speed back.
I'm planning on doing some more scouting around to try to find the source of this noise - possibly with an old AM radio (I think??) around my property first in the faint hope that it's something that i can definitely do something about.
Not that it matters but I went from Plusnet to BT.
Edited by WelshWArrior (Mon 16-May-16 15:51:04)
|
|
|
Grab some "Bitloading Graphs" from DSL Stats ensuring that under <Config>, <Items to monitor> you have <SNR per tone> and <Include with Bitloading> ticked.- reasonably expanded so that you get all tones shown across 5 images and host those somewhere. We can have a look and see if there are any strange notches and how it compares to "normal" plots.
If there is a noise source you may well see a large notch as the approximate frequency with the effect spreading each side. If it is very wideband then everything will be suppressed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
Thanks MHC - I'll get these done in the next hour and post a link to them.
|
|
|
|
The bit/tone graph is already available on MyDslWebStats
|
|
|
It is, however that is not with the current modem and even with zoom, not the best to look at.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
Can you remind me of the approx distance from cabinet to house.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
It is, however that is not with the current modem Which modem is that live graph from, if not the current one?
|
|
|
What I am seeing now is different from about 2 hours back which may well have been from this morning ... and the advantage of a captured set is that it allow you to look in detail at it without it being updated.
And it does NOT have the SNR overlay which I suggested be included.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
Edited by MHC (Mon 16-May-16 17:15:52)
|
|
|
|
You can look at all the historic bit/tone graphs on MyDslWebStats and compare them with others.
|
|
|
about 246m according to OR engineer. Actual distance by foot is literally 130m
|
|
|
It looks to me like your line is inherently noisy, in a way that causes the 8800NL to see a lot of FECs, an awful lot of FECs, resulting in DLM giving you FEC+interleaving-style intervention. The HG612 seems to see the noise too, but treats it significantly differently - giving you a lower speed that can overcome the noise better, resulting in much lower error counts. This could be the cut-off noise level on a tone causing it to be disabled being different, not necessarily by much, between the two modems.
The HG612 cuts the affected tones out and gets a stable lower sync. The Billion leaves them in, gets the higher sync, and suffers the consequences when DLM says ouch at the error count.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 59546/15321kbps @ 600m. - BQM
Edited by RobertoS (Mon 16-May-16 20:46:34)
|
|
|
I didn't have 'include with bitloading' ticked so I have done it now. Is it better to wait now until tomorrow until I have a few graphs produced before I upload some for you to see?
|
|
|
Upload a set now - might be worth looking at.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
|
|
|
|
The last one which shows both bit-loading and SNR is the right type - can you now get the same zoom level or maybe slightly less (~500 tones per graph) for the remaining tones up to just under 4000.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
|
|
|
|
Nothing here that really stands out. However, comparing that to mine (400m line) shows that in general your SNR is 6dB lower and typically each tone is carrying 2bits less as a result.
It points towards you being unfortunate to have a noisy line with no specific blocks of tones being affected just fully across the board.
Try using a MW radio - you might be lucky and detect something.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
|
Looks fine to me too. In fact, the gradual drop in tones over D3 is remarkably smooth.
Is this back on the HG612 again? Perhaps we should expect it to appear smoother than the 8800NL.
Right now, I would plan on keeping the HG612 connected full time, attempting to leave it running with no disconnections (so if we see one, we can assume it wasn't caused by human input), and attempting to leave logging running as close tyo 24/7 as possible.
|
|
|
Hi - yes it is back on the HG612 and those graphs were from it too. I will keep it on the HG612 from now on. Logging runs and uploads 24/7 to MyDslWebStats so we can keep an eye on it.
Do you think it's worth waiting until interleaving is off, leaving it a few days and then resyncing during the nightly quiet period to see if I can get my extra 10Mbps back?
|
|
|
I am guessing that the early dip up to tone 515 is due to power masking - on mine it stops at around 250 although even under that WW has bitloading of 14 down to 6 which is better than my 9 at teh low end and 4 around tone 180!
It is after that where WWs bitloading is low - 10 at tone 520 compared to my 14 and all the way up WW is around 2 or 3 bits lower than me - roughly 25% which, using mine as a benchmark, would put his sync around 60Mbps.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
Leaving aside your current running with the HG612, I wanted to explore what has happened to your line in the past.
So can I just say ... brilliant. You've got a year's worth of stats on MDWS, and it appears to have been worthwhile. All except for a gap between October 14th and October 26th.
I've been looking at graphs covering the full 360 days that it will show me, and I can see some interesting things.
1) It doesn't look like your problem started on shifting from Plusnet to BT (April 25th?). It does, however, look like the shift caused your modem (and DLM) to begin to deal with the issues rather differently.
2) It looks like something significant started to happen around 23:00 on November 20th last year.
All the graphs that depict error counts, or the response to errors, start to go haywire at that point.
Right now, I can see you had G.INP retransmission active on September 24th, all the way through to your change in April.
I therefore went looking for the graphs that show whether G.INP is encountering errors; you would expect to see (in order)
- the FEC counters go up;
- the retransmission counters go up;
- failures to retransmit start to indicate non-zero;
- CRC errors start to indicate non-zero;
- A "low error-free throughput" counter goes non-zero
- The "minimum error-free throughput" value starts to drop below the sync speed
Here are the graphs that show
- FEC and retransmissions go up: http://postimg.org/image/72v3psh5d/
- Retransmission failures happen: http://postimg.org/image/l5n04mqq9/
- Low error-free throughput indications start: http://postimg.org/image/qfr1t6d3l/
Quite clear, isn't it?
Zooming into the FEC graphs shows that, in November, the errors occurred regularly from 2300 to 1500; in March, they were 2300-1600, and by the end in April they were 2300-1700. The newer FEC levels (as part of full interleaving) in May they were 2300-1800.
The errors are, frankly, happening at a horrendous rate, but G.INP is doing an admirable job at coping - so you /thought/ everything was OK.
When you swapped to BT, it looks like a DLM reset likely took away the G.INP settings that were protecting your line - protecting both your line speed, and your connection's quality.
Speed dropped, and errors flooded through ... and DLM, starting decision-making from scratch again, obviously decided that there was no way that retransmission would be able to cope with your line at all, so sat it on the interleaving "naughty step" instead.
So ... what happened on November 20th?
|
|
|
Nice thorough explanation there - thanks!! Totally agree with it all. I did know about the 20th November date when all went mental but as of yet, have been unable to pin it down to anything of my doing/on my property.
One thing I have read up on this morning when researching what can cause electrical interference to VDSL2, is that touch lights can be to blame. Now thinking about it, the wife bought some bed-side table touch lamps from Argos around November last year. I am wondering whether they could be to blame. I have had all the power turned off a few weeks ago, meaning they were off too but I'm going to disconnect them again later to check.
I'd love it to be something on/in my property to blame as obviously I can do something about it but have a horrible niggling feeling that it's elsewhere  I am NOT giving up yet though . . . . .
|
|
|
I am guessing that the early dip up to tone 515 is due to power masking - on mine it stops at around 250 although even under that WW has bitloading of 14 down to 6 which is better than my 9 at teh low end and 4 around tone 180!
Yes, the dip will be WWarrior's own cabinet's power-masking to keep compatibility with ADSL there.
The dip varies from cabinet to cabinet, depending how far the cabinet is from the exchange (or, more precisely, how the ADSL signal has fared between the exchange and the cabinet).
If the cabinet is far from the exchange, the dip needs to be more extreme, because ADSL signals will have attenuated a lot. However, that extreme dip only needs to bother with low frequencies (the higher ADSL tones will have attenuated to nothing), so can give full power back to VDSL2 sooner than tone 512.
If the cabinet is close to the exchange, it doesn't need such an extreme dip ... but keeps the lower power until above the highest ADSL2+ tone (ie tone 512).
Comparing WWarrior's bits/tone graph with the ANFP, I'd guess his cabinet was about 1km from the exchange (CAL=10). If your dip ends around tone 250, or 1MHz, then I'd guess your cabinet was around 3.5km from the exchange.
My dip ends around tone 380, and the cab is perhaps 2km from the exchange.
It is after that where WWs bitloading is low - 10 at tone 520 compared to my 14 and all the way up WW is around 2 or 3 bits lower than me - roughly 25% which, using mine as a benchmark, would put his sync around 60Mbps.
The QLN plays a part in this too - a line that shows a lot of noise on the QLN graph ends up with a lower SNR value.
|
|
|
Just measure with Google Earth along the road (which is the path I know the fibre takes from the exchange) an it is indeed, just under 1km from the exchange.
|
|
|
Do you think it's worth waiting until interleaving is off, leaving it a few days and then resyncing during the nightly quiet period to see if I can get my extra 10Mbps back?
Having seen all those errors, I suspect you should probably aim for more of a stable line, than hankering after past glories speed-wise.
My first step would be to use the HG612 to get DLM to relent with interleaving.
My second step would be to keep the HG612, to persuade DLM to restore G.INP retransmission.
If you get to that point, I'd leave it for a good while (many days/weeks; at least a month) to get MDWS statistics comparable to the December-March set. The aim would be to see what speed, and what errors are happening (in the 6 graphs I posted). I'd use that time to answer this question: Is the HG612 giving you /almost/ the right speed, with considerably better error statistics than December-March?
If DLM doesn't relent with interleaving, your first priority would be to get rid of the cause of the errors.
If DLM doesn't turn on G.INP, your priority changes slightly - to figuring out why. The error rate might still be part of the issue, but DLM has become somewhat unpredictable lately, and there might be another issue.
If you get things settled well, you have restored G.INP retransmission, and have a good bag of statistics under your belt, then you might hazard an attempt with the 8800NL to see if it improves anything on the HG612, while keeping errors acceptable.
I absolutely wouldn't put the 8800NL back on again until retransmission was turned back on, and I would watch it like a hawk for any sign of retransmission being turned off, or errors getting too high.
|
|
|
The QLN plays a part in this too - a line that shows a lot of noise on the QLN graph ends up with a lower SNR value.
I agree, and looking at that suggests his line is a little noisier than mine ... It does really seem to point to high noise levels across the band potentially from crosstalk although nothing can explain the clean hours in the evening.
One really wild thought that comes to mind - could there be a split pair in use, not for the full run, just for a few metres or tens of metres? Something like the DSLAM to PCP link, or between a couple of footway chambers ... That might be enough to allow for significant cross talk but not enough too totally kill the signal. It should not happen, however, there is always the possibility.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
I'd love it to be something on/in my property to blame as obviously I can do something about it but have a horrible niggling feeling that it's elsewhere I am NOT giving up yet though . . .
The times are an interesting factor to figuring this...
- 2300-1500 in December
- 2300-1600 in March
- 2300-1700 in April
- 2300-1800 in May
Is there something regularly turned on at 2300? Or put into standby? Or turned off?
Garden lighting? A pond?
|
|
|
And if we solve this for WW he will owe us a trip to Fecci's !
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
This is what I've been racking my brains about for a few weeks. There's nothing at all on my property that is on a timer. I have a PIR LED floodlight in garden but that hasn't been powered on (i.e plugged into mains socket) since before Christmas. Apart from that, nothing.
I'm trying to borrow an old AM radio to attempt to trace it that way but that is proving VERY difficult!
|
|
|
LOL would that be Feccis Chip shop or Ice Cream Parlour??
If you help me get to the bottom of this, I'll happily splash out
|
|
|
Definitely sounds like a plan to me!
|
|
|
LOL would that be Feccis Chip shop or Ice Cream Parlour??
If you help me get to the bottom of this, I'll happily splash out
Both ... I can remember going to Fecci's Ice Cream parlours in the 60's & 70's
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
HaHa they're both still there. Probably the sons running them these days though. Apart from that, they probably haven't changed much since the 60s!!
|
|
|
|
|
|
|
Ordered and picking up from local store tomorrow - thanks
|
|
|
I MAY have found the source! I decided to tune the radio to AM 600Mhz and have a drive towards the cab last night as I was going to the shop. As i got near the cab right opposite THIS grey box, the radio went nuts with noise!
Could it possible be the culprit? The Fibre Cab can be seen to the left of the grey noisy cab and the PCP is inbetween the two of them in the hedge.
Is that a power supply for the cab?
|
|
|
600KHz I presume?
No idea what the grey cab is, not sure what the sweet spot for interference that will play havoc with VDSL2, but VDSL2 is in the range up to 17 MHz, so hunting around in the short wave bands might be useful.
What also matters is how far from the grey cabinet that you were getting lots of noise, e.g. if radio sat on casing then no surprise, but if ten or more feet away I'd not expect it.
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
Yes 600KHz - sorry.
I was sitting in the car exactly where I took the pic from. I'd say 25ft away. Soon as I drove away from the grey box in either direction, it stopped. I drove past several times and it was the same - noisey when near that box but just general quiet background noise along the rest of the road.
|
|
|
600MHz - you mean 600kHz
Yes, it could be the source and NO it is not the power supply for the cabinet.
Can you get a closer picture? or provide a Google Maps link to the location?
When you go past next, can you look and see who owns it ... are there any markings at all?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
I see you have a Galaxy S7 Edge!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
Google Maps street view
I'll do my best to get there tonight once the wife gets back from work and takes the kids off my hands 
I'll try to get a closer pic too if need be and also look to see if there are any labels/clues to the owner.
Edit: I forgot to add that directly opposite the grey box (behind me in the car) there is an electricity sub-station. Cold that grey box be related?
Edited by WelshWArrior (Wed 18-May-16 12:18:10)
|
|
|
Hahaha yep - hell of a phone. Kicks Apple's butt all day long
|
|
|
On the opposite side of the road is another PCP and a Grey rectangular building maybe 2x1.8m = any idea what that is?
Also try having the radio tuned at the other end of the band too - 1600 KHz ... it is unlikely you will find a cheap radio that will do the 2 to 20 MHz band.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
That's not a PCP - I think it's linked to the big grey box next to it which is an electricity sub-station. Could the little grey box be related to that?
|
|
|
Plus a bit of post processing with Photoshop CS2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
No processing - just resized with CS2. No need post processing with the S7 edge - the pics are just that good lol
|
|
|
Well you know what I meant!
The box could be linked to teh sub-station. You also need to try the radio outside there too and also walk up close to both.
Also, go and try it this evening after 19:30 when all is quiet!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
|
Is the fibre cabinet/pcp on the other side of the road the one you're served from? If so, Id expect everyone on the cabinet who has VDSL to be experiencing the same issues.
The fibre cabinet is only visible when looking from the main road, the images taken on the road where the grey substation is seem to be older and only show PCP3, not the fibre cabinet.
|
|
|
Hmmm. Isn't the substation more likely to be the culprit? I have looked to see if (your) pole-fed line goes over that, but the nearest is quite a way to the left so probably not affected.
Whether or not, I suggest you pick a time when the noise isn't apparent on your line and check this area again with the radio.
Edit - I see MHC posted similarly while I was pondering and re-examining the street view.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 59240/14753kbps @ 600m. - BQM
Edited by RobertoS (Wed 18-May-16 12:44:34)
|
|
|
I'm served from the fibre cab on the same side of road as the grey box - the fibre cab is just visible in the pic I took and posted above. ALL houses on my estate (around 200 or so) are fed from that cab. Those Google street view images seem to be at least 18months old.
The green cab across the road from there is definitely related to the adjacent electricity sub-station as it's got a Western Power label on it.
My neighbour next door was complaining last night how slow his internet is and he's been onto talk talk about it. He's gone away for a month today otherwise I'd have asked him last night if I could get some stats off his modem.
|
|
|
My line isn't pole fed. Mine is about 10 houses up the hill on the right-hand side and is fed via underground ducting. That pole in the pics serves the house directly opposite, the house behind the cab and the ones over the road.
I'll get down there tonight after the noise dies down and see if I can pick it up again.
|
|
|
Yeah i think I'll head back down tonight once the noise drops off after 7pm and post my results afterwards.
|
|
|
Once the ownership of that box becomes clear it may be easier.
The box could be a power junction box for example or something totally different.
Unlikely that a standard substation is going to be a source of very wide band noise - it would be nice to know exactly what is in there and if it does. A standard sub-station will have transformers and control gear only and why there is a green cab outside - distribution I wonder?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
Not sure if the green cab outside the sub station is still used or not - the sub station is a pretty new shell. It was put in a couple of years ago to replace a smaller one that was there. Possibly due to the imminent housing development if 180 houses due to start in the field behind my house. But I haven't seen that green cab open for a long time and I pass maybe 5 or 6 times a day. Often see people working in the sub station though.
|
|
|
I'm served from the fibre cab on the same side of road as the grey box - the fibre cab is just visible in the pic I took and posted above. ALL houses on my estate (around 200 or so) are fed from that cab. Those Google street view images seem to be at least 18months old.
The green cab across the road from there is definitely related to the adjacent electricity sub-station as it's got a Western Power label on it.
As soon as I saw the sub-station, I thought it was a more likely culprit than the small grey box.
Moving the radio from one to the other across the road might help distinguish one from the other.
And in the interests of proper experiments, you might need to try at 6pm, 7pm, 9pm, 10pm and 11pm.
Interesting, though...
My neighbour next door was complaining last night how slow his internet is and he's been onto talk talk about it. He's gone away for a month today otherwise I'd have asked him last night if I could get some stats off his modem.
That's a shame. Is he FTTC or ADSL?
|
|
|
when you go back can you also look at the manhole covers (maybe take photos) since they may show some more info.
incidentally, did you notice on the streetview photos, there are some taken at different times, some including the fttc cab, and others not. and one with bt engineers at the pcp
|
|
|
As soon as I saw the sub-station, I thought it was a more likely culprit than the small grey box.
Moving the radio from one to the other across the road might help distinguish one from the other.
And in the interests of proper experiments, you might need to try at 6pm, 7pm, 9pm, 10pm and 11pm.
Interesting, though...
Substations tend to be three phase transformer based - so noise will be at the very low end and even when rectified just 300Hz and the harmonics of that. It will be the 11th harmonic which is the first outside the voice band and that will be way down - unlikely to have an effect all the way up.
The may be other equipment housed in there too - I wonder what WW's checks later will show.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
Yep I'll get some pics. Hadn't noticed until you just mentioned all the different times of pics taken. OR guys don't seem to be too busy
|
|
|
I'll do my bets to do several tests later.
Not sure what my neighbour is using but knowing him (he likes to keep up to date with modern tech, plus he has 3 teenage kids!!) he's on fibre but I can't say for certain and they've left now.
I just did a driveby with AM 600KHz running on way back from my lunch break and I noticed a lot of noise (as much as next to the grey cab) soon as I pull onto my driveway! Whereas the rest of the trip from the cab is pretty quiet! Wondering what's buried beneath my driveway now!!!
|
|
|
Your FEC's have reduced substantially, my guess is a bad electrical earth somewhere (sub station pehaps) and it has been fixed.
See you in fecchi's in 30 mins.
|
|
|
hahaha!! Unfortunately, the FECs always drop between 19:00hrs and 22.30hrs each night like clockwork.
I didn't receive my handheld AM radio yesterday so couldn't do my tests last night. I'm hoping it'll get delivered today so i can get out later and track the source down
|
|
|
|
Have you looked at your stats....tenbyboy2 on mdws?
|
|
|
I've been watching them at least twice an hour every day. I'm still getting spikes of over 500FEC/hr but that's much much better than the 400,000FEC/hr I was getting before
Fingers crossed now that interleaving drops off and I can regain my speed.
|
|
|
Your FEC's have reduced substantially,
Have they?
To me, they look like they are running at the same level as on May 14th. Lots of spikes, but at under 1,000 FEC's per minute compared with May's peak 100x as big.
On that day, FECS had reduced because @WWarrior had put the HG612 in place, and it ran at considerably reduced speed. Not because of a fix anywhere - evidenced by the FEC reappearance with the 8800 back in place.
As @WWarrior has put the HG612 back in place again, and it is running at low speed, the FECs are continuing to do what I'd expect.
On the line, we're waiting for DLM to choose to de-intervene ... in the hope that it eventually turns on G.INP after that.
Away from the line, @WWarrior is seeking a source of noise, and I think he should continue to do that ... disturbing the line as little as possible.
I suspect the fact the DLM de-intervened once already, but (with the 8800 swapped back in) needed to re-intervene quickly, has slowed down any de-intervention response right now. Patience advised...
|
|
|
^^^ What he said
|
|
|
^^^ What he said
Brain fade...of course; I am a fool; to much other stuff going on.
Edit (typos)
Edited by ian007jen (Thu 19-May-16 18:45:50)
|
|
|
So here's the thing, many things will make appreciable noise on a radio .... it doesn't mean they are causing interference though.
I seriously doubt that 'mystery grey box' is a cause.
Sadly, this is just based gut feeling, hunch, feminine intuition, etc ..... and 15 years as a REIN engineer.
|
|
|
|
Given the apparent consistency etc of your problems, have you heard any complaints from neighbours etc, fed from the same FTTC & PCP combination?
|
|
|
My neighbour next door was complaining last night how slow his internet is and he's been onto talk talk about it. He's gone away for a month today otherwise I'd have asked him last night if I could get some stats off his modem.
|
|
|
I also have 2 other mates living closer to the cab. One is away working in Saudi at the moment but I'll ring the other tonight after work and see what he says.
|
|
|
Just had an email that the router had resync'd and G.INP is back on. Speed up from 49Mbps to 56Mbps so hopefully if I reboot during the 'quiet time' between 7PM and 10.30pm tonight I might get back up the the 68Mbps I had before my migration. Or do I not risk the restart?
New stats:
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 16759 Kbps, Downstream rate = 56072 Kbps
Bearer: 0, Upstream rate = 16752 Kbps, Downstream rate = 56852 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 6.3 6.2
Attn(dB): 19.1 0.0
Pwr(dBm): 12.7 7.5
VDSL2 framing
Bearer 0
MSGc: -6 21
B: 235 237
M: 1 1
T: 0 64
R: 12 16
S: 0.1321 0.4521
L: 15018 4495
D: 8 1
I: 248 127
N: 248 254
Q: 8 0
V: 1 0
RxQueue: 48 0
TxQueue: 16 0
G.INP Framing: 18 0
G.INP lookback: 16 0
RRC bits: 0 24
Bearer 1
MSGc: 122 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 8.0000 0.0000
L: 32 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 95018
OHFErr: 0 0
RS: 20690048 1783829
RSCorr: 18 0
RSUnCorr: 0 0
Bearer 1
OHF: 42770 0
OHFErr: 0 0
RS: 341665 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 86406979 0
rtx_c: 0 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 56862 0
errFreeBits: 595629 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 75081229 0
Data Cells: 17687 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 22 51
SES: 10 0
UAS: 54 44
AS: 688
Bearer 0
INP: 49.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 7.26
OR: 0.01 29.74
AgR: 56942.85 16781.84
Bearer 1
INP: 2.00 0.00
INPRein: 2.00 0.00
delay: 0 0
PER: 16.06 0.01
OR: 63.75 0.01
AgR: 63.75 0.01
Bitswap: 118/118 3/3
Total time = 1 days 12 hours 31 min 50 sec
FEC: 154808 347
CRC: 4361 53
ES: 22 51
SES: 10 0
UAS: 54 44
LOS: 1 0
LOF: 9 0
LOM: 0 0
Latest 15 minutes time = 1 min 50 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 113 0
CRC: 4317 0
ES: 10 0
SES: 10 0
UAS: 32 22
LOS: 1 0
LOF: 9 0
LOM: 0 0
Latest 1 day time = 12 hours 31 min 50 sec
FEC: 20007 39
CRC: 4319 5
ES: 12 4
SES: 10 0
UAS: 32 22
LOS: 1 0
LOF: 9 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 49605 86
CRC: 24 13
ES: 5 13
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 11 min 27 sec
FEC: 18 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
|
|
|
If you do risk it, make sure you shut down in te right way.
Leave te line connected, and power off the modem/router. Wait a minute then disconnect the line.
Wait a few minutes, re-power the hardware and allow to fully boot and stabilise. then reconnect the line.
Don't give up on finding the noise source though. If you can cure it, your speeds could be even faster.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
|
Wait 30 minutes before powering on to avoid DLM.
|
|
|
Wait 30 minutes before powering on to avoid DLM.
Rubbish.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
I've always wondered what the correct procedure was. Used to think it was just restart from the modem's own menu.
I'll see if I can pluck up the courage tonight but may leave it a few days to settle down on G.INP first.
The portable radio definitely arrives today so I'm not giving up on finding the source of the interference! Infact, as my neighbour is away, I'm planning on going around the outside of his house over the weekend under the cover of darkness to see it the radio pick anything up
|
|
|
I tend to use a power down - a "dying gasp" is sent by the modem which says it has lost power as as such the DSLAM should not react adversely. If the signal is just lost then it can be interpreted as increased noise levels for example.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
That definitely makes sense! I'll use the 'MHC method' when resyncing then
|
|
|
|
DLM doesn't monitor dying gasps. It monitors sync every 15 minutes, therefore wait 30 minutes to ensure DLM knows you've powered down, rather than an unforced resync.
|
|
|
So what?
And how does your DLM know you have powered down? It does not. If it monitors sync and sync has gone it will not know why.
READ THE SIN. That defines a requirement for "Dying Gasp"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
READ THE SIN. That defines a requirement for "Dying Gasp" I didn't say there wasn't a requirement, I just pointed out that DLM doesn't monitor them. This is well-known.
It is also well-known that in order to avoid DLM seeing an unforced resync, you have to wait 30 minutes.
|
|
|
Stop spouting rubbish.
I have done twenty or more re-syncs in an about three hours using the power down method. And DLM did not intervene.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M H C
taurus excreta cerebrum vincit
|
|
|
|
I can provide evidence. Can you?
|
|
|
|
Uh oh. Another thread about to enter a death spiral.
|
|
|
|
Some people just refuse to be informed. Ah well, it's not my DLM after all.
|
|
|
Just had an email that the router had resync'd and G.INP is back on. Speed up from 49Mbps to 56Mbps so hopefully if I reboot during the 'quiet time' between 7PM and 10.30pm tonight I might get back up the the 68Mbps I had before my migration. Or do I not risk the restart?
It might indeed give you faster speeds ... but I'd rather see the stats continue over that period without a restart - perhaps a few days.
I *think* it will only improve speed if you see an improvement in SNR in the quiet period - so I'd rather make predictions after watching the stats for another few days.
It might equally be the case that the HG612 stays less tolerant of the noise than the 8800NL; right now we're using it to convince DLM that you have a stable line, rather than a fast one.
And, right now, I'd also prefer DLM to believe the line is stable, rather than trying to pull the rug out from underneath it a second time.
|
|
|
Some people just refuse to be informed. Ah well, it's not my DLM after all.
I'm well informed - but I take information from a wide variety of sources, mull it all over, and reach my own conclusions.
For some strange reason, yours is a source I find less trustworthy.
Each to their own...
EOT
|
|
|
For some strange reason, yours is a source I find less trustworthy. Oh dear Because we know that the DLM collects data bins every 15 mins and that it monitors traffic count to see if the line is in use, it is therefore recommended if possible to try to leave the router switched off for 30 mins to ensure that the DLM sees at least one complete period of inactivity prior to the resync.
|
|
|
I agree with you totally and think I'll leave it until at least after the weekend before I start messing about again. I think, as long as I do see a speed improvement once I do restart the modem, that I'll leave the HG612 in play too instead of putting the Billlion back on.
|
|
|
Copying something written by Kitz is not 'proof'. Like many of your other "proofs" (*) - they are to be digested, and weighed on the evidence.
Oh, in this instance, I happen to agree with Kitz - and I find her a considerably more trustworthy source than something filtered by you. However, MHC is right that SIN 498 demands implementation of a dying gasp in the modem - but we have no distinct proof that it is used by DLM. Nor do we have proof that it is not used.
It appears that the dying gasp used to be used, but is no longer. DLM is, shall we say, opaque. DLM changes. What was once definitive, is not always so.
My own experience: In 2011, lots of power outages in one day did not trigger DLM. In 2015 - on a day when our electricity kept tripping incessantly - DLM did intervene. Presumably it intervened after *only* seeing dying gasps. Just a lot of them.
To anyone still listening:
Safest option, if you care to be safe, is to follow both strategies: Power off the modem, to provide a dying gasp. Leave it off for 30 minutes to ensure the statistics bin stays empty.
Absolute safest option is to make DLM think a wide-area event is happening, so it ignores your line. Trigger a power cut in the whole district.
(*) A batboy proof appears to be the TBB corollary to Godwin's law. Once reference has been made to a proof, the thread should be considered over.
|
|
|
|
That demonstrates the problem with only reading the final post in a thread. I was providing proof that it was well-known, as I said in an earlier post.
|
|
|
DLM doesnt use dying gasp. It uses MTBR. It will ignore 'x' amount of resyncs, 'x' depending upon the profile selected by your ISP. You are safe to perform 'x' amount of reboots per day. The odd few wont matter as last year BT increased the MTBR allowance.
The 15 min collection of data is fact, and the 30 mins is just a recommendation if you are performing lots of reboots during setting up of modem to ensure it is classed as an unforced retrain.
It may have been better to quote Detection of sync events
Whilst the DSLAM is capable of detecting loss of synchronisation and most modern routers are capable of sending a dying gasp message to indicate when loss of sync was through a power failure, BT's DLM system does NOT take any notice of dying gasp messages when it comes to counting retrain events�.
A retrain event is detected by "a RADIUS transaction having occurred" - ie a new authentication event has been recorded on to the BTw network, which is part of the handshake process of synchronisation.
The DLM only counts 'forced' retrains and will disregard any resyncs detected as being an Unforced Retrain or one caused by a Wide Area Event.
An unforced retrain is one in which the user switches off or unplugs their modem for "a period of time greater than the minimum period of time" and that a minimum period of time prior to or after a resynchronisation has elapsed without the line automatically attempting, but failing to establish a connection.
/snip/
� Note on Dying Gasp - Whilst DLM may not make use of the dying gasp message, nor is it mandatory for MCT; modem manufactureres are encouraged to implement it's use for Openreach's Test and Diagnostic systems. This allows ISPs to check EUs have performed a power cycle of the modem prior to a potential engineer visit. See SIN 498 Section 3.2.5 R.OAM.4.
Edited by kitz (Fri 20-May-16 20:31:02)
|
|
|
|
|
|
|
Am I right in thinking from your description(s) of the DLM as it relates to FTTC that all Sky, TalkTalk and similar VULA lines are controlled by a BT Wholesale system? Which collects regular data about their NGA connections?
Wow!
I always thought FTTC had its own DLM controlling the line itself, running in the cabinet, that simply fed reconnection data for BTW connections through to the BTW DLM which calculated the IP Profile, and also fed back ISP stability and other requests to the OR one. But given the detail of your obvious research and writeup on your site I have to believe what you say.
Kindness isn't going to cure the world of all its awfulness but it's a good place to begin. Daisy Ridley.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. Sync 59240/14753kbps @ 600m. - BQM
|
|
|
|
I think DLM is a complex beast, and cannot be simply said to be "running in the DSLAM".
I think the statistics collection happens in the DSLAM, but anything grander happens outside, in some centralised Openreach process. I don't think it relates to BTW's DLM in any way either.
Which means the the Openreach process is collecting data for BTW, Sky, TT and any other ISP.
I think the initial connection speed data is included in tags for any VULA CP within the reconnection process, including BTW, but only BTW uses them in creating the well-known IP Profile.
|
|
|
I agree with you totally and think I'll leave it until at least after the weekend before I start messing about again. I think, as long as I do see a speed improvement once I do restart the modem, that I'll leave the HG612 in play too instead of putting the Billlion back on.
Some interesting stats so far, with the "G-Retransmission TX" graph now showing retranmissions being carried out. They're at a much lower level than even before last Nov 20 ... though looking closely at the old parts of the graph, I can see an even earlier step change on Oct 27th. More to look at tomorrow.
I know this will be the quiet period, so it'll be interesting to see what happens overnight and on into tomorrow too.
But ... collection of stats seems to have stalled right now ...
|
|
|
RAMBO/DLM/RAP was originally a BT wholesale thing. Invention and design totally belongs to BT, not Openreach.
However there are now 3 'sub-systems' :- 20CN, 21CN & NGA. The NGA system 'belongs' to Openreach, but NGA RAP function is still maintained by BTw.
NGA (FTTC) has its own RAMBO control box that collects info from the FTTC DSLAM's element managers.
NGA DLM also uses different parameters to control DLM than 20CN & 21CN systems. Parameters being such as the amount of interleaving/FEC or whether it uses different target SNR margins... or banding etc.
When I say same BT DLM system I mean the same system design, just different hardware and parameters for the 3 sub systems. The basic theory on how it works for all 3 systems is the same. NGA RAMBO can pass info to the BTw RAP, in fact it could (and does) pass this info on to the GEA providers if they wanted to implement their own RAP, but none of them choose to do so.
Hope that makes things a bit clearer.
|
|
|
DslStats had crashed and hadn't restarted itself for some reason. IT happens quite often too and I'm not sure why.
Yes looking much better now so I guess we'll see how it goes overnight ans into tomorrow. Does the line look to be performing better than before when it was also on G.INP do you think?
|
|
|
|
I have a task scheduled every minute to restart dslstats
|
|
|
Yes looking much better now so I guess we'll see how it goes overnight ans into tomorrow. Does the line look to be performing better than before when it was also on G.INP do you think?
Yes, it is definitely working better, in a quality sense, than when the 8800NL was running with G.INP. There is a lower FEC count, and a lower level of re-transmissions, which are the rawest indicators. There is also lower ES and LEFTRS counts, which are the "refined" indicators.
The gap in statistics might be hiding something, but otherwise there isn't an obvious difference between the 6pm-11pm "quiet" period and the other times.
At first glance, there wasn't a change in SNRM between 6pm and 11pm, so it is unlikely that a resync at those times would give you any more speed, but who knows...
With the gap yesterday, it is probably still worth trying to grab another 2 full evenings of data before trying anything.
|
|
|
Yeah leaving it for another few days sounds like a good plan. I think I've sorted the issue whereby DslStats was crashing and therefor not uploading - hopefully!!
Is there a possibility my profile has been banded now because of all the errors the line was suffering before? If so, is it likely to be removed if the line stays more stable?
Portable radio arrived yesterday and there seems to be a lot of noise around the receiver unit for my indoor weather station. Do you think it could be causing the remaining errors?
|
|
|
I don't think you are banded. Your speeds seem to change at a resync, and don't hit a ceiling of (a few bytes below) a nice round number. And, as a giveaway, your SNRM seems to be 6dB after each sync.
The issue with DLM is that, when it sees things go wrong, and more errors on the line, it wouldn't /just/ intervene. It would (used to) impose longer delays before it would de-intervene.
See "Why does it take so long for DLM to increase my speeds" here:
https://community.plus.net/t5/Library/FTTC-DLM-What-...
We don't know what applies to your line right now (it took longer to take away FEC+interleaving this second time, but it was quite quick to put G.INP in place), and the rules of DLM could have changed (and likely have) since that Plusnet article was written. But this period of quiet can only help...
Someone else can probably tell you more about the RF question.
|
Pages in this thread: 
Print Thread
WelshWArrior
