546 and DMT: latest results

Am finally getting to grips with DMT, though it does rather look as though my line's pretty bad, certainly worse than I thought. After only 2 days since the last resync I did, I've clocked up 300 million FEC errors and 11,000 CRC errors (as of this morning). And that's with me having set a Target SNR of 11.5dB at a speed of 3872K bps. It's definitely the case that firmware 5.4.0.14 gives rise to far more FEC and CRC errors than 6.1.4.7.

I've been monitoring the deviation in SNR per tone at certain times of the day. Here are some DMT images that show that:

http://img243.imageshack.us/img243/8648/dmt200609192034yd1.png
http://img134.imageshack.us/img134/9914/dmt200609191106qz6.png

The first shows the SNR deviation between 7.30pm and 8.30pm in the evening. This is arguably one of the busiest times of day for Internet usage and where local interference is also most likely to occur. The second shows the same plot but between 10am and 11am on the same day (yesterday, in fact), obviously indicating quieter conditions. Notice how the evening SNR plot gradually goes more and more negative, after tone 120 and, at one or two points, drops by around 15dB, maybe more. I set the sampling to every 30 secs and ran the monitor for an hour. The morning deviation is not so bad and appears to generally move positively.

Looking at the top graph, there appears to be a horrible gap in the tones at around 97, with even wider gaps at 128 and 176.

In the middle graph, notice that DMT reports, on the left, that the SNR actually goes negative (-2dB). Someone on these forums recently recommended that the spot SNR should ideally not be allowed to go lower than 3.5dB. Certainly, at present, my line can't meet that criterion.

Given that I've tweaked the Target SNR to 11.5dB, up from a default of 6dB, and thereby reduced the sync speed to 3872K bps, these seem to be very poor results. In general, the lowest SNR seems to still keep the connection stable (probably because of the interleaving) but, all the same, the CRC errors mount very quickly. If possible, I'd like to get the CRC errors down to 100 or less in the same 2 day period but, at the moment, that seems a pipedream.

Am I rushing the gun, as far as resync'ing goes? Should I leave at least 3 or 4 days for the line to settle out to the new settings, before drawing any conclusions?

As things now stand, my inclination is to increase my Target SNR even further, perhaps pushing it up to 15dB. That'd probably mean a drop in speed to around 3000K bps, but then perhaps that's where my line's best operated, given its length and attenuation?

Addendum: I've been setting the Target SNR in the morning, rather than in the evening, as this gives me the highest sync speed for the relatively high Target SNR that I'm setting (because conditions are quieter). The idea is that, by me setting a Target SNR of around 12dB in the quiet period of the day, there's then enough allowance for the SNR to drop later in the day by as much as, say, 6dB. Thus, in the evening, the sync holds. That said, DMT reports that there are times when my spot SNR gets so low as to go negative.

Edited by deleted (Wed 20-Sep-06 12:22:49)

If you check my other thread you have got the exact same thing I noticed, just after 120 (50%) your signal sharply is degraded and I think this is because the dslam only provides 25% of the power to the 2nd 50% tones. I wonder if you enabled power cutback and your synch stayed above 3424 since you dont have much bits after 120 then you may be better off.

I said to you before you got 7k crc but thats not a massive number due to your line conditions you are always going to get some crc errors and its something you need to live with as long as they are not generally accumulating you should be fine. The fec is much higher in this firmware but wont affect your connection. Earlier today I had a noise burst which caused me to get 30000 crc every 6 seconds and needless to say I had huge packetloss, its those type of figures that are problematic. I waited for the noise burst to end and resynched raising the snr on the lower tones (where the bursts occur) and then they were high enough to only give me FEC not CRC, no affect on connection.

After you have done your diagnosis you can always upgrade your firmware again later if the errors bug you too much but if the line is as stable then you should be fine.

Many thanks, Chrysalis, for your comments.

How do you know that the DSLAM is possibly providing only 25% of the power to the second 50% of the tones? I'm intrigued. Is that just a guess on your part, or is that something that we can actually measure? Is it, in fact, a fault condition, the likes of which might be worth reporting to our ISPs, for them to get BT to investigate?

