Print

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

[kitz]

I'm about to split this topic because it contains an interesting discussion about the BToR DLM that can be discussed separately and not distract from Jamies main problem which is still ongoing.  So rather than have 2 discussions in this thread, each which distract from the other, its better to move and split them.

The discussion about BToR's DLM can be found here

--------
and whilst I have my admin hat on.. 

Only problem I've come across is when connected to LAN2, I've no internet connection? Do I need to set this up somewhere? 

This is a question I see again and again, and its one I fell for too...  Hence the reason why I did this which includes a diagram on how to set up the HG612 to get your line stats and may be helpful for others in future.

[Chrysalis]

ok keep the hg612 plugged in now, no resets.

You have no CRC which is good but the FEC is still too high in my opinion, there is a problem somewhere you need to resolve if you want optimal latency.

[jid]

ok keep the hg612 plugged in now, no resets.

You have no CRC which is good but the FEC is still too high in my opinion, there is a problem somewhere you need to resolve if you want optimal latency.

Latency is not something I desperately need, but something I knew wasn't quite right 

My ECI was always constantly plugged in so this will be the same

and whilst I have my admin hat on..

This is a question I see again and again, and its one I fell for too...  Hence the reason why I did this which includes a diagram on how to set up the HG612 to get your line stats and may be helpful for others in future.

I completely forgot the routers pages on the main site Kitz! Hope you are well? 

[burakkucat]

Do you still have the raw data which produced the 1343 hours montage, Jamie? If yes, would you be willing to share that data with an inquisitive b*cat, please?

I would like to take a close look at the precise frequencies of those spikes in the 200 - 300 tone region. 

I should do B*cat, could you tell me where I could find it?

Ah, now that is a question! As I don't use BGW I have not bothered to understand the mysteries of Bald_Eagle1's magnificent code, so we may need to wait for the pair of Eagles to return home . . . unless Colin can advise, please? 

Essentially it will be a text file which contains the output of "xdslcmd info --SNR", "xdslcmd info --QLN", "xdslcmd info --Hlog" and "xdslcmd info --Bits" command line invocations. It might have the word 'snapshot' in its name, which should also have the date/time (as numeric parameters) present. (A string somewhat similar to '20130907-1343', perhaps.)

[ColinS]

Do you still have the raw data which produced the 1343 hours montage, Jamie? If yes, would you be willing to share that data with an inquisitive b*cat, please?

I would like to take a close look at the precise frequencies of those spikes in the 200 - 300 tone region. 

I should do B*cat, could you tell me where I could find it?

Ah, now that is a question! As I don't use BGW I have not bothered to understand the mysteries of Bald_Eagle1's magnificent code, so we may need to wait for the pair of Eagles to return home . . . unless Colin can advise, please? 

I think what you need for B*Cat is the modem_stats.log file which is kept in the Ongoing_stats subdirectory.  However, keep in mind that this file is appended to every minute.  So the quickest way to safely grab it, is to copy it when about 15s past the min. (use the windows time clock).

On second thoughts, I think B*Cat wants to see the entire output of the bitloadings, QLN, Hlog & SNR for all 4096 bins.  In which case the file he needs is the Plink_<date_time>.log file, which is in a similarly named Current_stats_<date_time>-<cause> subdirectory of Current_stats.  And it seems the one he's interested in would have yesterday's date and a time of around 13:43.

HTH 

