Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[roseway]

There's no simple answer as to what is an acceptable variation in noise margin, but large short term variations such as seen in the graphs you showed us earlier are definitely not normal. They indicate either a line fault or REIN. Changing your router won't have any significant effect on such large variations - it's not likely to be a router fault.

There's a lot of information about REIN here and this may help you find the source if this is the problem. If it's a line fault then you're in Tiscali's hands.

[sqwim]

Thanks for the continued replies, it's good to get this sort of advice - pity it never seems to come from the ISP!

If the problem is REIN then it's somewhere between my test socket and the exchange - I have checked EVERY electrical item in the house to no avail, I've checked 612 khz with a portable radio and there's no interference I can discern that would affect the router.  If this is the case then there's presumably little I, or Tiscali, can do about it (is there??) and I may have to find some way of living with it.

However... before coming to that conclusion I'd like to find some way of having Tiscali prove to me that it isn't a line fault.  Is that realistic?  Am I likely to have success?  How do I best do it?  Am I best writing an email to the top chap of what used to be 3rd level support and asking for assistance?!

Many thanks

[waltergmw]

You have obviously been doing observations for an extended period, but when doing so have you continued for say 30 minutes at a time?.

Have you tried the usuals:-

17070 Option 2 Quiet line test and check the noise using Routerstats
Making an ordinary call and ditto
17070 Option 1 and ditto

(The Options might not work if you have a LLU connection though.)

Kind regards,
Walter

[sqwim]

Yes, I have sampling for the last week or so solid at 5 second intervals with RouterStats.  The problem is generally very bad between about 7pm and 7am and far more stable outside of those times.  However, this is a very general rule, I have seen the fluctuations and large SNR drops throughout the day and the start / finish times of the 'bad' period can differ by hours on occasion.

As you mention I haven't been able to get 17070 > options to work on my line (non BT), Tiscali do not seem to have such a service.  When asked their support team knew nothing about it (not on the script?!).  However, when making ordinary calls there is no effect on the SNR according to RouterStats.

[Chrysalis]

my guess is, if the fluctuation can be smokescreened by a 15db noise margin and/or interleaving then it wont be considered a fault by some isps and in particular BTw.  The exception would be if the noise fluctuation causes the synch to drop below fault threshold on a regular basis.

[GunJack]

This is sooo similar to the problem I'm currently having, again with a tiscali LLU line. You may get more joy by using the tiscali forums here:-

http://www.tiscali.co.uk/forums/index.php?s=1ea0cb008f527fcd8e0be4c40b2ecbf4&

although, I just sent them around 30 hrs-worth of SNRM data from DMT, and don't think they actually understand what the issue is....AND they keep wanting to change my profile to 256k upload to try and solve the problem

[sqwim]

Interestingly when Tiscali called me back today they tested the line and said they could actually detect a voice fault on it, a very low level constant background hum that I had assumed was just normal (as there were no crackles, hisses etc).  They escalated it to BT OR and, impressivley, they started looking into it 30 minutes later, chap called, tested things, turned up and found that just outside the house (otherside of the wall to the NTE5) there was a damp joint causing the problem.  He fixed that, confirmed no voice fault.  Brought out his HAWK, ran a good few tests and said the line was coming back with no errors.  Fair play to him, he was a nice chap, here for a good while, put some effort in and seems to have made the line a little more quiet for voice.

