![]() ![]() ![]() ![]() |
|
That hum will be doing wonders!
hio77:
That's a battery contact hum...
weird that it wasn't noted when i called on friday night!
Are all battery contact detectable on your end or only severe ones?
Yes apologies, I can hear it (I know what I'm listening for), she can't (if its not overpowering then there is no noise at all)
To be fair it is faint in the background and with a tone and/or voice over the top its easily missed.
jurgensp99:
hio77:
That's a battery contact hum...
weird that it wasn't noted when i called on friday night!
Are all battery contact detectable on your end or only severe ones?
Yes, I can hear it (I know what I'm listening for), she can't (if its not overpowering then there is no noise at all)
To be fair it is faint in the background and with a tone and/or voice over the top its easily missed.
That would explain it.
none the less, that's absolutely the fault.
It gets into testable vs user experience. the fact that as a user you experience the sound leaves very little discusion around a detectable fault.
The world of copper is a pain in the ass since it's kinda a whole lot of maybe it's an issue maybe it's fine...
I'm used to battery humms being actually very overpowering, thus the expectation that it's audatable if it's actually testing as there..
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
Just so I know, ideally there is no sound on the line at all?
Speaking of ideal should the adsl snr be closer to 6? is it achievable on a 2.5km line? I'm not sure I've ever seem it that low which means there has always been a fault/faults on the line. I'm guessing one can fit many faults on such a long line, where do they start looking?
So many questions
RE detection I was just thinking it would make life a lot easier if the fault were detectable ie the tech keeps fixing until no fault detected which in turn means all is actually fixed.
jurgensp99:
Just so I know, ideally there is no sound on the line at all?
Speaking of ideal should the adsl snr be closer to 6? is it achievable on a 2.5km line? I'm not sure I've ever seem it that low which means there has always been a fault/faults on the line. I'm guessing one can fit many faults on such a long line, where do they start looking?
So many questions
RE detection I was just thinking it would make life a lot easier if the fault were detectable ie the tech keeps fixing until no fault detected which in turn means all is actually fixed.
ideally, you should have a dialtone, and a near crystal clear line.
Often copper isn't ideal, also often people put up with more than they should in terms on noise on the line because they just assume it to be normal :)
your training margin is currently 12dB, as such i'd expect the modem to sync at 12dB (which it has, there has been slight movement due to changing noise but that's to be expected)
Your right on where do they start looking.
Often their process is simple, they go out, they try to find a fault soon as somethings found... does it look good? ok lets go.
the next time the tech came out, he noted the fault must be underground. a different tech came and repaired the 100pair cable along the street.
It's totally possible there are multiple faults along the cable, or that you have a pair that has slowly degraded beyond use!
I'm cautious of pressing the DSL fault, as that will be resolved with the PSTN fault coming right. It's easy to sign off a fault as "working as intended" until it's made clear no actually there is a testable fault.
Is also a reason I'm not really a fan of naked lines. More points i can test with - in saying that, Rural lines are often on PCM cabinets which are untestable (reasonably common with lines out our way...)
Fibre gets easier, they can test the fibre and find the break in most cases very automatically.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
Line is looking good from my end here, it had me worried when the tech first signed it off as it was dropping a few times but that may have been nothing.
Stable since, testing is looking ever so clean. ddDLM should be happy to make movements now, It's the waiting game...
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
hio77:
Line is looking good from my end here, it had me worried when the tech first signed it off as it was dropping a few times but that may have been nothing.
Stable since, testing is looking ever so clean. ddDLM should be happy to make movements now, It's the waiting game...
I notice the line acting strange also.
Lets wait and see what happens. The tech went down the line and re-crimped all the joins up to the pit. I suppose short of putting a new line in there is nothing else to do.
Regarding lines it was interesting to find out that in the pit the 100 pair steps down to a 25 pair and all 25 pairs along my road are currently allocated so no redundancy here should a pair fail.
Went away for a couple of days last week. Upon return ran a speedtest to find I have my 1.5Mb/s back.
Checked the SN and its down to 6.3
tbh I had conceded to having lost the bandwidth and am happy its back. Its still not allot but all we have.
Would be nice to decrease latency but if it stays around 25ms its ok.
Thanks for all the help to the GZ experts.
jurgensp99:
Went away for a couple of days last week. Upon return ran a speedtest to find I have my 1.5Mb/s back.
Checked the SN and its down to 6.3
tbh I had conceded to having lost the bandwidth and am happy its back. Its still not allot but all we have.
Would be nice to decrease latency but if it stays around 25ms its ok.
Thanks for all the help to the GZ experts.
Great news, I was watching your connection for awhile it took ages to actually drop back (one of my personal connections took about 4 months to drop back so not nearly as bad!)
Glad to know it's finally down to normal.
We can request interleavings to be turned off which will drop you down about 14-16ms, There are hidden little changes that come here though that's worth considering. things like slight packet loss from errors that would otherwise be corrected, this can wreck tcp/ip traffic at distance.
on a clean line generally it isn't noticeable.
There is a possibility when they switch you to FF it will jump back to 12db and retrain down again FYI.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
|
![]() ![]() ![]() ![]() |