[Edit] An Excel template supplied by that most noble bird is attached.  It enables Excel users to directly import the raw data format into a more human-readable spreadsheet (with apologies to our , who I'm sure will have a clever way of achieving the same )

[burakkucat]

I think B*Cat wants to see the entire output of the bitloadings, QLN, Hlog & SNR for all 4096 bins.  In which case the file he needs is the Plink_<date_time>.log file, which is in a similarly named Current_stats_<date_time>-<cause> subdirectory of Current_stats.  And it seems the one he's interested in would have yesterday's date and a time of around 13:43.

HTH 

Yes, thank you, Colin. That appears to be correct. 

Something to do with 'plink' or 'plonk' . . . I'm never too sure what my avian colleague will come up with next! 

[jid]

Ok so I couldn't get back the file from where all the tones were loaded up however on one of the hourly stats today they've come back so the files are attached for those

I appreciate all of your help on trying to solve this one


After a day and a half uptime, it seems FEC errors are a problem:

Code: [Select]

Total time = 1 days 19 hours 37 min 57 sec
FEC: 31985 0
CRC: 0 0
ES: 0 0
SES: 0 0

[ColinS]

After a day and a half uptime, it seems FEC errors are a problem ...

FECs are not a problem Jamie in themselves, as they (bit errors) have all been recovered successfully.   If they weren't, you would be seeing non-zero CRC and ES counts.

Recall that your line has an interleaving depth of 2177.  This is to allow the recovery of bit errors caused by (impulse) noise bursts that might last as long as 9ms (the value of your INP).  Since every line has some noise some of the time, it is inevitable that you will get a non-zero FEC count.  This is the way it is supposed to work, and demonstrably here, it is.

Just to make you feel better, my INP is 3ms, and my interleaving depth is 1233, but my syncs rates are ~ double yours DS at ~78/20 (hence ~twice as many DS bits in the same time period).  Here are my FEC counts for the last 24hrs:
Previous 1 day time = 24 hours 0 sec
FEC:      607430      299
CRC:      28      72
ES:      5      65
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0

So, in a relative world, my line is much noisier (18x) than yours.
(Assuming I've got my sums right ...) My BER is ~900*10^-10, whereas your BER is ~50*10^-10. 
A reasonable target BER is ~1*10^-10.
[Edited to compare BERs]

I hope this helps.  Wouldn't want you to become one of the 'worried well'?! 

If there is anything to investigate, it is the source of this REIN (and the bit loadings that B*Cat is currently attending to, I trust  )  Perhaps a passing black sheep might offer the benefit of his experience with the former? 

[Black Sheep]

Excellently put there Colin, I understand it better myself now. 

For what it's worth, it depends on the severity of REIN as to how the DLM will act, but generally the depth of interleaving will be at it's highest, and the FEC's would be incrementing in their hundreds of thousands a second !! Sometimes the circuit can just about hold on to synch, but the service is severely restricted to its normal behaviours.
More often than not, the FEC's will be incrementing so fast the DLM can't cope and synch will lost after a period of time.

A high percentage of REIN faults I receive, are in fact due to poor quality wiring (from Exchange to premises). This results in any normal interference being acted upon by the DLM. I don't know if the OP has issues anywhere, as I'd have to be on-site to determine this conclusively, but going off the little bits I've read here, I would humbly suggest there isn't any REIN affecting his circuit.     

[ColinS]

Well, I'm sure he'll be glad to know that BS.  

[burakkucat]

(and the bit loadings that B*Cat is currently attending to, I trust  )

I've downloaded the ZIP format file and will take a look at the data to determine the frequencies of those rather prominent spikes . . . 

[jid]

FECs are not a problem Jamie in themselves, as they (bit errors) have all been recovered successfully.   If they weren't, you would be seeing non-zero CRC and ES counts.

Recall that your line has an interleaving depth of 2177.  This is to allow the recovery of bit errors caused by (impulse) noise bursts that might last as long as 9ms (the value of your INP).  Since every line has some noise some of the time, it is inevitable that you will get a non-zero FEC count.  This is the way it is supposed to work, and demonstrably here, it is.

Just to make you feel better, my INP is 3ms, and my interleaving depth is 1233, but my syncs rates are ~ double yours DS at ~78/20 (hence ~twice as many DS bits in the same time period).  Here are my FEC counts for the last 24hrs:
Previous 1 day time = 24 hours 0 sec
FEC:      607430      299
CRC:      28      72
ES:      5      65
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0

So, in a relative world, my line is much noisier (18x) than yours.
(Assuming I've got my sums right ...) My BER is ~900*10^-10, whereas your BER is ~50*10^-10. 
A reasonable target BER is ~1*10^-10.
[Edited to compare BERs]

I hope this helps.  Wouldn't want you to become one of the 'worried well'?! 

If there is anything to investigate, it is the source of this REIN (and the bit loadings that B*Cat is currently attending to, I trust  )  Perhaps a passing black sheep might offer the benefit of his experience with the former? 

I understand the concept of Fec's much better now thank you Colin I was under the impression that they were a bad thing!

My main concern is how this could effect my speed if I were to upgrade to a 80/20 package, its under consideration but would only be worth the money if the line could cope with it.

A high percentage of REIN faults I receive, are in fact due to poor quality wiring (from Exchange to premises). This results in any normal interference being acted upon by the DLM. I don't know if the OP has issues anywhere, as I'd have to be on-site to determine this conclusively, but going off the little bits I've read here, I would humbly suggest there isn't any REIN affecting his circuit.     

Thank you for your reply Black Sheep, I appreciate the response It is a good thing to know that its unlikely REIN is affecting the line. But my question is if it's not REIN, whats causing the line faults? Poor quality wiring in BT's network?

(and the bit loadings that B*Cat is currently attending to, I trust  )

I've downloaded the ZIP format file and will take a look at the data to determine the frequencies of those rather prominent spikes . . . 

Thank you, I shall await your results

[ColinS]

My main concern is how this could effect my speed if I were to upgrade to a 80/20 package, its under consideration but would only be worth the money if the line could cope with it.

Well, your line is noisy. 50x worse than desirable...  but then mine is 18x worse than that! It's the noise that's the bad thing.  FEC is a helpful technique in a less-than-ideal world.

Just what sort of rate would make it value-for-money for you is only something you can ultimately decide upon for yourself.  Personally, I would say you will get a significant uplift from your current 40/2 service, but that you will not, on those current line parameters, achieve the full 80/20 service.

I don't know how to predict what you might get, other than to look at our respective overheads due to the helpful error correction required.  My 20% overhead results in a loss of ~2Mb/s or ~2.5% of the headline product DS rate.  So, if these things were linearly related (which I doubt), then your 35% might result in reduction of ~3.5Mb/s DS or possibly quite a bit more, who knows?

There is a graph in here http://www.broadcom.com/collateral/wp/XDSL-WP101-R.pdf - Fig. 1 on page 4 - that might give you some sort of rough relative guide, baring in mind that on your line INP=9, and L=15425 (or 15.425*10^+3)
[Edit] but be warned it is illustrating the effect on ADSL2+, not VDSL2.

[Chrysalis]

I think you guys have played down his issue.

Yes right now there isnt a major impact on his line, he doesnt care about the latency from interleaving and is no CRC errors but the fact remains he has a line that has a huge snr margin that DLM has decided needs interleaving, that suggests if he was to upgrade to 80/20 he is heading for trouble.

Colin I admit I am confused as to how you calculated your line has more noise, I probably need to reread your post a few times to understand how you calculated it but did you take into account your comparitive levels of snr margin?  I would hazard a guess if your line had 17db to spare you would not be interleaved.

[ColinS]

I think you guys have played down his issue.

I don't think anyone is playing anything down.

Yes right now there isnt a major impact on his line, he doesnt care about the latency from interleaving and is no CRC errors but the fact remains he has a line that has a huge snr margin that DLM has decided needs interleaving, that suggests if he was to upgrade to 80/20 he is heading for trouble.

Well if you could be a little more specific about what trouble you anticipate, and what evidence you have for that, we all might be able to follow your concerns a little more easily....

Nevertheless, even in my own very first post I said quite clearly

However, as to achieving the full whack on 80/20, I would suggest it's debateable.  The excess achievable over the 80/20 product banding will not help him in that respect, and since the overhead of that Interleaving depth is R/D, which in his case is 16/46=~35%, I doubt very much that he would get the full 80Mb/s DS.

and I think I repeated that in the post just below yours.

Colin I admit I am confused as to how you calculated your line has more noise, I probably need to reread your post a few times to understand how you calculated it but did you take into account your comparitive levels of snr margin?  I would hazard a guess if your line had 17db to spare you would not be interleaved.

By calculating the BER, and by observation that his QLN floor is on average 8dB better than mine (ignoring specific spikes).  And sorry, I think the application of INP and Interleaving on my line has got nothing to do with my spare SNR, and everything to do with very occasional but very, very large impulsive-like noise spikes, albeit of very short duration.  What margin do you suggest would be sufficient to survive a peak noise burst that gave rise to an instantaneous FEC rate of 3.5Million/min over a period of 2-3mins without interleaving?