HOWEVER, SNR on the line is still very eratic and probably worse this evening than it has been for a while (see attached).  Unfortunately when he was here it was early enough that the line was 'reasonable' (not great, fluctuations of 4-5 db but with the starting point high enough (10 db) that SNR didn't get too low (5 db)).  Now that evening is upon us it has hit 0 db about 20 time in the last couple of hours.

The BT OR chap said he will call me back tomorrow to see how things are.  Obviously I'll tell him it's not fixed but what else, realistically, can I expect him to do?  He seemed very willing to help but how far can I push this?!

Thanks

[attachment deleted by admin]

[sqwim]

Quick update, having had a look at the Bits/Tone tab in routerstats, the bits seem to drop off more now thean they have done previously when the line is bad.  However, I'm not an expert in reading these things.  I've attached a few examples of the Bits/Tone tab.

The first is when the line is OK - pretty good/stable.
The second is when it was WORSE - pretty bad previously.
The third is one just NOW - with the line as bad as it has been for a while.

If anyone can read these things / offer any advice, it'd be very welcome!

Thanks

[attachment deleted by admin]

[jeffbb]

Hi

One thing that strikes me as odd is that at the lower frequencies your tones are very heavily loaded  10 to 12 bits that is 30 to 36 db but the snr /tone is only  27 to 35 db.  Normally you would expect  to have some margin ideally +6db . Just wondering if there is a mask problem . That is where the lower frequencies should have less data to Prevent  crosstalk .
I will see if I can find out about masking ,I think I have seen references in Kitz .
See my Bits /tones for comparison.
regards Jeff

[attachment deleted by admin]

[jeffbb]

Hi

from Kitz # Notice how the shape of the Bit Allocation (blue lines) correlate to the SNR (grey lines) in the lower table. The yellow lines show the SNR Margin.
# Also note the smooth curves at on the upstream causing a inverted 'U' and also at the beginning of the downstream. This is likely due to spectral masks applied at the DSLAM which ensures that power levels are cut back to reduce the likely hood of cross-talk on those frequencies.

Read more: http://www.kitz.co.uk/adsl/adsl_technology.htm#ixzz0TYn1WhJj    (copy and paste for actual extract)

whole page
http://www.kitz.co.uk/adsl/adsl_technology.htm  

Regards Jeff

[sqwim]

An update (apologies for the delay)...

Thanks to jefbb who gave a contact address for Richard Lawrence, who appears to be Tiscali's Head of High Level Complaints, in an earlier post I've finally made contact with useful Tiscali support staff based in the UK who have been affording me proper tech support and customer care.

They sent a 'Qube engineer' round to 'test the 'internal configuration'.  It turns out a Qube engineer checks you've not done anything stupid with your cabling (I haven't) and insists on providing a new 'Tiscali crippled' router (limited functionality etc) in case the problem is with that (it wasn't I've been using one of two non-crippled non-Tiscali routers).  Anyway, since the Thomson TG585 v7 seems better than the Siemens Gigaset they originally sent out to me I thought I'd humour them and stick with it instead of my Netgear's for a while.

The TG585 has an SNR of around 13 db (which seems very high!) and it doesn't seem to fluctuate like the Netgear's does.  'Great' you think, the problem was the router and not the line afterall... not so.  The TG585 cannot hold on to the connection at 13db and has to resync at 21db (even higher!) and a far lower speed 3-3500kbps (when behaving itself the line can achieve 5500-6500kbps).  The Netgear very rarely actually 'lost' sync, when the SNR hit 0 db it would usually just report an SNR of around -214000000 db and be very slow until a restart.  I suspect that whereas the Netgear did that, the TG585 actually loses sync and has to reconnect at a lower speed/higher SNR.

Anyway, today's chat with Tiscali has them telling me that no matter the problems I'm having, as long as the line can connect at over 2Mb without issue (which it can I suppose) they cannot 'make' BT fix the line (unless there's a voice problem, which there isn't).

They have arranged to send out a REIN engineer with special equipment to try and detect any REIN that might be causing the problem.  I'm not full of hope as I've already checked whilst using every electrical piece of equipment we have to no avail and there's no discernable pattern that would indicate an electrical item causing the issue (it's generally worse all night  and reasonable during the day).  It also means that if they do find something it's likely to be outside of my control!

I'm happy about their efforts with the REIN engineer, but a little concerned about the BT line and 2Mb rule.  Despite the obvious problems (assuming they are not REIN related) with the line, is it really true that if it can attain and keep a 2Mb connection nothing can be done to fix?

Cheers
Sqwim

[jeffbb]

Hi
As usual they try to bluff .
quote from Kitz "Fault Threshold Rate.

Once your MSR has been set, BTw use this figure to calculate your Fault Threshold Rate which is in the region of 70% of your MSR. BTw will only investigate speed related faults if your speed drops to below the Fault Threshold Level.

Read more: http://www.kitz.co.uk/adsl/maxdsl2.htm#ixzz0WgfTCVJT

see also http://www.kitz.co.uk/adsl/maxdsl2.htm

More info to help you argue with them.

Regards Jeff

[sqwim]

Thanks for the info.  From what that page indicates it seems that the MSR (Max Stable Rate) is key here and this is determined from the lowest achieved rate (rounded down to nearest 0.5 Mb) over the initial 10 days of DSL Max synchronisation.

That was months ago, how can I find out what this is?

Certainly if they take the lowest rate over the last 10 days it'll be about 3500 kpbs = 3.42 Mb which rounded down becomes 3 Mb.  70% of which is 2.1 Mb, close the to 2Mb rule they have mentioned.  This seems ludicrous when the line can, when behaving itself, connect at over 6000 kbps (5.86 Mb)!

Have I understood things correctly?
How can I find the line's MSR?  Do I have to ask Tiscali?  I risk them just giving me a figure that means they don't need to do anything!

Thanks

[waltergmw]

Hi Squim,
I think you'll only be able to get the MSR from the dreaded T if they are co-operative.

You'll see here that some will be able to re-train a BT Wholesale line here:-

http://forum.kitz.co.uk/index.php/topic,6046.0.html

Kind regards,
Walter

[jeffbb]

Hi

quote From Walter  You'll see here that some will be able to re-train a BT Wholesale line here:-

If that is done with a bad line then you will be lumbered . This is my fear about some ISPs they will quickly cotton onto an easy way to avoid having to sort out some problem by  doing a retrain so reducing the MSR .

Regards Jeff