Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: waltergmw on February 25, 2009, 02:15:19 PM
-
Can anyone offer any hints for getting around the " unsupported firmware version " problem illustrated below.
I.e. is there a work-around or special version of DMT that will "see" a Thompson rather than a Speedtouch ?
(I'm accessing the PC remotely using logmeon.com on an Apple Mac.)
Kind regards,
Walter
[attachment deleted by admin]
-
Yes - as long as its a correct chipset you can over-ride the DMT firware limitations.
To do so, the router must not be connected to DMT when you change it.
The setting is found under
Special >
Misc. Options >
Then in the "Firmware Specific" box >
Tick "allow untested firmware versions"
-
Thanks very much Kitz.
I was hoping to do it remotely but that's obviously not possible.
K R
Walter
-
You may be able to.
Open DMT on the remote machine - and then just make sure you change the setting before hitting the DMT connect button.
-
You're a genius Kitz - but then you knew that already !
Here's the result and I'm still in my dressing gown !
[attachment deleted by admin]
[attachment deleted by admin]
-
Is that by any chance that troublesome line that you have?
Bit loading looks fine nothing much that I can see wrong there... a couple of unused bins but thats quite common on a line that long when you get to it higher end frequencies... its actually looking very healthy.
It looks like the target SNR is set at 15dB - but difficult to say for certain since its been up a couple of days... but if so a sync speed of 2624 is very good indeed and the physical line is looking ok.
Without the high target SNR that line would be very good for its length... so whats causing the high target SNR?
I think you need to continue to monitor and graph the SNR Margin.... from what DMT has shown so far nothing I can see wrong with bit allocation at all... it is a bit low.. but again that will be due to the high target SNR.
-
Thanks Kitz,
There seems to be the occasional noise spike which I suspect is causing the problem. Here's a small one.
I also note a small night drop of about 1 dB but that shouldn't be too much of a problem.
Kind regards,
Walter
[attachment deleted by admin]
-
yep - the 1dB nightly drop is perfectly normal.
That slight noise spike at 8.45 - heating lighting etc switched on/off.
Even so most lines should be able to stand that - and that particular spike is still within acceptable parameters... would take something a bit more than that to knock out that line.
From what Ive seen so far I still suspect random periodic noise burst which is whats causing it. Its a case of 'catching it in action'.
-------
btw something that occurred to me - if youre monitoring that line remotely on DMT - turn off some of the sound settings in DMTtool - or else your client at the other end will be hearing periodic ping and ding noises and may wonder what they are. :D
-
Hi Kitz,
Thanks once again and even though my Laptop is in the spare attic bedroom, I've muted the speaker.
The general picture is one of very good stability, although there have been 3 single spikes down to about 11 dB during today.
This morning there were a few DMT reports of bit swopping.
Here's a typical start-up events data:-
Info 00:00:46 (since last boot) xDSL linestate up (ITU-T G.992.1; downstream: 2720 kbit/s, upstream: 448 kbit/s; output Power Down: 18.0 dBm, Up: 12.5 dBm; line Attenuation Down: 55.0 dB, Up: 31.0 dB; snr Margin Down: 14.0 dB, Up: 16.0 dB)
There's been no sign of the noise storm yet which I suspect is the reason for dropping down to a bRAS of 500 kbps worst case which seemed to have happened in the small hours.
I noted last time I rebooted that a couple of the bins were brought back into service so perhaps I could try restarting the router.
I'll obviously drop my remote connection but it might just make it slightly better - or do you think that's too risky?
Otherwise, perhaps after waiting for another storm, and then experimenting with noise levels ?
Kind regards,
Walter
[attachment deleted by admin]
-
>> noise storm yet which I suspect is the reason for dropping down to a bRAS of 500 kbps worst case
I think youre correct in the assumption of what it will be.
>> that a couple of the bins were brought back into service so perhaps I could try restarting the router.
Probably not worth it - I'd try and keep the line as stable in an attempt to get rid of the 15dB target SNR that it appears to have picked up.
Because the target SNR is high, there not many bits being loaded into each bin - only about 3 or 4 at the high end. After 620kHz its only going to give you around another 12-16 kbps of sync speed per bin that is loaded.
-
Hi Kitz et al,
Not a storm but bad case of the droop ! I would much appreciate thoughts on this anomaly.
Kind regards,
Walter
Further inspection shows the noise margin has, at present (00-16 Sat 28 Feb), increased to 19 db but the sync speed has redced to 1472,
Althought the portal hasn't yet caught up, I suspect that the bRAS will be about 1,000
I'm still baffled as to what could cause such a phenomenon, but I've yet to establish if anything unusual was happening in the area.
[attachment deleted by admin]
[attachment deleted by admin]
-
hmmm quick burst of noise.. that looks from that graph that it was recovering again before the router even had time to settle down after the resync.
If the stats are still like that now, then a resync is in order to get the speed back.
Before you do though - just on the offchance that its managed to record it have a quick look at DMTtool it may show which frequencies have been affected by comparing it to the prev nights and seeing if theres any bins that now arent in use. It may have all happened too quick for DMTtool to capture it too.
-
Hi Kitz,
Here are some pictures with hopefully sensible titles.
Kind regards,
Walter
[attachment deleted by admin]
-
Hi again Kitz,
Herewith the Sat night shots including a better bRAS.
The 585V7 shows v high FEC errors but I gather these figures can be tempramental.
I'm wondering what to do from here?
I see no reason that this cycle won't be repeated and the end user isn't too much of a techie.
The major problems are so relatively infrequent and others closeby and much further away
have rock solid performance that it seems unlikely (but not impossible) that it's an external REIN problem.
I have another new 585V7, an old DG834V2 and a new DG834V4 so could swop
to see if it's an intermittent problem at our end.
However I don't know how to persuade BT O to change a line card which could be another option.
Kind regards,
Walter
[attachment deleted by admin]
-
Comparing the 'brefore reset' with your graph you first posted in this thread.. it looks like bit allocation was affected across all bins.. which would seem to indicate that what ever took the connection out was affecting the whole downstream frequency range.
Even some of the latter upstream frequencies would appear to be affected (bit hard to tell for sure because of the spectral mask that is applied to frequencies in that range but it looks steeper?).
Having seen the bit allocation afterwards Im pretty sure its electromagnetic interference.
The distinct drop in bit loading certainly looks like a large noise problem somewhere.. I was hoping that it may show a particular range which would perhaps make tracking it down a lil bit easier.. but its all across the board. Some sort of power surge/static... could be anything that causes it :(
>> new DG834V4
May be worth giving that one a go - different chipset to see if it can cope with the bit allocation a lil bit better.. but I dont expect miracles.. if it is a large noise burst it will probably take that out too at some point.
>> BT O to change a line card
I dont think it is the line card - not to cause those symptoms.
-
Thanks yet again Kitz,
I was about to update you with the latest situation and was trying to describe it as a highly intermittent white noise problem.
This (Sunday) afternoon there was another noise storm but this time it was apparently in the middle of a phone conversation:-
"At that time I was on phone and there was a lot of noise on the line which I could hear but
she couldn't. It started after I'd been speaking for about 10 mins. There were no electrical appliances running at the same time."
As I didn't want the bRAS to be reduced I decided to risk re-syncing the modem which did indeed restore the situation to almost pre-incident settings.
Would it be reasonable to postulate that:-
a) the phone and house wiring are unlikely to be directly involved as it was clear before and after ?
(Remember this is the house where I had to get BT to install an Openreach filtered faceplate and feed the phone connection back down another pair of about 4 metres of the cable to an outside junction box.)
b) it is a remarkably wide frequency band as it includes the first 3 kHz and it also causes the modem to truncate the ADSL signal by 45 tones as well as reducing the high tone capacities almost uniformly.
c) the line is normally very stable indeed with only a loss of 1 or 2 dB overnight and then up agiain the next morning.
When I discovered the anomaly, and after I remembered that I had to Stop and Start the DMT monitoring to see the current settings, the bit rate was down to 1024 and the tones in use had dropped to 97 and their capacity had been "hedge trimmed". I used DMT to resync the modem and it returned to nearly the previous bit rate of 2784 and 142 tones.
The three pictures below show the noise burst and my intervention, the lower DMT performance after the anomaly and the restored DMT after I had resynced it.
Any further ideads Kitz and / or Ezzer et al ?
Kind regards,
Walter
[attachment deleted by admin]
-
I spoke too soon!
We were "bRASed down" to 750 kbps within 11 minutes of the storm.
Kind regards,
Walter
-
.... BUT by some miracle we were returned to a bRAS of 2000 kbps WITHIN ONE HOUR !
-
>> describe it as a highly intermittent white noise problem.
Yes very probably :/ The problem is going to be tracking down something like that :(
From everything youve said it doesnt appear to be the line - it could possibly have been a HR fault, that causes symptoms when wet or if the wind blew the line against tree branches etc... but you said that this has already been checked and the D side replaced?
The line itself seems to be in very good condition for its length... just the 'noise problem' letting things down.
>> tones in use had dropped to 97 and their capacity had been "hedge trimmed". I used DMT to resync the modem and it returned to nearly the previous bit rate of 2784 and 142 tones.
Typical noise burst symptoms through EMI. Start of the storm knocks out the dsl.. then whilst still there vastly effects the bit loading.
Source of problem may not even be at the EU's home could be being picked up from nieghbouring properties. We've had quite a lot of these of this forum over the past year or so. Culprits have been neighbours faulty TV or music centre. Neighbours Faulty Monitors and Sky boxes have been quite common of late.
>> BUT by some miracle we were returned to a bRAS of 2000 kbps WITHIN ONE HOUR !
ahh so the 'new' system does work how it should on occasions. :)
-
>> BUT by some miracle we were returned to a bRAS of 2000 kbps WITHIN ONE HOUR !
ahh so the 'new' system does work how it should on occasions. :)
Occassions :lol:
The line is now being investigated again. The e-side and d-side will be the first to be looked at and from there we'll head to the line card. Looking at the Graph I have to agree with your synapsis that the white noise is EMI. The question remains, where is the noise coming from...
-
The D side wasn't actually replaced but re-wired to a new filtered Openreach Master Socket and the modem is plugged directly into it.
Overnight the noise levels have remained almost flat.
Kind regards,
Walter
-
Just to update you all, the saga continues !
This seems quite an unusual problem so it's caused me to evaluate what I'm doing.
I am using empirical observations to investigate a highly intemittent problem on an otherwise nearly perfect line.
Quite reasonable speeds are apparent for most of the time but it is relying on the valid communication of the 585V7 modem and the corresponding equipment in THCN.
When things go wrong they do so quite dramatically and the exchange equipment responds.
There is sometimes a smaller excursion just before the crash as can be seen in the Storm brewing picture.
There is also a "horrible 160 kbps" picture showing a much reduced but symetrical result; this does not seem to be the normal sort of problem where a few bins are unusable due to particular set of noise frequencies. Hence my earlier description of white noise.
On one fault occasion when the householder was actually talking on the DECT phone, and had been doing so for about 10 minutes, he stated that the speech "suddenly sounded all fuzzy, but the other person couldn't hear it". This suggests that whatever the event is, it affects the entire frequency spectrum down to the 3 kHz audio levels. (Yes we have changed filters.)
Yesterday there was one event at just about the time the washing machine started but other events have happened in the middle of the night when the house is quiet and also during the day when the house is unoccupied.
There is a refurbished 3 phase 11 KV overhead power line and transformer in the vicinity but nothing unusual was observed during the severe storm we had last Tuesday night.
Another ADSL user within about 300 m of this house has a good stable connection, nor am I aware of any other similar problems in the village.
The house wiring is of varying ages and includes a double solenoid bell but the master socket is within 4 m of the cable entering the house and the modem is connected directly to a new BT Openreach filtered faceplate.
One question I'm asking myself - is there actually a problem or is the modem or the exchange equipment wrongly detecting an anomaly ?
We have noticed that the 585 can clock up astronomic FEC errors which might suggest there's a logic fault ?
To help assess the situation yesterday I replaced the 585V7 with another 585V7 I've bought direct from Thompson and am still waiting for another crash.
I have posted a set of recent screen dump pictures below.
I have also included one showing the rapid change of bRAS rates, both up and down, when large sync speed changes are detected at THCN.
All comments and suggestions welcomed !
Kind regards,
Walter
http://s694.photobucket.com/albums/vv301/waltergmw/?action=view¤t=TwodropsResync09-3507Mar093A.png
http://s694.photobucket.com/albums/vv301/waltergmw/?action=view¤t=Horrible160kbpsDMT09-18Pict2.gif
http://s694.photobucket.com/albums/vv301/waltergmw/?action=view¤t=00-17sat07Mar09spike.gif
http://s694.photobucket.com/albums/vv301/waltergmw/?action=view¤t=DMTafterre-boot23-305Mar09.gif
http://s694.photobucket.com/albums/vv301/waltergmw/?action=view¤t=Stormbrewing10-43to11-05.gif
http://s694.photobucket.com/albums/vv301/waltergmw/?action=view¤t=Stormarriving11-45to12-48.gif
http://s694.photobucket.com/albums/vv301/waltergmw/?action=view¤t=StormaftermathDMTscreen.gif
http://s694.photobucket.com/albums/vv301/waltergmw/?action=view¤t=bRASasrecordedbyZen.gif
-
s there actually a problem or is the modem or the exchange equipment wrongly detecting an anomaly ?
We have noticed that the 585 can clock up astronomic FEC errors which might suggest there's a logic fault ?
A large amount of FECs indicates low level noise.... FECs meaning that data has been recovered/repaired, that without RS encoding would become more serious errors and cause the line to drop sooner. The line should be able to cope with quite a lots of FECs, but too many and its an indication that at times the line's SNR is being affected causing what would otherwise be corrupt data packets.
If its racking up tons of FEC's the router may even get a bit warm as the processor will probably be working overtime correcting and reconstructing data packets.
-
Kitz et al,
I'm pleased to say the problem has probably been eliminated.
BT O fitted a RF3 filter and the line is much more stable now.
SNRM varies between about 12 dB and 14 dB (night to day).
I don't suppose we'll ever find out what was causing the difficulties.
There was a 9 hour power outage last week so it's just possible that an arcing component has been replaced.
It's interesting to note that the bRAS rate adjusted very rapidly when there were major sync speed changes but it has taken 6 days to return to 2,500 kbps whilst the sync rate has remained between 2624 and 2912 kbps. (See the picture below.) The tone count has varied between 151 with 6 gaps and 145 with four gaps which has provided the fastest sync speed. Line attenuation has remained constant throughout at 55 dB and Tx power has returned to 18.5 dBm.
I'm now intending to leave sleeping dogs well alone !
We have been chasing this highly intermittent fault since December and we are all relieved that it seems to have been resolved now.
Thank you Kitz et al for your help and suggestions.
The ISP is also to be congratulated at staying with this problem for so long !
I know of many that would not have been interested, nor have the systems in place to monitor and record the anomalies.
Kind regards,
Walter
[attachment deleted by admin]
-
That's good to hear, even if there isn't a full explanation. :)
-
BTo usually fit RF3s in an area where there is a lot of radio EMI inerference.. usually where its from a radio/tv mast which causes widespread interference across a whole range. I'm not sure exactly which frequencies an RF3 filters out.. but despite the fact it is supposed to let adsl frequencies pass through unhindered, it can sometimes (but not always) filter out some of the higher adsl frequencies and may occasionally in these instances give a slightly higher attenuation reading.
It looks like it may have done some good though on that particular line. :thumbs:
Out of interest - sorry I cant remember - but did that line have any bell wires still in place? RF3's tend to work best where the bell wire is acting as a large aerial.
I'm just glad that all now seems to be sorted for you :)
-
Thanks Kitz,
No there are no bell wires at all, but there is a "prehistoric birdsnest" including a double solenoid bell acting as another junction box, a DECT phone on the ground floor and a wireless fuel tank level indicator, but no WiFi. The modem and master socket were within 4 metres of the drop wire in the second floor attic.
The attenuation has remained constant at 55 dB on a line of about 4 km in length.
We do also get the occasional high level aircraft from LGW and lower Chinooks etc. from Odiham. I started in this house by getting BT to remove a star connection and back-feeding the phone line from the new BT O filtered faceplate back down another pair to the external junction box.
I'm afraid this one is going to remain a mystery as BT O are not usually forthcoming with their exchange modifications. I'm reasonably sure the problem, which was highly intermittent - i.e. about once in every 4 to 7 days, had little to do with a constant public wireless broadcast nor any other actual human-operated radio device such as CB radio. It happened several times in the early hours in a sleepy village with only one house occupied by septogenarians closeby and the main road 300 metres away. As you've seen the effects were across a very wide frequency spectrum right down to the 3 KHz audio level.
I've attached a Noise margin picture from this afternoon. The night time ones drop a couple of dB and are a bit more spikey by 0.5 dB
I do hope we can just say RIP !
Kind regards,
Walter
[attachment deleted by admin]
-
It appears the issue was the line card. This was replaced after they fitted an RF3 filter.
-
>> It appears the issue was the line card.
Thanks for the report Azzaka.. :)
... although Im not 100% convinced about it being a line card fault as such, due to all the classic symptoms of intermittent REIN.
One plausible explanation though could be that a neighbouring line on the dslam was on occasions getting a good SNR and power cut back on that line was taking a while to kick in/or/ powercut-back didn't occur until that lines next resync. This would cause NExT on the dslam and affect all users on that particular line card. With you perhaps mentioning REIN/EMI in the fault report to them, some engineer may well have twigged where to look for the REIN.
The main thing is that this is now fixed for the EU and thats good news... and well done to Zen for sticking with a fault that is often very hard to track down. :thumbs:
-
So you DID see my " It appears the issue was..." ;)
No other notes from the engineer apart from that one, Now its time to fix another one. Same exchange, little further down the line.
-
Hi Kitz (and Azzaka),
It's still early days on this one and we're still in wiring and NTE5 mode at present.
Just to whet your appetite; it's interesting to note that we have the same signature noise drops to zero.
I'm using the same 585V7 and remote-monitored laptop.
You might like to know that we're getting quite notorious in the village, and I think with BT O as well.
Kind regards,
Walter
[attachment deleted by admin]
-
>> So you DID see my " It appears the issue was..."
lol - I'm very aware that the reports that come back arent always full of info, nor always give a proper explanation :D
>>> Just to whet your appetite; it's interesting to note that we have the same signature noise drops to zero.
That looks more like some sort of impulse noise, but very different pattern from the other one.
Fridge or something thermostatically controlled?
Thats a very long line and is going to be very susceptible to noise :(
-
@ Kitz
We now have a veritable pastoral symphony ! Nearly a flat calm and then all hell breaks loose in the early hours and up to mid day.
It remains to be seen what the cure is but how come such a long line has almost no noise and then goes wild and is still very bumpy as at 15:30 ?
Another interesting point is the higher speed for a short period around two crashes.
(Note this is the same 585V7 modem I used on the other line.)
My guess is still an intermittent line card fault
Kind regards,
Walter
http://i694.photobucket.com/albums/vv301/waltergmw/03-39Sat21Mar09pic3.png
http://i694.photobucket.com/albums/vv301/waltergmw/04-42Sat21Mar09pic4.jpg
http://i694.photobucket.com/albums/vv301/waltergmw/05-44Sat21Mar09pic5Crash1.jpg
http://i694.photobucket.com/albums/vv301/waltergmw/06-47Sat21Mar09pic6Crash2.jpg
http://i694.photobucket.com/albums/vv301/waltergmw/07-50Sat21Mar09pic7.jpg
http://i694.photobucket.com/albums/vv301/waltergmw/08-52Sat21Mar09pic8Crash3.jpg
http://i694.photobucket.com/albums/vv301/waltergmw/09-55Sat21Mar09pic2A.jpg
http://i694.photobucket.com/albums/vv301/waltergmw/12-00Sat21Mar098pic.jpg
http://i694.photobucket.com/albums/vv301/waltergmw/12-00Sat21Mar09Speedbumppic5C-1.png
-
It certainly looks like an intermittent line fault of some sort. It's very similar to experiences which I had on my line on a few occasions, and on these occasions there was a very obvious crackling on the telephone. I reported it to BT, but by the time they responded the crackling had gone and the ADSL connection was fine again.
-
@ Kitz and Roseway,
Continuing with the saga, the line remains a little unstable with the SNRM varying between 5 dB and 11 dB.
As to be expected the noise margin increases when the sync speed decreases.
The modem has reset itself several times and occasionally I've done a manual reset.
This often produces a sync speed up in the 600 kbps range, but then the modem resets itself back down to 448.
With a line of this length (attn'n 63.5 dB) I believe the observed noise margin patterns to be normal usually.
Perhaps what's surprising is the almost flat noise lines before these events started.
I assume that, as part of the initialisation after a reset, the modem negotiates with the DSLAM and the noise discrimination logic between the two define the tones and bit loading which then is also reflected in the current sync speed.
This logic then continues to monitor the individual tones loading them as has been determined until there is a major loss of data, whereupon the modem decides to reset itself.
I did just wonder if there was a sort of positive fault with the noise discrimination logic falsely giving the previous flat lines ?
I'm always a bit sceptical in these situations where you are observing the equipment and systems themselves rather than with independent test equipment.
However that would clearly be difficult to do when you're relying on the modem and DSLAM to be self-regulating in an inherently noisy environment.
Any corrections, comments or ideas would be welcomed.
Kind regards,
Walter
-
With a line card fault (due to the no of lines that will be on the card) I would expect if it was a line card fault for it to be more frequent. An exception would be the NExT example I gave in my post above, where the x-Talk is being generated from a neighbouring line.
During the 'bad' period.. it could be typical of intermitant REIN... or like eric says an intermittant line fault.
>> This logic then continues to monitor the individual tones loading them as has been determined until there is a major loss of data, whereupon the modem decides to reset itself.
Correct, resync occurs when (a) major loss of data (router enters serious alarm state) and/or (b) Noise becomes so bad that insufficient bits can be loaded. Event (b) can and often will cause (a) to occur.
What the graphs are clearly showing is at times the line becomes 'noisy'. This could be Noise through EMI or it could be reduction in Signal strength cause by an intermittent fault on the physical line.
When SNR starts being erratic, your router can go into overdrive with the bit swapping process, it may eventually shut some tones down as unusable if the SNR gets too low in those sub-channels. This can then result in there not being sufficient channels to support the original Bit Allocation from last sync.. then if the line cant support enough bits it will eventually have to drop and resync at a lower speed.
-
Does the SNR margin fluctuate like that at similar times each day?
-
@ Kitz Thanks very much.
@ orainsear There were a few days of very "calm" noise margin graphs, then the storms and now it seem like a typical noisy line as you"ll see below.
Kind regards,
Walter
[attachment deleted by admin]
-
@ kitz
>>or it could be reduction in Signal strength caused by an intermittent fault on the physical line.
It's interesting to note that the "noise" pattern has become much less erratic after we did a quiet line test.
BT Retail / Openreach are investigating tomorrow.
Kind regards,
Walter
[attachment deleted by admin]
-
The BT Retail / Openreach engineer reported no fault found on the telephone side. However I managed to chat to our local "ezzer" today who immediately suggested an intermittent high resistance fault.
I had "filtered" my mind to think only about the ADSL part, but it's now obvious that we might cause additional disturbances by going on and off hook as the RMS current could well induce another bout of spikes. The circuit has been up to 704 kbps and down to 135 kbps like a yoyo today and the modem has reset around 40 times. For the last two hours it's been almost as flat as a pancake on 704. Patience is a virtue but we'll get there hopefully before too long.
If anybody knows of any other tricks I'd be glad to hear of them.
Kind regards,
Walter
-
Lifting the phone off the hook sometimes does clear an intermittent HR fault.
In fact if the adsl works better when the phone is in use this is indicative of a HR or High Open type fault
From ~ adsl only works when the phone is being used (http://www.kitz.co.uk/adsl/connectionprobs.htm)
Possibly a fault on the actual phone line perhaps due to worn cables or water on the line.
There may be times when a cable or joint is only slightly damaged/corroded and shows no immediate problem, however the damage is sufficient to increase resistance on the line.
When the phone line is in use, it generates a small electrical current which is needed to carry the voice signal. This current helps reduce resistance on the line and can be sufficient to "bridge the gap" just enough to carry the adsl signal.
-
When I was having trouble with a crackly line, I sometimes got some temporary relief by doing a 17070 ringback.
-
Hello everybody,
SUCCESS AT LAST !
I suspect that, thanks to my portable test equipment (laptop accessed remotely with logmein.com, running DMT and Routerstats lite plus my 585v7) and our very helpful ISP Z,
BT have changed yet another line card in THCN with quite astonishing results for a 63.5 dB line - see below.
The downside is that it has taken just over 4 weeks to achieve two line card changes.
However our local BT Openreach gurus are now aware that we have the test equipment and do listen to us once the BT dinosaur has woken up.
It does beg the question as to how we could get BT to monitor their line cards without waiting for all their customers to grind through all their call centres and everybody dismantling their master sockets.
I suppose from BT's viewpoint they observe so many cases of bad wiring they'd rather let the faults take longer to isolate in the first place.
If only it was possible to have a rational discussion with might halve the number of BT site visits.
I am now quite a happy chappy !
Kind regards,
Walter
[attachment deleted by admin]
-
Interesting that yet again this has been resolved by replacing the linecard.
What I am interested in is finding out why.. and how... that im both these cases... something that so very clearly points to intermittent REIN is being resolved by replacing line cards.
I may be wrong but unless there was a whole batch of linecards installed on that DSLAM/MSAN that were faulty why it should materialise with these symptoms. I still feel that something more like NeXT from a particular line would be causing something like this to occur - otherwise surely it wouldnt be so intermittent. With the no of users on a linecard you'd expect this to be far more noticeable and consistent.
Azzaka, are you able to find out any more info from BT about this... I'd love a technical explanation because something just doesnt feel right about this so far that I cant put my finger on.. and I wonder if there's something a bit more deep rooted... or even conspiracy time one particular line on that dslam is having causing massive NeXT when that particular line connects and causing problems for any neighbouring lines on the same linecard... and they are curing this by moving lines around to different cards.
-
@ Kitz and Leo,
I'll list below all that I know about the two lines.
The first was Sue in the village centre off cabinet 19 with a line distance of about 4 km.
DMT shows Sue's DSLAM as >>Vendor ID: P----<<
Herewith her 585v7 log:-
Info
01 day 06:43:38 (since last boot)
FIREWALL event (1 of 12): modified rules
Info
01 day 06:43:38 (since last boot)
FIREWALL event (1 of 24): created rules
Info
01 day 06:38:39 (since last boot)
LOGIN User Administrator logged in on [HTTP]
(from 192.168.1.64)
Info
00:01:01 (since last boot)
FIREWALL event (1 of 6): deleted rules
Info
00:01:02 (since last boot)
GRP Default destination is routed via gateway
nnn.155.35.179
Warning
00:01:01 (since last boot)
PPP link up (Internet) [nnn.155.35.179]
Info
00:01:01 (since last boot)
PPP CHAP Chap receive success : authentication ok
Info
00:00:59 (since last boot)
PPP CHAP Receive challenge (rhost = ERX3.Reading2)
Info
00:00:46 (since last boot)
xDSL linestate up (ITU-T G.992.1; downstream: 2720
kbit/s, upstream: 448 kbit/s; output Power Down: 18.0 dBm, Up: 12.5 dBm; line Attenuation
Down: 55.0 dB, Up: 31.0 dB; snr Margin Down: 14.0 dB, Up: 16.0 dB)
Warning
00:00:28 (since last boot)
DHCS server up
Info
00:00:28 (since last boot)
FIREWALL event (1 of 1): deleted rules
Info
00:00:28 (since last boot)
FIREWALL level changed to Standard.
Info
00:00:28 (since last boot)
WIRELESS interface turned off.
Info
00:00:24 (since last boot)
WIRELESS automatic channel selection done (channel =
6)
Info
00:00:16 (since last boot)
FIREWALL event (1 of 1): modified rules
Info
00:00:16 (since last boot)
FIREWALL event (1 of 1): created rules
Info
00:00:04 (since last boot)
WIRELESS interface turned on.
Error
00:00:03 (since last boot)
[CWMP: 0:00:02.820] setting cwmp defaults
Warning
00:00:02 (since last boot)
KERNEL Cold restart
The second was James off Cabinet 20 with a line length probably around 7 km
DMT shows James' DSLAM as >>Texas Instruments<<
It's interesing to note Sue's PPP CHAP Receive challenge (rhost = ERX3.Reading2),
whereas James' says PPP CHAP Receive challenge (rhost = ERX13.Kingston3)
A picture of part of James' log is attached below as is the last Prodigynet DSLAM data I have for THCN.
I hope this helps but if there's anything else you can train me to do with the 585v7 you've only to ask.
Kind regards,
Walter
[attachment deleted by admin]
-
>>Vendor ID: P----<<
Which manufacturer does this code represent?
-
Looks like the 2 lines are on different dslams/msans then if they are going via different RASes.
Vendor ID: P----
Ive no idea what that is Ive never seen 'P' before
-
@ Kitz,
It's not a DMT display bug as the 585V7 Link Information gives the same
Vendor ID (Local/Remote): TMMB/P
which presumably is where DMT is getting the same information in any case.
I do wish BT weren't quite so secretive !
Kind regards,
Walter
-
@ Kitz,
Do you know you might just be right re your suspicions !
I've just captured the attached noise margin graph which still shows bursts of noise but at much reduced levels.
I've asked James whether they fitted an AR3 but he's yet to reply.
From BT O's viewpoint they have made the line quite usable so unless I can grab the engineer again I don't suppose we'll ever find out.
Kind regards,
Walter
[attachment deleted by admin]
-
Ive done a search and cant find anything at all about who 'P' is.
There are a couple of 'P's that crop up but there is so few of them - one of them is here (http://forums.whirlpool.net.au/forum-replies.cfm?t=883784&r=14041488#r14041488). Revs per min is one of those names that crops up as generally knowing what he's talking about.
One thing that could be a longshot and this is a very wild guess... but the CLI switch for configuring the Vendor ID and Product ID is
-o vendor id [ -p product id ]
Wonder if its just a simple case someone has not configured the vendor id correctly when setting up the dslam/msan?
-
Hi Kitz,
I'd believe anything's possible in sunny Ewhurst !
We've just had the modem drop out and resync at 576 kbps and the noise margin variations are worse than the Blackpool roller-coaster !
Kind regards,
Walter
-
Wonder if its just a simple case someone has not configured the vendor id correctly when setting up the dslam/msan?
Could well be. According to this thread (http://anonym.to/?http://www.routertech.org/viewtopic.php?t=1418) P designates unknown, so it looks like it's either the hardware ATUC has not been configured properly or it's a new manufacturer.
Walter: Have you had any reports of problems from other users of cabinets 19&20?
-
@ orainsear,
I've got one other which I suspect is on cabinet 19. However I am about to circulate my distribution list of about 130 homes to see if anyone else is suffering.
My guess is that there's something around the BT parts of THCN which is causing the noise problem as we see similar problems on different DSLAMs.
I expect all the E side cables run down the same set of ducts for the first 3.5 km at least, but as they must be screened it seems unlikely that they're causing the grief.
The user I'm currently helping has another LLU with TalkTalk but that seems O.K.
I've attached a picture of the last drop which mirrors the types of noise margin graph I've seen many times before.
Kind regards,
Walter
[attachment deleted by admin]
-
@ kitz
How about this for a nightmare ? Do you know of any software that would let us split the noise margin down into single or groups of tones?
Would that give us a better idea of what's going on?
Kind regards,
Walter
[attachment deleted by admin]
-
With supported routers, DMT displays the SNR per tone in the second graph. But in practice (on my system anyway) the second graph is almost exactly the same shape as the first graph (bit loading per tone), so maybe you can infer what you're looking for from that.
-
>> Do you know of any software that would let us split the noise margin down into single or groups of tones?
Unless anyone knows better - I dont Im afraid - well not that would graph it.
DMTtool graphs the tones and if youre monitoring it live - and you have the right router such as a ST585 v6 - then you can sometimes see the shift in the SNRM for the rough area of the tone.
------------------------
/sorry eric I'd started to type this - then got distracted by something else Im trying to sort, but I posted anyhow.
"Warning - while you were typing a new reply has been posted. You may wish to review your post. "
-
A 585v6 would be a good aquisition - it's a good bit of kit and with the right firmware would probably serve you better than the 585v7 for fault finding with DMTtool.
Do you have a have a DMTtool graph of the frequency spectrum for the line that you are currently monitoring?
-
Herewith pictures of my current DMT system, viewed remotely.
I had, perhaps wrongly, assumed that I was limited by using the 585V7 and "allow untested firmware versions"
All suggestions gratefully received.
I will certainly look for a 585V6 and will be pleased for any advice on suitable firmware.
Kind regards,
Walter
[attachment deleted by admin]
-
I will certainly look for a 585V6 and will be pleased for any advice on suitable firmware.
There's usually a few on ebay. If you do decide to buy from ebay get a non-ISP branded one because some of the ISP supplied units are locked to their own services and won't easily flash with standard firmware.
In their wisdom (under pressure from certain ISPs) Thomson crippled the 'expert modes' in their firmwares (commands in the CLI were disabled - the same commands DMTtool uses). The last best firmware for the 585v6 is release 6.1.4.3 and if you check the sticky thread in this forum you can find a link to it.
-
Thanks orainseer,
I shall persue this activity shortly but I have to keep on top of the immediate problem at present.
@Kitz
I've now discovered that the first BT O investigation did not actually change the line card but they did a lift and shift which effectivly uses a different line card.
We thought that had cured the problem due to the sporadic nature of fluctuating noise.
The next BT O visit changed the E side pair and by coincidence another BT O team cured a REIN fault in the cabinet which was affecting many users.
This had the appearance of no real change on our lines.
Just to be absolutely sure I changed the 585V7 for a DG834V4 and am using routerstats only to monitor the noise margin and provide sync speed.
The noise curves are slightly different as the Netgear reports chages down to 0.1 dB but the general appearance is very similar with long periods of calm followed by wild fluctuations and usually causing the modem to re-sync eventually - several times.
This afternoon my laptop was left on running Routerstats lite, but otherwise untouched by human hand, I noticed that noise line had become almost absolutely flat.
I am suspicious as I don't believe that the real noise margin could possibly remain so for long periods.
I am therfore questioning what causes these major changes in operating parameters and subsequent re-syncs?
Could it be with zero real traffic the Tone noise margin summation logic goes into sleep mode as there's nothing there to detect ?
I also note the latest disturbance happened shortly after I had used my remote access software to examine Routerstats, which obviously generated some real internet traffic.
Thankfully this householder has two ADSL lines, the other being directly connected to TalkTalk's LLU system.
That noise margin seems to behave in a similar but less-pronounced way.
We are asking BT to continue their investigations and changing the D side pair, if others are available.
I've attached pictures to illustrate this very strange situation, together with one of my 585V7 connected on the TalkTalk line.
Any ideas would be most welcome.
Kind regards,
Walter
[attachment deleted by admin]
-
>> did not actually change the line card but they did a lift and shift which effectivly uses a different line card
That makes much more sense!.. and ties in more with what I was saying previously.
>> Could it be with zero real traffic the Tone noise margin summation logic goes into sleep mode as there's nothing there to detect ?
Im not 1--% certain, but I'm pretty sure it should continue to monitor. My own line is monitored 24/7 and I see shifts recorded on my graphs even when I'm not around.
Ive hardly been here the past few days and therefore hardly any traffic, yet throughout that period my graphs have continued to show many many changes both up and down regardless that there was no data being processed at the time.
I cant see from the graphs what scale/how much SNR was being fluctuated by. I dont know if it is possible for an own line to cause some sort cross-talk effect on itself when passing data.. as strictly speaking I thought x-talk affected neighbouring lines.