Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: boozy on May 25, 2018, 07:41:38 PM
-
I've had a few issues OpenReach visits, and I'm now down to one issue (although I stand to be corrected on that). At approximately 7pm every evening something gifts me serious interference and remains until midnight from when it goes a bit random but interferes until between 7 and 9 in the morning. I've bought myself a cheap and cheerful AM radio and tuned to 612Hz but can't really hear a difference before and after the problems happen. I'm at a bit of a loss on how to proceed (apart from moving house).
I'll not go into the previous OpenReach pains, but the line is now running with a fair amount of retransmission relatively stably (compared to before). I'm not sure if I'm a bit obsessive or should I just leave it alone now that I'm not getting thousands of CRCs and only having problems in the evening.
I've attached the QLN, HLog, the connection Stats FEC graphs (in the next post) before and after 7pm (note that the scale is a bit different)
-
The FEC errors (the record according to DSLStats is 186K per hour).
I've set up a ping, but it won't have enough data yet. Theres a bit of data https://www.thinkbroadband.com/broadband/monitoring/quality/share/1ccc117f5e81a31c70252661b4eb8c96b848c0fc (https://www.thinkbroadband.com/broadband/monitoring/quality/share/1ccc117f5e81a31c70252661b4eb8c96b848c0fc)
Thanks in advance for any help :fingers:
-
Is that it, a few million FEC a day? That's nothing. In fact I think the stats show it's working perfectly with zero uncorrected errors on the downstream!
All the error correction mechanisms are factored into determining what speed your line can manage by your modem. There's not really any point in having all this error correcting FEC and retransmission capabilities for it to never be used. Instead it aims to actually use the FEC and retransmission to give you more bandwidth at an acceptable uncorrected error rate.
Are you having any problems with your actual usage of the Internet connection, or do you think that you have a problem based only on those FEC graphs?
-
Thanks ejs - VOIP is pretty unusable, as you can tell from the packet loss on the ping graph (and important as there is no mobile signal indoors). Ditto for anything real-time (kids have left the Xbox off for a long time) and I shy from working from home as presentations have a habit of glitching out. I didn't know what would be useful information in all the graphs from DslStats, so if you can suggest anything - that would be good.
-
Do you have power line adaptors by any chance? If you do get them in the bin now!
-
No - powerlines are in the bin many years ago. I've turned off the electric to everything apart from the sockets used for the internet (I even went as far as unplugging the beer fridge) and the graph continues in it's peaky way. I am the last house on the electric line (and phone line) so it may be affected by that (or not... I don't know).
-
The Hlog plot is reasonable for a somewhat longish circuit.
The QLN plot . . . there's definitely something going on, it's trying to tell me something, but I can't put a paw upon it. The sinusoidal background, very evident in the DS3 band, is actually present in the DS2 & DS1 bands (if one looks closely and critically). :-\
-
How does one identify a good/bad-looking hlog graph?
-
There are some upstream CRC errors, but I'm not convinced there are enough to account for the described problems.
Perhaps try comparing ping results with different packet sizes:
ping -n 100 pingbox1.thinkbroadband.com
ping -n 100 -l 1400 pingbox1.thinkbroadband.com
If the problem is due to some sort of interference affecting the DSL, I would expect the packet loss to be higher for larger packets.
-
I agree ejs.
Those FEC graphs are nothing compared to my connection, I have a noisy fat line on my graphs somewhere between 3000 & 10000 FECs per minute, and experience no detectable packetloss.
The upstream CRCs are high though, 100s of errored seconds per day is not ideal. It seems pretty strange to me that upstream G.INP hasnt been applied, the cab is huawei right? Downstream G.INP seems to be on.
Whats the rest of the home network look like boozy? Unusable VoIP on a 63/12 connection is crazy... what router are you using? Does it have QoS? If you have xbox aged kids might they not be saturating your uplink with torrent clients constantly running?
-
@johnson - I've probably made the VOIP sound worse than it is. I tend to use the phone for conferencing and have calls of one or two hours in length. When on the calls there will be periods where it goes garbled (usually for the other end of the call i.e. I go garbled), so I sit outside with wifi on the phone turned off. So for me VOIP isn't usable.
The home network has two access points, a Fritzbox upstairs at he east end of the house and an Asus DSL55U downstairs at the west end (that sounds posh - it's just an old long house with solid walls). There are a few Netgear Switches and everything with an ethernet port is wired. Kids had restricted internet access until recently (I did a factory reset on the Fritzbox and haven't put the restrictions back on yet). I don't think they are torrenting, mainly because they don't have anything which won't go to sleep in a few minutes.
It's now much better than it was - the question is, if it normally goes pear shaped at roughly 7pm each evening with a sudden spike of FECs, is that not likely to be REIN (It would likely be present on the QLN as the last reset was overnight). How would I go about finding the source?
Looking at the Ping graph, it mostly behaved last night (I'm not sure I believe the packet loss it's reporting, I mostly see large ping times rather than loss - possibly the timeout is set at 500ms).
I've wandered about with an AM radio on 612Hz and while I can hear noise - I can't correlate it to ping or FEC. I may also have an incorrect assumption that it's one device causing the problem.
-
The FEC rate increasing could be a red herring, 7pm could be when congestion starts to affect your exchange/node/ISP.
-
It's very well behaved this afternoon - no loss and no variance on ping, but TinkBroadband graph doesn't agree?! I'll come back to it this evening.
I realised there has been a resync since the earlier QLN graph - it currently looks noisier, but has the same waves. Would it be worth rebooting when everything seems good, to see if it has a different profile?
-
The pings have now changed for the longer one:
Pinging pingbox1.thinkbroadband.com [80.249.99.164] with 1400 bytes of data:
Reply from 80.249.99.164: bytes=1400 time=22ms TTL=58
Reply from 80.249.99.164: bytes=1400 time=22ms TTL=58
Reply from 80.249.99.164: bytes=1400 time=22ms TTL=58
Reply from 80.249.99.164: bytes=1400 time=345ms TTL=58
Reply from 80.249.99.164: bytes=1400 time=304ms TTL=58
Reply from 80.249.99.164: bytes=1400 time=344ms TTL=58
Reply from 80.249.99.164: bytes=1400 time=23ms TTL=58
Reply from 80.249.99.164: bytes=1400 time=138ms TTL=58
Reply from 80.249.99.164: bytes=1400 time=23ms TTL=58
Reply from 80.249.99.164: bytes=1400 time=22ms TTL=58
no packet loss, but larger variance. Happened a few times in the last run. Default packet size has a max of 30ms.
-
Sometimes it's good to talk - I was just asking one of the neighbours if they have anything on a timer starting at 7pm. They hadn't but they do lose their internet connection and sometimes electricity at 7pm. It's not bothering him overly as it's a business and he has some guard dogs so the security cameras aren't that important, but it is annoying him a bit. Appears it's not just me having issues (although I'm not having it that bad).
I did a 24 hour FEC to SNR per tone graph and it again shows the FECs kicking in at 7pm. The SNR graph is from the end of each FEC period - and there's combing evident after 7pm. It's too big to attach so here's a link to it https://1drv.ms/u/s!AofPcWieuJD2tqdzgvUFkmGuoR5rXg (https://1drv.ms/u/s!AofPcWieuJD2tqdzgvUFkmGuoR5rXg).
I'm guessing he's nearer the source than me, so I will go down there this evening.
-
He loses the mains? Would it be worth getting your own mains supply checked? To see if there is voltage drop, ripple, noise spikes up the mains? Try putting in a UPS then mains filters after it?
-
He was away tonight, but there are weird noises on 657kHz on the radio - pulsing alien noises, need to check when it seems clear of FECs. I might convince him to get an UPS (cheaper option than me doing it;)). Someone was trying to convince me about a device that gives a building a clean 220V and saves about 10% on electricity costs, I may want to have a talk about that (he was Facilities Manager in a shopping centre, so it may not be a consumer device... and I wasn't really paying attention at the time)
Pretty curious to see if he's banded or what his sync rate is, given he is about equidistant to me from the pole. I was banded down to 32.4Mb with a bridge tap until recently. Interestingly the BTW speed test reports the profile you are about to go to the day before it happens, although got it wrong on the day the DLM relented (reported 30Mb and it resynced to 40Mb). The bridge tap only showed up when it was damp, looking like a wet joint (long, painful story - this is just the tail end and more obvious now that there only seems to be one pattern left).
-
Someone was trying to convince me about a device that gives a building a clean 220V and saves about 10% on electricity costs,
I remember those devices being introduced with a great fanfare a couple of years ago. The company which developed them was grossly over-egging the pudding with claims for savings which simply couldn't be verified. It was all based on the assumption that a drop in voltage directly equated with a drop in power consumption. This ignored the effect of switch-mode power supplies on most electronic equipment, and thermostats on things like fridges and freezers. It also ignored human nature, whereby the lower brightness of electric lights would tend to be compensated by using bigger or more lamps.
Sorry, that's off-topic.
-
I'll avoid the power saver ;)
I'm not sure I'm getting anywhere. Of the houses in the row (all 5) 4 have nothing on a timer, one has and it's controlled remotely (ecomony 7 heating or some such - but that won't be kicking in at 7). One has frequent disconnections and has been considering phoning about it, one has no internet, one didn't know much about it (only streams) and another has just had a repair to get up to 40Mb/s from 19 on a 40Mb/s service. They were still having problems but it seems better now... the line is now interleaved (20ms ping) and it seems slower to them than before (It might also be banded to 37.5 from the speed test at 34.5Mbs). If his line is similar to mine, then a large SNR Margin didn't help.
Of the 4 business 2 have nothing on a timer - and the other two had the day off.
The problem is likely further from me - or down at the exchange (the cabinet is across the road from the exchange, although my line takes a 300m detour rather than cross the road (a friendly OR engineer was surprised by the line length and had a look). There's nothing between the businesses and the exchange but fields, so it leaves quite a narrow area, if my timer theory is correct i.e. whatever is causing it is on a timer, given the regularity of it starting.
I think the only things I have found, using the radio, are a French radio station on 621kHz, a Czech? on 639kHz and more strange noises on 657kHz - I recorded a few seconds for posterity :)
I'll maybe see if any of the networks guys in work know anything about QLN, given the earlier thoughts it was dodgy.
-
Taking a step back.
The thing that annoys me is that VOIP is awful. According to the TBB quality ping a reasonable amount of packets are lost. According to the HG612 there’s not much loss. Running pings from my end I’m not seeing much loss (certainly nowhere near TBB), but lots of variance .
So the one thing I can try is a different phone. If it doesn’t work (I’ll try an iThing as at least they’re supported by all providers) then... not sure.
The REIN and interleaving are irritating, but as @ejs said - it shouldn’t matter and likely doesn’t explain the problem with VOIP.
-
Much improved today after accidently pulling out the power lead and getting a few Mb slower sync (and less interleaving). Only one noticeable glitch in 2 hours of calls.
Not sure what to make of the ping from TBB :o
(https://www.thinkbroadband.com/broadband/monitoring/quality/share/thumb/44dee71d6637a1c466d6cf56029ed0f70ae66f76-30-05-2018.png) (https://www.thinkbroadband.com/broadband/monitoring/quality/share/44dee71d6637a1c466d6cf56029ed0f70ae66f76-30-05-2018)
Edit: I've run speed tests and checked the stats - those numbers aren't right (the speed test gives close to max I could get given the profile). Either the problem isn't my end or the Fritzbox has decided it's under a ddos (I can only see 1 setting and it's not to reply to ICMP at all). I'll turn off the monitoring as it wasn't too bad before last night's resync, and turn it back on tomorrow.
-
Just wow. That's a shocking amount of packet loss.
That would need thousands of constant ES for the DSL link to be causing anywhere near that amount of packet loss. FEC's are errors that have been corrected so you can ignore them.
ATM I'm getting 100,000+ FEC/min and I'm not worried about it at all.
What router are you using and have you tried another 1?
-
I'm not seeing that - there have been just over 100 Error Seconds today and 10 CRCs per hour according to DSLStats. I'm seeing a fair bit of improvement :lol:
If I ping TBB:
Ping statistics for 80.249.99.164:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 57ms, Average = 24ms
Confused seems to be the correct description.
-
The Quality stats are now working (the ISP had a trace on too which was causing the modem to not respond) and it's showing clean. I've checked all but one businesses, and nobody has anything on a timer - guess I surrender if there is nothing there.
A lightning shower has just been and gone and it's left me with a question. Why was only downstream affected? That seems wrong to me, but that's what the graphs show! I caught the SNR margin per tone during a bolt, again - only the downstream seems affected. Really curious about the reason.
Although from what my daughter said OR we're working in the cabinet (or possibly the All in One beside it), when the lightning started.
-
I can't give you a definitive answer to your question but I will offer a comment . . .
Looking at the full 4096 sub-carriers of a profile 17a G.993.2 service we see, left to right, the frequency increasing in 4.3125 kHz increments. The bands, left to right, are US0, DS1, US1, DS2, US2, DS3.
In your "SNRMperbandDownstream-2018-06-01-15.54.34" plot we see a upward stepwise change at approximately 1455 hours which was preceded by a downward perturbation. Of the three DS bands, the one most significantly affected is DS3. The DS3 band relates to the highest frequencies of a profile 17a G.993.2 service. :hmm:
In your "snr thunder" image we see that you captured what appears to be some "ringing" in the DS bands and that the xDSL link had dropped.
-
Thanks for that @burakkucat, although I have a particular reason for the question... I've previously had weather related problems on the line where chunks of the SNR graph vanish suddenly. I had thought it was fixed, slightly worried now. If you look at the two following the thunder on reconnect and then the screenshot from Feb (the slightly darker lines are the minimum and maximum) - the jump seems similar. Unsurprisingly in Feb I had multiple line drops per day and error seconds in the thousands. I'm a bit concerned I'm going to have another winter talking to support watching the intermittent problem vanish as I get put through ;D. Sub Zero temperatures were a real problem, which aren't happening now.
You also commented on the QLN graph - when translated into the SNR graph I've seen the SNR per tone move (the sinuous part) by about a quarter of the wave in D3 (and smaller in D2 and 1), if that helps jog your memory. I suspect that may have something to do with it, but no idea what it could be.
-
Ah, yes. It was your circuit that was clearly showing an underlying sinusoid, towards the higher frequencies, in the
Hlog QLN plot. Unfortunately I am unable to think of anything that would cause such an effect.
Hmm . . . I just typed that last sentence when I had a sudden thought. A number of years ago I performed a series of experiments which consisted of harvesting the data and creating the four snapshot plots (Bit Loading, SNR, QLN & Hlog v sub-carrier) from a circuit whose length (between VTU-C and VTU_R) was increased in 100 metre lengths, up to a maximum of 600 metres. I was using two reels of three pair, CW1308 specification, cable of length 100 metres. To achieve any length greater than 200 metres I was using more than one pair in any one cable. For the full 600 metres, all three pairs were in use . . . VTU-C, reel one blue pair, reel two blue pair, reel two orange pair, reel one orange pair, reel one green pair, reel two green pair, VTU-R. As the total circuit length was increased, so was the coupling between the pairs in the cables. A new term, SIXT (self-induced cross-talk), was proposed for the effect seen.
And now that I have typed that paragraph, I realise that the effect was similar to that seen with a bridged-tap and not an underlying sinusoid, as seen with your circuit.
[Edited to correct the punctuation and an incorrect statement.]
-
My maths is shaky after forty years, sounds a bit like a reflection, time-delayed. Is that possible?
See time shift at http://nptel.ac.in/courses/IIT-MADRAS/Principles_Of_Communication/pdf/Lecture05_FTProperties.pdf
It is possible to determine the length of the delay by looking at the period of the sinusoid in the frequency-domain, the spacing in frequency terms between peaks.
Is a bridged tap a source of reflections?
-
Are there any phone line extensions in the property? I’m thinking about any ones that may not have filters on them, in case they might be a source of reflections.
I see what Burakkucat is referring to now, I think. What is the level of quantisation noise / rounding error, is it less than the 1dB level? I appreciate that it is not visible elsewhere. It is quite ‘blocky’ and not so easy to see absolutely clear periodicity, but I can definitely understand what Burakkucat is seeing.
-
There is just one line in with a single filter, one phone and one modem... Extension wiring was removed a long time ago. A bridged tap was removed recently (orange wire, I think - I'll find out if someone thinks it's important) about 80m away, 80m long - an old second line to the house. I suspect my line was Exchange Only at one point but now turns back on itself 3 times before reaching the cabinet - it goes through a number of caverns before it reaches it's destination, so there are more joints than you would normally expect, I think. I'll have a look through the captured graphs, after the bridge tap was removed, and see if any show the sinusoid more clearly.
My Maths degree was 30 years ago and I didn't like Fourier Series then (and up to now I've never found a use for it), willing to have a look but I am totally unfamiliar with the domain i.e. I can do equations, but have no idea about the meaning (or I might have cleared that memory and need a few weeks to redo that module :)).
-
For a bridged tap length calculation (I wrote that code before to figure out my tap - gave 77m, so seems to be good enough):
tones is the number of tones between troughs and dips are the number of troughs across the measurement (2 if you measure two adjacent troughs)
lengths = new double[16,5] { { 100, 231.9, 463.8, 695.7, 927.5},
{ 150, 154.6, 309.2, 463.8, 618.4},
{ 200, 115.9, 231.9, 347.8, 463.8},
{ 250, 92.8, 185.5, 278.3, 371.0},
{ 300, 77.3, 154.6, 231.9, 309.2},
{ 350, 66.3, 132.5, 198.8, 265.0},
{ 400, 58.0, 115.9, 173.9, 231.9},
{ 450, 51.5, 103.1, 154.6, 206.1},
{ 500, 46.4, 92.8, 139.1, 185.5},
{ 550, 42.2, 84.3, 126.5, 168.6},
{ 600, 38.6, 77.3, 115.9, 154.6},
{ 650, 35.7, 71.3, 107.0, 142.7},
{ 700, 33.1, 66.3, 99.4, 132.5},
{ 750, 30.9, 61.8, 92.8, 123.7},
{ 800, 29.0, 58.0, 87.0, 115.9},
{ 850, 27.3, 54.6, 81.8, 109.1}
};
private double TonesToLength(int tones, int dips)
{
if (tones > 850 && dips>2)
{
tones = tones / (dips - 1);
dips = 2;
}
double ret=0.0;
int i = 0;
while (lengths[i, 0] < tones)
{
i++;
}
//assume each is straight
if (i == 0)
ret = 300.0;
else
{
if (dips ==1)
{
ret = 0.0;
}
else
{
dips = dips - 1;
double aboveprev = tones - lengths[i - 1, 0];
double betweenTones = lengths[i , 0] - lengths[i - 1, 0];
ret = lengths[i - 1, dips] + (lengths[i, dips] - lengths[i - 1, dips]) * (aboveprev / betweenTones);
}
}
return ret;
}
being dragged to the shops - but I'll stick in the figures when I'm back and could tell what length a tap would need to be to cause that periodicity.
Edit: kids weren't ready... if it's a bridged tap, it's about 92m long (254 tone period)
-
Sometimes it's good to talk - I was just asking one of the neighbours if they have anything on a timer starting at 7pm. They hadn't but they do lose their internet connection and sometimes electricity at 7pm. It's not bothering him overly as it's a business and he has some guard dogs so the security cameras aren't that important, but it is annoying him a bit.
I'm guessing he's nearer the source than me, so I will go down there this evening.
I had problems with REIN a few years ago, after weeks and weeks interference that only came on when it got dark and off when it got light, A 'OR' engineer found it was a distant neighbours Security cameras power supply units.
There very long phone drop wire was re-radiating the interference all down our lane.
-
If this helps:
Relating to that link I posted to a possible situation here: the reflected signal comes back and interferes with the original, and the superposition gives cancellation or reinforcement in a frequency-dependent way. This is exactly the same thing as the pattern of colours seen on a very thin oil film sheen on a pool of water, because of reflected light from both the top and bottom surfaces of the oil, two light waves combine together with a result depending on the exact thickness of the oil film.
The e-iωt gives the sinusoidal variation with frequency ω, and the time delay t controls the width in frequency-space of the distance between peaks in the frequency-spectrum sinusoidal pattern.
-
Is a bridged tap a source of reflections?
Indeed it is.
What we have to remember is that the original telephony circuit has been cajoled into acting as a radio frequency transmission line (or feeder), operating in differential mode.
-
Which part of the HLog graph in the first post are people getting a bridged tap from? I thought it looked pretty much fine.
-
Which part of the HLog graph in the first post are people getting a bridged tap from?
I'm not. :no:
I thought it looked pretty much fine.
Agreed.
It is the QLN plot that has an underlying sinusoidal background which becomes visible at the higher frequencies. (Reply #6.)
My later post (Reply #26) is probably the source of the confusion.
-
Isn't that shape of the QLN merely indicative of crosstalk from other VDSL2 lines?
-
I'm not sure. :shrug2: Would you be able to convince me, please?
-
kitz mentioned spotting crosstalk from QLN or bitloading:
https://forum.kitz.co.uk/index.php/topic,20906.msg363413.html#msg363413
-
I don't see that there would be a relative time delay between disturbers in crosstalk?
I see which graph Burakkucat was looking at, mea culpa, I was looking at the wrong one and was confused probably just as ejs was. The pattern is very clear there.
-
kitz mentioned spotting crosstalk from QLN or bitloading:
https://forum.kitz.co.uk/index.php/topic,20906.msg363413.html#msg363413
Hmm . . . I remember that post, now that you have pointed me in its direction.
-
Reading it off the right graph now, I make the period about 220 tones. So assuming the speed of light in copper is c, the in-vacuo speed, which it isn’t, but anyway, my calculator says the reflection round trip length would be 316 m, so 158 m length one-way.
Would someone check my arithmetic?
But that needs to be corrected according to whatever the propagation speed really is. Using a velocity factor of 0.67 for copper then that would make the length about 106 m (again one-way length, not round trip). But someone who knows about TDR would know the correct numbers.
-
It's not the arithmetic that needs checking! There's nothing on the HLog graph, and you shouldn't be trying to calculate bridge tap lengths off a QLN graph.
-
I've been reading... would a more accurate term be impedance mismatch rather than bridged tap (this may be totally wrong, as I still don't know much about the domain). Wouldn't that look like the graph (as opposed to crosstalk which would look like the middle of an "m", can't think of another letter with 2 curves meeting in a point).
-
I've been reading... would a more accurate term be impedance mismatch rather than bridged tap (this may be totally wrong, as I still don't know much about the domain). Wouldn't that look like the graph (as opposed to crosstalk which would look like the middle of an "m", can't think of another letter with 2 curves meeting in a point).
I have collected together some example plots for you and have sent you a PM.
-
As for the QLN graph, I was assuming that it was the noise that was being frequency-shaped by this, no?
But you’re right, it’s very mysterious. It’s as if the noise were going through one path and the signal through another, one that is not experiencing this phenomenon, and then they were getting combined later. You make a very good point indeed.
-
I've been reading more (thanks burakkucat). And the thing that sounds most like the problem so far is a split/unbalanced pair (although up until a few weeks ago I had a bridged tap, as well, which may colour my answer). Sadly I've just added the HG612 recently so don't have Hlog or QLN figures from before. I scribbled out a rough picture of my line which has at least 9 sections, and was obviously designed post 4 pm on a Friday afternoon - although I'm not sure I remember the end bit correctly but it does go to two cabinets, one for PCP and one for FTTC. I've read the Broadband boost engineer post... boy, could use one of those - and he would be able to report back a good result, or what.
There is still REIN between 6pm and 8am, but it was at a different time on Saturday (7pm) - so I'll ask who was working late. I was totting up the number of security cameras and a big security lights, and I must say they are a paranoid bunch. Happily none of the lights are on at 6, so I can ignore those.
-
As everyone was having fun with the reflection maths, I'll give something back.
I'm supplimenting my eldest's Computer Science by teaching her a bit of coding, she won't listen about camel case... but I've helped her write some code to calculate Bridged Tap/Reflection lengths. She's being taught VB - but that was a no-no, she's now on a C based language. It will calculate (well, look up) the lengths for multiple or single minima based on the the number of tones between a number of minima or the single tone with the dip.
The source is attached and is based on aJDSU application note, a compiled version is also there for those without Visual Studio/Mono.
I've also noticed my attainable varies by about 1Mb, so I'm going to restrict the maximum sync rate - and theorise the FECs will drop away. We'll see.
-
Thank you for the source code. I'll certainly take a look. :)
. . . I'm going to restrict the maximum sync rate - and theorise the FECs will drop away.
Rhetorical question time: What are FECs?
Answer: CRCs that did not happen.
Hint: Do not worry too much about FECs. They show that the error detection and correction mechanism is working well.
-
Good for you, teaching something like C#, is it? Well C-like, as you said. VB is pretty shocking. Especially in this day and age.
I'm a huge D lover these days. A lot easier and cleaner than C or C++, very high powered. Garbage collected, but you can turn that off if you really read up on how. Compiled to native code by two superb quality compilers GCC for D (called GDC) and LLVM for D (called LDC, like CLANG) plus the reference compiler from Digital Mars, called DMD, the latter always the latest bleeding edge latest language spec version but not a serious quality code generator, fine for testing or for non speed critical stuff.
Like the C versions, GDC and LDC compilers feature superb intelligent integration with inline assembler, many processors. The DMD compiler has a much inferior and incompatible inline assembler system which I would stay a million miles away from, for too many reasons to list. If you wanted to use assembler then you would be using one of the high performance compilers anyway, so it doesn't make any sense.
Someone has done a Visual Studio component/add-in or whatever that gives the IDE support for D.
You can mix it with C, call C from it, call some C++ from it, call D from C too, in fact there is a compiler switch to help you with the latter because it then warns about features that won't work in an entirely C world without some of the core D RTL and perhaps does one or two more things. It's a feature called something like BetterC.
I think it is hugely cleaned up, all the madness of C++ syntax is gone, the worst things about C are sorted out. There is no preprocessor and no header files, instead there are proper modules and everywhere you wanted to use header files, preprocessor directives and so forth, there are specialised clean tailored features to handle each use case properly. Nothing has been missed. Because there are no header files there is no repeated pulling in and compiling of vast amounts of header file text again and again so compilations are lightning fast in a way that C or C++ can only dream in vain about.
Templates and generic programming are amazing. CTFE, compile-time function evaluation transforms your programming sometimes, occasionally removing huge pieces of code because when it can whole function calls are entirely done at compile-time whenever they possibly logically can be, without limits just because of syntactic restrictions or lack of intelligence on the part of the compiler. I recently had a readonly table with 64k entries that needed complex calculations for each entry. The whole lot was set up by a long involved initialisation routine, but all of that code vanished because it all got done entirely at compile-time and the end result was simply included as readonly preinitialised data.
Here’s me going on and on. Love-struck. Apologies for being so off-topic!
You might be interested anyway. Could be fun.
-
@Burakkucat, I was interested in the other FEC definition - that it’s a bitswap there was no room for (I’ve made that up but that’s how what I’ve read has ended up in my head). I’ve seen the REIN pattern and am curious if bitswapping would manage it.
@Weaver, I need to work on her hard-coding and explain that when I say “exactly the same” it means create a function not copy and paste... but considering she hadn’t seen a while loop in school, it wasn’t a bad effort. As for D, I’ll give it a look. I cut my teeth in C and C++, so like a language that allows the shooting of both feet at the same time. I’ve hated Eclipse since the Sun Netscape alliance days (I’ve literally got the tshirt).
-
@boozy well done anyway you are at least teaching her what a while loop is.
You can write C almost 100% in D, the only frequently encountered differences are the missing preprocessor, which I do not miss at all, am very glad it is gone, and the syntax of casts is different, easier to read. Otherwise most of the time it is the same. One other thing is that you do not use zero terminated strings, performance killers always having to scan to the end, or forgetting the zero entirely. Strings are a proper part of the language with a length field. They can be bytes (UTF8), or words (UTF16) or ulongs (UTF32). I always use the latter unless I just want pure ascii, or general random non-text bytes of course. Strings and arrays can be fixed length like C or variable length optionally.
You might find it fun. I would start by reading the "for C programmers" page on the D language (google "dlang" because you can't get google to understand just the letter D) website. Absolutely all of the users are hardcore C or C++ serious programmers and they all know that they want sane conversion from C. A number of users in the very active forum have contributed to the fast evolving design of the language and especially its huge run time libraries, written entirely in D with possible bits of asm or the use of compiler magic directives.
Could be interesting reading anyway.
-
Failed FEC Experiment - the DLM intervened as well, so there's more than 1 thing changing. FECs did halve, or more, but I didn't see what I expected on bitswapping.
Bearer 0
INP: 57.00 0.00
INPRein: 1.00 0.00
delay: 0 0
Bearer 1
INP: 4.50 0.00
INPRein: 4.50 0.00
delay: 3 0
became
Bearer 0
INP 55.00 0.00
INPRein 1.00 0.00
Delay 0 0
Bearer 1
INP 2.00 0.00
INPRein 2.00 0.00
Delay 0 0
Although I'm afraid I have another question. Can anyone theorise a reason for the difference in the noise disturbance in the 2 QLN graphs (without involving a few feet of copper wire)?
-
I'm feeling pleased with myself and thanks @burakkucat and @Weaver (and I've had a play with D). I took the information from burakkucat and worked out what two things together could cause the QLN graph to be like it is, and decided that I must be on a split pair with someone else who has a Bridged Tap. I've been politely harassing the neighbours, who are quite helpful when I tell them it may help their internet - It turns out that I've found a likely culprit... I'll be back down there tomorrow to fix it, if it's internal wiring. If not, OR can do it and the split pair.
I've attached the HLog and bitloading - and make the Bridged Tap 25.5m. with 2 times that and the distance to the pole would be ~100m which matches up to Weavers calc. Although I'm not sure that's how it works, as I'm thinking about expansion chambers and standing waves. It could be interesting if there's another tap of 100m. However I'll find that out when this one is fixed and my QLN remains sinusoidal or straightens - their internet will improve regardless.
-
That Hlog plot (HLog-2018-06-12-18.44.46.png) definitely shows a bridge tap. I won't attempt to estimate its length just by viewing the image . . .
I remember one case of a bridge tap which was measured to be exactly the distance to the aerial DP. Eventually an Openreach technician climbed the pole, checked the connections and discovered that both pairs of the aerial drop cable had been connected in parallel at the DP. ::)
-
I'd probably be remiss if I didn't post the other hlog and qln I've got to see if there's any comments.
And I used the program I helped daughter to write (and have double checked against the graph in the document), so I'd be willing to bet on it - given plus or minus a meter :). I've fixed the bits that annoyed me too :-[, I couldn't leave it alone.
-
Answer to something the OP brought up a while back, hope this is helpful and sincere apologies if you knew every bit of this already.
When you shift a signal in time by delaying it, then if you take the (continuous) Fourier transform of the delayed thing then you get a function that is a sinusoidal wave pattern in frequency space. (Look up Fourier transform time shift.) Here the idea is that there is a reflection from something in the cable which has an associated time delay and then this results in the sine wave. The ‘why’ of it can be understood by doing the maths, but also by simply thinking about what is happening. The time delay will have a different effect on the end result which depends on frequency because the reflected wave comes back and mixes with the original signal. Differing frequencies mean that a certain time delay counts as a differing phase shift depending on how many whole cycles at frequency f fit into the delay time. Varying phase difference means reinforcement or cancellation and all points in between when the reflection and original signal mix, and there you have it. Think of older televisions when some fellow in the tv studio is unwise enough to wear a stripy tie or shirt, and what happens if the stripes have a short wavelength. Then there is horrible trouble with ugly spatial interference patterns visible through the camera. This same pattern is seen in different situations again and again.
-
Found the tap! The extra line "rung the bell in the shed, but we've taken the bell away". They can phone and see if they can convince support to send an engineer (it shows no Bridged Tap in the availability checker and a handback of 30).
In the meantime, I've had some fluctuations on my SNR that I'm not sure what to make of... I also ran a quiet line test, which has never had noise before (or I think it hasn't). If I bring the phone close when on speaker there's definitely noise. However, I have cookie bite hearing loss so have no idea of the volume. If the noise is in a range I can hear: It's fairly quiet. If not, it could be anything :-[.
@Weaver, physics homework last night was longitudinal and transverse waves - so it came in useful :) although with a very frustrated child (and parent.
-
Really confused now. There was a little shower and the SNR dropped again (there was one earlier too, but only for a few minutes). I decided to force a resync to see what the QLN was like... The SNR returned to normal. That would imply that my line was contributing to the noise levels, but I can't see how that would work. Assuming I have a split pair is this possible, or is there something else?
-
@boozy is that GCSE or A-level Physics? Must be nice to have that time with your child though.
-
Really confused now.
Hmm . . .
There was a little shower and the SNR dropped again (there was one earlier too, but only for a few minutes). I decided to force a resync to see what the QLN was like... The SNR returned to normal.
The SNRM returned to the default margin. Yes, that is expected. When the assumed noise ceases your SNRM will rise by the same amount by which it was depressed when the assumed noise started.
That would imply that my line was contributing to the noise levels, but I can't see how that would work.
No. :no: That is incorrect logic.
-
@weaver. Lol - Nat 5 (Scottish invention, I'm more of an O or A level person). She'd missed 6 weeks of school this year (and this topic), so leaving the homework to the night before was not a good plan. Homework with children is overrated - I ended up dictating the last few answers as it was way past bedtime. When both parents are calming a child, it's too late at night.
@burakkucat: I was expecting the return to normal when the noise stopped. I'm dubious that the noise stopped while I forced the resync as I've seen the pattern before, far too many times, with lots of CRCs for hours then it loses sync - when it comes back at the same speed CRCs are gone. This is the first time I've forced the sync.
-
No. :no: That is incorrect logic.
Yep, the logic was incorrect - but I'm trying to answer a question I have (domain knowledge is the problem). I can see the pattern I want to query, but am having difficulties putting the correct question.
I'm also putting in old information from before I had the bridged tap removed, and before I had stats from the HG612. I'll try again and see if I can word what I'm trying to find out.
1. When rain happens (and especially noticeable when it's snow) my normal SNR drops as if there is crosstalk, using the gif you gave to identify the closesest approximation of the effect, this causes CRCs/resyncs or did before I set an upper limit on the attainable. Worst connection I've seen was about 22Mb/s : first attachment (minimum line in the graph)
2. If my line resyncs a few minutes after the starting event the speed/snr are as before and no more errors occur. The picture yesterday
3. If the line recovers on it's own, it's a gradual process over the course of 30 - 40 minutes (unlike crosstalk) : Second attachment
4. It looks like I have a split pair with someone who has a bridged tap causing some noise on my line (found, but I haven't asked them to do anything yet). This could be anything - the pairs could potentially lie beside each other for a long distance.
I can't put points 2 and 3 together (that's causing me confusion :D), as they seem to contradict each other. Point 4 is the left field item - that's got to be so rare to make it unlikely many people will have seen it, and the effects wouldn't be well known.
So that's it - I can't think how both 2 and 3 can be true at the same time.
Attainable has varied by ~6Mb during the last 24 hours, but sync would've been maintained if I hadn't have got nosey.
-
It's been dry for a month, except for one thunderstorm, but that's over now ;D.
A proper Scottish shower (about 2 inches in as many minutes and then ordinary persistent rain):
Connection speed dropped by ~10Mb (I would have said banded, but the attainable is the same as actual just now), guess I'm not clear of the weather problems :(, someone else's bridged tap can wait.
-
4. It looks like I have a split pair with someone who has a bridged tap causing some noise on my line (found, but I haven't asked them to do anything yet). This could be anything - the pairs could potentially lie beside each other for a long distance.
Rare to have a split pair.
Chances of having a split pair and that being shared with another user are extremely slim.
How you think you're detecting a bridged tap on a neighbouring line I have no idea.
You should sell that to OpenReach.
-
@j0hn. I do have a daughter who specialises in vanishingly small... she could find a bone in calamari :) - although I'd prefer her not to have managed to hit some of the other 100 million to one things she has.
Willing, eager, for a different explanation ;D. QLN shows a refected noise of length 101 +/- 5m (Weaver gets 106, I get 96). Makes sense all 8 drop wires are between about 80 and 120m. There were 6 premises when BT buried the cable, so I doubt we have lots of spare capacity now that there's 8. Hlog is fine, so the reflections aren't on my line. From the notes Burakkucat gave me, nothing matched to all the symptoms... so I combined them together in pairs. Only split pair & bridged tap matched - although, I think it more likely that my pair lies against the other and isn't well twisted.
After that I just stuck the hg612 on the other lines to see if there was a bridged tap. Finding an ADSL2+ line with <17Mb was also a surprise as well, given that it's 1050m to the exchange (even with the insane routing) according to BT. Mine was >19.
So if you can think of something, I'm all ears :D. I'm just applying Occam's razor, and while I may not totally agree with the likelyhood - it does fit.
-
There are Hlog and Bit Loading plots attached to reply #53 (dated 12 June). The Hlog plot definitely shows a bridge tap, whose length can be estimated with a fair degree of precision by manipulating the raw data.
I presume that a suitable CPE was taken to the relevant neighbours home and the data was harvested. :-\
-
So while playing with Occam's Razor - the current fewest assumptions don't fit anymore. Here's how QLN changed during the rain. Attainable or SNRM have not yet recovered as they've done previously... there was a lot of rain in a very short time - although the noise reflection is dimmed too.
@burakkucat - while that's true, given the effect of rain, the combination doesn't hold true (on it's own). Given I've had a bridge tap removed, I feel I should be calling bingo ::).
-
The SNRM returned to the default margin. Yes, that is expected. When the assumed noise ceases your SNRM will rise by the same amount by which it was depressed when the assumed noise started.
The speed return to the one I'd set as the maximum attainable, so I expected a lower SNRM - not the same as it was before the rain. Doesn't make less sense than anything else that's going on :).
I'm surrendering and putting the details on Zen's forum - even a bit of rain that barely wet the ground was noticeable on the margin (only about 0.5Db though).
-
I have now "wandered around" with the aid of Google Street View and have found the relevant "cavern" covers. The telephone exchange was unmissable. Quite clearly the lines in question were direct exchange lines. I will agree with your description of "mad wiring".
Performing a "look-up" on the telephone numbers you have shared with me shows, interestingly, two different cabinet numbers.
-
I must have miss typed - tried again. Street view seems old, but the unseen caverns are pretty much where the dog walker is at the exchange on opposite sides of the "road" (scarily there appears a worn path towards my line cavern on it's first pass past the exchange). Reckon the electric goes up there too.
-
Going to ask a really silly question - what would happen if one of these (or similar) hit some cables:
https://www.farmtechsupplies.com/product/flail-hedge-cutter-am60-60cm-wide/
there appears to be a patch or covering on the cables on the pole about hedge cutter height - I'll need to remove some hawthorn to have a look. But that would be a much simpler explanation, if some sheaths had been stripped away...
-
Well I have seen the end result when the top of a road sign "got in the way". Not a pretty sight. ::)
-
I noticed that the pole wasn't vertical any more, water crossing the wires/close proximity of bared wires would seem to match all the symptoms... you should see what happens to your drive when it's angled towards it, I have bicycle tyres on my amazon favourites (not that they are often used). I've asked the previous person who did it what type of cutter it was, betting cheap and unprotected. I stopped short of asking did he hit the pole and then twist some bare wires together :-X.
-
My view is, of course, historic from 2011 but, back then, the only cable climbing (or descending) a pole was on the middle one of the three. From that pole aerial cables run both ways to the first and third poles. The cable up pole two was protected (and I assume it still is so) with the usual capping which ends just below the hedge top!
You may well be onto something . . . :)
-
The hedge is currently a bit higher, and there's something spiral wrapped around the cable towards the exchange, about a foot higher than the capping which is hanging off - Callum (2nd Engineer) lost the nail, and the one I gave him is missing. The hedge is now a few feet higher again, only around the pole - I may need to get the loppers out. Or I could just go mad with the hedge cutters and ensure a visit :D
-
Quite hard too see - but there's about 6-8 inches of something round the cable in the lower half of the picture.
I also went and found a water pistol, but the rain was about to start (there were a few spots), so I just ended up standing in the road with it :-[.
[attachment deleted by admin]
-
Just the exact spot question now, but it's above ground given how quick it appears :)
You can just about see when I was referring to spots of rain - and definitely see where there's now a little rain.
-
Quite hard too see - but there's about 6-8 inches of something round the cable in the lower half of the picture.
I can see it but I am puzzled as to what it night be. ???
It doesn't look like a joint closure . . . at best I will say that it looks like half a joint closure! Then there is the problem of deciding how many cables there are . . . is it two or three? :-\
Certainly some attention and maintenance is required at that location.
-
Here's a better picture - after some loppers were applied. There's two wires.
The rain isn't really going, but you can see it going on an off... especially upstream.
-
Yes, two cables. I am still uncertain as to what is that object on the left-hand cable. Perhaps Black Sheep will be able to identify it?
Looking critically at the wood of the pole, could those nicks be from a hedge trimming flail? :-\
Perhaps the damaged cable just needs to be replaced and a second length of capping be fitted to provide further cable protection, higher up the pole (for when Angus is next trimming the hedge)?
-
I have to say, I don't recognise that particular closure ??? It may be a closure specific to 'Aerial Cables' as the picture appears to show this kind of cable ??
The only other item it possibly resembles, is something we fit around drop-wires going through trees ... a kind of wrap-around device rather like a 'cable-tidy' you might have at the back of the TV, where all the wires go to die. :)
-
If it happened a while ago you've likely got the first letter of the name right, but right when you thought it was safe to go back in the water... the rain started a bit more heavily and this happened ???
I'm away for a few days, but I'll check the pole for damage when I'm back.
From Black Sheep's reply it sounds like protection (at best) - but fitting to only one of the drop wires? Sounds like an "after the fact" or farmer fitted.
-
I tried the water pistol - unfortunately it's no smoking gun ;D. Although there's a limit to where got wet given the angle and the fact that I'm below the bandage and the clouds are above (I did try and mimic rain too).
However something is different - when I came back in to check the CRCs and ES had increased last night on the downstream upstream and is still increasing. I tried removing the modem for 30 minutes but that hasn't helped... I think I'm going to get around 50% errored seconds between 7 and 8. After removing the modem interleaving has increased to 16 downstream (which seemed less affected) - so I guess VOIP is kaput again. Guessing this won't end well.
Not sure what to look at as everything else looks like it usually does,
-
The interleaving depth is almost irrelevant with G.INP - it's an absolutely tiny value, even 16, it's just the DTU size. I think the DLM only has two levels of retransmission (G.INP), high and low, if Bearer 0 still has INPRein of 1, then it's the retransmission high level, and any slight changes in the INP level or DTU size (interleaving depth) do not indicate that the DLM has changed something - they tend to change slightly on each resync.
-
Those several thousand upstream errored seconds should be enough to cause DLM intervention, so its quite possible things will now improve, i.e. upstream G.INP, though it unfortunately goes away fairly quickly for most people.
-
Those several thousand upstream errored seconds should be enough to cause DLM intervention, so its quite possible things will now improve, i.e. upstream G.INP, though it unfortunately goes away fairly quickly for most people.
Yep - both up and downstream are now on retransmission low, from the ejs description.
I did turn off everything and do a quiet line test, not sure why given I have cookie bite hearing loss :), but I could hear noise on the line. A short "tock" about once every 75 seconds on average and a really faint modem-like noise (but I had the gigaset on speakerphone and to my ear to hear that, so could have been the phone).
I think the easiest thing to do is find out where the water is ingressing. Would a garden water sprayer reach 20 feet? The few hundred ml in the water pistol ain't enough (nor is the 6 feet range).
@burakkucat - that might well be damage in the picture, but I can see something further up too. Without getting a ladder and clearing away undergrowth and hedge it's hard to be sure.
Zen will raise a fault, but are concerned nothing will show up on the day - so I'm trying to remember who provided the BT hospitality at Knockhill about 12 years ago, in case I need to shout at someone :), bet he's ended up on the BT side of the split though. Anyone with an indication of how the fault could be identified on the standard OR tests?
Nothing I can do for now - Jury Duty starts Monday.
-
I am now the proud owner of one of these : https://www.amazon.co.uk/Nerf-E0022EU4-Soaker-Soakzooka-Action/dp/B075Z3FBWC and still none the wiser as to where I need to add water to show the fault. Although I cannot get to the top of the pole (must be a wuss).
Just to please me - the DLM relented and removed, however temporarily, the G.IMP upstream... that shouldn't last long. I rebooted everything between 5 and 6, but that just lost 3Mb/s speed and didn't change the error rate. I went to the office today, so suffered little of it (kids had no such luck on the first day of the holidays ;)).
QLN looks pretty bad on the downstream, but it's been OK with only a few errors - despite what he SNRM has been doing.
I'm just going to wait for rain - and help the neighbour get PlusNet to fix their bridged tap (as I'm curious about my QLN when that happens).
-
I am now the proud owner of one of these : https://www.amazon.co.uk/Nerf-E0022EU4-Soaker-Soakzooka-Action/dp/B075Z3FBWC and still none the wiser as to where I need to add water to show the fault. Although I cannot get to the top of the pole (must be a wuss).
Ha! :D
QLN looks pretty bad on the downstream, but it's been OK with only a few errors - despite what he SNRM has been doing.
The "flying gulls" (or "pigeons") in the QLN plot are good indicators of cross-talk. There certainly is something happening . . . the SNRM and Error Second plots are clear proof.
-
The "flying gulls" (or "pigeons") in the QLN plot are good indicators of cross-talk.
Well spotted, I hadn't noticed that - the shape of the sinusoid has now changed to have the "m" centre as opposed to the curved one before. I really need to remove the neighbours modem and force a resync on my line to satisfy my curiosity, if nothing else.
-
Still waiting for rain - a first for Scotland.
Is there a maximum possible number of FECs? and did I reach it :D... I was getting CRCs too, but not as many as you'd think.
Still trying to figure out the hybrid response from broadcom's diagnostic tool. If I look at the two different sets of peaks and troughs and calculate the lengths from that - it comes out at ~800m and ~100m... that's roughly my line length and where I think the fault is. Pure speculation though, as it could be measuring anything. Would love the manual for it ;D
-
Is there a maximum possible number of FECs? and did I reach it :D...
If the FEC count is stored as a 32-bit signed value the maximum is 231 = 2,147,483,648. If it is stored as a 32-bit unsigned value the maximum is 232 = 4,294,967,296.
-
I should have asked that better :). Is there a physical limit i.e.
60000000 (mb/s) / 1492 (packet size) * 60 (seconds) = ~2.4 million per minute
-
Ah, I see. I'm not aware of any limit . . . but, thinking about it, there must be an upper-bound. :-\
-
In one of my regular tries with the water pistol I managed to get around the top of the pole wet :). Not much, but it did drop the SNRM like it has previously for light rain. Looks like I found the location, and it isn't the strange wrapping round the cable. I think I'll wait for some rain before reporting this as my hit rate is well under 1% (the wheat in the field is much healthier around my target :D), I don't think I could wet it on demand.
-
After a long while waiting on forecastable rain. OpenReach are coming on Friday morning. They’ll either think I’m a genius, eejit or nutcase (especially if I hand them a water pistol). Most likely a combination of those three.
-
@ boozy Hope it goes well for you! If they can't make up their minds what
it is you are, you could always arrange a poll here! Not really,mate! ;D
-
Not sure either me or the engineer were happy at the end of that. I'm now the proud owner of a module, previously 92m away at the DP. The line down the pole was also given a good check over. But just as he was about to go the rain started - a my heavily amplified phone was picking up noise, his wasn't. He reran everything and stayed on the phone running the Quiet Line Test for a bit (actually quite a while, I think the water pistol and the amount of printouts intrigued him... you can read that as tending towards nutcase in the poll :)). He reckoned if he could pick it up he could find it, but no joy.
Learnt more about the line too - first 92m are .9mm copper, down the pole is 0.5mm copper (this is likely to be the source of the wavy SNR and the reflections shown in the hybrid response test). The unidentified enclosure is for use in trees as Black Sheep surmised (as is the .9mm cable) Underground cable is 20 pair, he tried to look up the line on "Magic Map"? but it wasn't on it.
I've attached the post and pre HLogs, I can see both good and bad. I'm not sure what to think :)
-
I'm now the proud owner of a module, previously 92m away at the DP.
If I am understanding correctly, your circuit now has a new connection module within the DP.
Learnt more about the line too - first 92m are .9mm copper, down the pole is 0.5mm copper (this is likely to be the source of the wavy SNR and the reflections shown in the hybrid response test). The unidentified enclosure is for use in trees as Black Sheep surmised (as is the .9mm cable) Underground cable is 20 pair, he tried to look up the line on "Magic Map"? but it wasn't on it.
It's interesting to read of the circuit's local "make up" . . . and it's not the first time that the network records have been shown to be incomplete.
I've attached the post and pre HLogs, I can see both good and bad. I'm not sure what to think :)
There is a slight "lift" in the total plot (i.e. it moves in a positive direction) between the pre- and post-plots. That's a good. Possibly the highest frequencies in the DS3 band show a slight improvement, so that's a second good. However the US2 band seems to be slightly more degraded. So that's a bad. Hmm . . . :hmm:
-
boozy: what is your current hybrid response test?
-
I haven't had the heart to try it today yet - it looks like rain, and with my luck I'll miss capturing it if I do. The bit loading looks the same, so I expect little different given the change in wire gauge at 92m.
-
Is this still the actual problem?
Thanks ejs - VOIP is pretty unusable, as you can tell from the packet loss on the ping graph (and important as there is no mobile signal indoors). Ditto for anything real-time (kids have left the Xbox off for a long time) and I shy from working from home as presentations have a habit of glitching out. I didn't know what would be useful information in all the graphs from DslStats, so if you can suggest anything - that would be good.
Have you considered the possibility that there's nothing much wrong with the physical wires, and there's no significant problem at the DSL layer, and the performance issues are elsewhere such as congestion at the ISP or their wholesale network? If you look hard enough, you're bound to find imperfections with some part of the line somewhere, but they may be completely irrelevant to the actual problem.
-
Is this still the actual problem?
Not so much
Have you considered the possibility that there's nothing much wrong with the physical wires, and there's no significant problem at the DSL layer, and the performance issues are elsewhere such as congestion at the ISP or their wholesale network? If you look hard enough, you're bound to find imperfections with some part of the line somewhere, but they may be completely irrelevant to the actual problem.
Yes, but I have reasonable cause to believe there's a physical problem.
-
:no: rain last night, sync dropped, but it got me thinking. I’ve looked over all the previous sync losses or SNRM drops due to rain and it struck me that shorting to a capacitor (with different discharge rates) would look like that, and explain why the effect stops later even if the rain continues. I don’t suppose there is a capacitor or similar in the circuit?
The QLN also showed a significant positive jump during the resync. It would look good if the previous hadn't been seen :D.
Edit: semi rhetorical question, what would it look like if rain allowed another conductor to become part of the circuit temporarily? An open or a bridged tap... or the above.
Further edit: I'm at a loss, the only things I learned was that the QLN was about 5-10 db higher than normal at that point in the negotiation process and that the SNRM was at 5.9 at the point of Synch although this had increased to 7.9 within a minute. I was hoping the HLog would show something like a tap, but it doesn't :(. Given the whole thing lasted 3-4 minutes (and the rain kept going) I not sure how the fault can be tracked back - quite often the SNRM drops by 2 or so and stays that way for a few hours, but it still seems a small window to fault find. I'm thinking of following Ixel's lead and provisioning a new line.
-
OpenReach came today after an escalation, the rain didn't as the forecast changed over the weekend.
My line is now a very different one to yesterday. A split pair was found and fixed (about 7m worth of split with an unused pair) and the pair back to the DSLAM after that was swapped out (with a noisier pair :)). As before I can see both good and bad in the stats and I am still not sure if it's "better" - I'll wait for the rain which is forecast for Wednesday morning and see if it all hangs together.
On a side note - I almost reached 1ES/Sec (which did get a smile out of the engineer ;D).
-
There was a nice short shower earlier and for once synch wasn't lost, and even better I saw it coming and managed to grab an extra few snapshots. The pre-rain snapshot is at 5:31 (was just starting) and one a few minutes later when errors were starting to appear (I also grabbed a SNRperTone in between and it was in between the two i.e. not as bad as the 5:35). This ties in with what I'd seen before with the QLN being significantly higher after the rain, if a resynch happened i.e. the average noise had increased.
Has anyone any idea what could cause this effect?
It sort of looks like crosstalk that lasts for a short period - is there a way another line could cause this? In the past I've lost synch with a margin of 16 :D