Your second sentence doesn't scan too well but I think you're advocating that I try enabling Power Cutback and, provided the resultant sync speed stays above 3424K bps, that I then resync. Am I right? You're saying that it's worth a try and that if I'm lucky, it might improve things from tone 120 upward.

Re CRC errors, I suppose that whether you or anyone else regard 7000 such errors as being anything to worry about surely depends on the rate at which they accumulate? That 7000 piled up within just 2 days and CRCs continue to increase at the rate of 2000 - 3000 per day. The same is true of FECs, the numbers of which are now astronomical.

I definitely intend to go back to firmware 6.1.4.7 but only after I've gathered some more information from DMT and have hopefully found some way of reducing the rate at which my CRC errors accumulate, eg. by increasing the Target SNR yet further.

if you got 7000 in the space of a few seconds its a big problem, if its over the course of a day its a ant in a haystack. 7000 in one day is a very small % of your total packets passing over the line. Obviously people living 300m from the exchange are going to have next to 0 but you cant compare to that as your line is different. I would be more worried if the crc was as high as your fec but it isnt, interleaving is doing its job.

Now over the power cutback, what it does is actually turn of the tones above 128 (on my line) so they will just be disregarded so in other words as your tones below 128 are stronger you will in thoery have a lot less errors and may also get away with synching on a much lower margin so possibly clawing back some of the lost speed. The reason I have come up with 3424 is since right now you will be on a 3mbit bras profile and as long as you achieve 3424 kbit you will have no loss of speed at all. Of course if the synch takes you down on BRAS it will take you 3 days to recover again.

In reply to:

---

Now over the power cutback, what it does is actually turn of the tones above 128 (on my line) so they will just be disregarded...

---

I think this is a feature of DMT on the 546. When applied on my 780 (firmware 6.1.7.2) it is more like a proper power cutback, all the tones are still present and the down SNR improves slightly.

Edited by NormanB (Thu 21-Sep-06 07:29:53)

In reply to:

---

When applied on my 780 (firmware 6.1.7.2) it is more like a proper power cutback, all the tones are still present and the down SNR improves slightly.

---

Yeah but does the DS power go lower as well? If so by how much?

dmt doesnt give features its just a gui frontend for features already there.

if your snr goes up and the synch remains the same then that probably means its cutting power on the US and not the DS since cutting power weakens the signal.

Are you able to produce stats for your router whilst power cutback is enabled?

I still think its down to the dslam on how this reacts or possibly the firmware version, since mine is reacting differently to someone who has a almost identical chipset.

The 'power cutback' option in DMT is not what it says it is, simply because from a technical standpoint it makes no sense at all. Setting the first bit of Register 00 supposedly cuts back the DS Tx (sic) power, now this just goes against all logic, a true power cutback feature would offer a range of values to change to, not some arbitrary/random amount mysteriously reached via setting one single bit in a register. Also the author of DMT himself admits he doesn't know what the 'power cutback' option actually does.

yeah it does something that happens to reduce the power but I think the feature it enables isnt actually a power cutback. For me it enabled something dmt describes as splitterless mode, but when I googled splitterless adsl it isnt what I am experiencing, splitterless adsl is simply where the signals are split before they reach the premises allowing someone to plug their adsl into their socket without splitting the signal.

It would be interesting if someone else can enable power cutback and then produce 2 dmt screenshots one with and 1 without it so we have mroe to go on.

Well, it's Fri 22nd now and over the last few days I've experimented with pushing my target SNR progressively upward, in order to render fewer CRC errors. With the target set at 15dB by me during the morning, the line sync'ed at around 3.6M bps but, late in the evening, the SNR had dropped 0.5dB and the sync speed had also dropped, to just over 3M bps.

The error rate for CRCs, so far, looks much improved but, hey, I'm not celebrating just yet. I seem to be getting 1 - 2 CRC errors per minute, averaged out. I think that's between about a half and a third of the CRC rate I was getting at a target SNR of 11.5dB. So, a worthwhile improvement, but at the expense of considerably lower sync speed.

I think I'll re-flash back to the 6.1.4.7 firmware and put back my target SNR to 12dB or thereabouts.