Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Bald_Eagle1 on October 26, 2013, 06:58:43 PM
-
I have attached a montage showing my connection stats for the latest 3 days.
Some changes since the firmware update (17th Ocober for my HG612) are clear to see.
Namely DS bitswaps, DS attenuation, DS SNRM (slightly) & DS/US Power.
Are you all seeing similar changes?
The new firmware may just be reporting connection stats 'differently', but I'd be interested to know if it has changed for everyone.
I have also attached before & after SNR graphs.
I have seen on at least one other connection a similar effect on SNR at the top end of the available tones.
I forced a modem resync today, just in case a fresh connection changed anything, but it didn't.
Just for info, quite a few of the top end tones are reporting zero for SNR.
Here's a snippet from the Plink log:-
1726 6.6250
1727 5.0000
1728 5.0000
1729 6.8125
1730 7.9375
1731 5.1875
1732 0.0000
1733 8.1875
1734 0.0000
1735 0.0000
1736 0.0000
1737 8.1250
1738 7.4375
1739 6.8750
1740 0.0000
1741 8.0625
1742 8.5000
1743 8.7500
1744 8.8125
1745 8.8125
1746 8.6875
1747 8.4375
-
I can was going to force a re-sync tomorrow or Monday if the DS interleaving went down but it maybe resigned to 1215 and looking also at you DS interleaving it has increased since the 17th of October.
The D1 signal attenuation is 2db higher than it was before update as line attenuation used to be matched and SNR DS now seems to take a nose dive in the evenings to 4.9db before it was 5.4db for evenings
don't see any zeros in thoses tones
1726 5.0000
1727 4.8750
1728 5.0625
1729 6.9375
1730 9.7500
1731 12.1250
1732 13.5000
1733 14.6875
1734 15.5625
1735 16.2500
1736 16.1875
1737 17.1250
1738 17.1875
1739 16.0625
1740 9.5625
1741 14.4375
1742 17.7500
1743 18.0000
1744 17.7500
1745 17.3750
1746 16.2500
1747 15.4375
-
Perhaps your connection is able to use higher tones in the D2 band, up to tone 1961 from a Huawei DSLAM?
My connection discovers all the tones, but can only use some of them.
-
Perhaps your connection is able to use higher tones in the D2 band, up to tone 1961 from a Huawei DSLAM?
My connection discovers all the tones, but can only use some of them.
I have current graphs before update and the D3 band showed as 0.1 now it shows as 82.9 after update.
-
What does your 'snapshot' SNR graph look like?
BTW, I'll be uploading some amended programs shortly.
They (hopefully) speed up the logging process during SCHEDULED & RESYNC events, thus avoiding the data harvesting programs potentially remaining open into the next minute's harvest.
Also, the snapshot montages had grown following the firmware updates to a size too large to attach to messages in this forum.
That's now been addressed in the updated programs.
-
What does your 'snapshot' SNR graph look like?
BTW, I'll be uploading some amended programs shortly.
They (hopefully) speed up the logging process during SCHEDULED & RESYNC events, thus avoiding the data harvesting programs potentially remaining open into the next minute's harvest.
Also, the snapshot montages had grown following the firmware updates to a size too large to attach to messages in this forum.
That's now been addressed in the updated programs.
SNR Graph uploaded and look forward to amended programs
-
They have been uploaded here:-
http://forum.kitz.co.uk/index.php?topic=13051.msg247983#msg247983
-
Just noticed a reSYNC log in the current stats looks like it re-sync'd last friday 18th of October so I'll leave it for another week before I force a sync (turn off HG612 for 30 minutes) ;D
PS what happens to Modems time when the clocks go back at 2AM ?
-
PS what happens to Modems time when the clocks go back at 2AM ?
This is what happened to the logging at my end:-
27/10/2013 00:59 20721 4561
27/10/2013 01:00 20721 4561
27/10/2013 01:01 20721 4561
27/10/2013 01:02 20721 4561
27/10/2013 01:03 20721 4561
27/10/2013 01:04 20721 4561
27/10/2013 01:05 20721 4561
27/10/2013 01:06 20721 4561
27/10/2013 01:07 20721 4561
27/10/2013 01:08 20721 4561
27/10/2013 01:00 20721 4561
27/10/2013 02:00 20721 4561
27/10/2013 02:01 20721 4561
27/10/2013 02:02 20721 4561
27/10/2013 02:03 20721 4561
27/10/2013 02:04 20721 4561
Looking through the Windows Scheduled Tasks log, it kept trying to run the task but failed until 02:00 when everything came back on track.
As the tasks didn't actually run again until 02:00, there were no leftover ONGOING_ISRUNNING files or 'stuck' processes.
The effect can be seen in the attached montage.
Checking the modem's time via telnet this morning (typing "date" at the Busybox prompt - without the quotes), as expected the time was one hour fast as on VDSL2 connection's the modem's date/time aren't synchronised with any time servers.
The modem's time doesn't seem to be used for much anyway (other than date/time stamping events that we can no longer see now that we don't have GUI access).
Regardless, I reset the modem's time via my "SET_HG612_DATE_AND_TIME.exe" & rechchecked via telnet that it had been reset.
If you choose to do that, it's best to do it as close as possible to on the minute for it to more or less match the PC's system time.
-
Mine got to 1:14, before it stopped, then picked up again at 02:00
But I did have two isrunning files for 01:59, here's the section from the error log.
27/10/2013 01:59:37.067 - [ IN HG612_stats.EXE ] - Start of 1 minute sampling - delayed by user setting of 0 seconds
27/10/2013 01:59:37.314 - HG612_current_stats.exe was NOT running
27/10/2013 01:59:37.314 - Temp File ONGOING-ISRUNNING-015937-314.TXT was created
27/10/2013 01:59:37.788 - *** Now in exit_2_instances as there are 2 instances of HG612_stats.exe running. Status = 1.
27/10/2013 01:59:37.826 - *** In exit_2_instances - Closing ERROR.LOG. Status = 1.
27/10/2013 01:59:36.955 - [ IN HG612_stats.EXE ] - Start of 1 minute sampling - delayed by user setting of 0 seconds
27/10/2013 01:59:37.311 - HG612_current_stats.exe was NOT running
27/10/2013 01:59:37.311 - Temp File ONGOING-ISRUNNING-015937-311.TXT was created
27/10/2013 01:59:37.815 - *** Now in exit_2_instances as there are 2 instances of HG612_stats.exe running. Status = 1.
27/10/2013 01:59:37.837 - *** In exit_2_instances - Closing ERROR.LOG. Status = 1.
-
I have not been recording on-going stats, but I can report that, after 14 days of heavy DS interleaving on my line (INP 8, Delay 16, D 1557, I 64, DS sync 37126), DLM this morning changed it back to the pre-update levels (INP 3, Delay 8, D 701, I 74, DS sync 39998 [top of band]). Retrain Reason was again 1, which seems to be the code for a DLM resync with the new firmware.
I think this perhaps emphasises the importance of allowing time for the new firmware and MSAN band plan to "bed in", before jumping to conclusions about relative performance.
Latest snapshot stats and Plink log attached. Stats pre- and post- the first band plan change attached to http://forum.kitz.co.uk/index.php?topic=12956.msg244739#msg244739 (http://forum.kitz.co.uk/index.php?topic=12956.msg244739#msg244739); pre- and post- the update attached to http://forum.kitz.co.uk/index.php?topic=13041.msg246175#msg246175 (http://forum.kitz.co.uk/index.php?topic=13041.msg246175#msg246175); and post- the first resync attached to http://forum.kitz.co.uk/index.php?topic=12956.msg246513#msg246513 (http://forum.kitz.co.uk/index.php?topic=12956.msg246513#msg246513).
For my line I am hesitant about attributing changes in the SNR or bitloading graphs to the firmware or band plan changes. I find these graphs vary considerably anyway with the time of day and also with the time since the last resync, and my snapshots were taken manually at random times of day. However, a curiosity I have noticed is that, since the update, the total US bitloading (U0+U1) appears visually, on the graphs, to be considerably less. This remains the impression even looking at the HI-RES graphs, which show the individual "bad" tones with low or no loading. Yet the total US bits loaded count (excluding the shared bits pre-update) is only a few percent less, and the US sync rate, max attainable rate and SNRM are little changed. There has never been US INP/interleaving applied.
-
I have not been recording on-going stats, but I can report that, after 14 days of heavy DS interleaving on my line (INP 8, Delay 16, D 1557, I 64, DS sync 37126), DLM this morning changed it back to the pre-update levels (INP 3, Delay 8, D 701, I 74, DS sync 39998 [top of band]). Retrain Reason was again 1, which seems to be the code for a DLM resync with the new firmware.
That's what I am hopeing will happen at my end and have one more day to go "25 hours"
-
For my line I am hesitant about attributing changes in the SNR or bitloading graphs to the firmware or band plan changes. I find these graphs vary considerably anyway with the time of day and also with the time since the last resync, and my snapshots were taken manually at random times of day. However, a curiosity I have noticed is that, since the update, the total US bitloading (U0+U1) appears visually, on the graphs, to be considerably less. This remains the impression even looking at the HI-RES graphs, which show the individual "bad" tones with low or no loading. Yet the total US bits loaded count (excluding the shared bits pre-update) is only a few percent less, and the US sync rate, max attainable rate and SNRM are little changed. There has never been US INP/interleaving applied.
My snapshot graphs are usually scheduled at 06:00 (a quiet time), 14:00 (peak for SNRM) & 22:00 (a relatively 'busy' time).
Recently, while i have been testing amended programs, I have scheduled snapshot logging/graphing every hour.
Yes, there are definitely differences from hour to hour, but the pattern remains the same.
We firstly saw Band plan changes, then the HG612 firmware updates.
I suspect that we may well have been experiencing 'issues' prior to the changes, but the firmware wasn't detecting them adeqautely.
If you recall, asbo's 'new' BLOB affected the raw data obtained from the HG612 (e.g. bitloading ceased to be reported dynamically).
Maybe the new BLOB did allow the HG612 to operate 'differently' or maybe it just reported the data differently.
The recently updated firmware has no doubt been installed to make 'best' use of the revised band plans which makes my connection 'appear' to be performing slightly differently.
Just for reference, I have attached a high res copy of a very recent bitloading graph, along with the low res SNR graph for the same period.
Prior to the band plan/firmware updates, I didn't see quite the same 'issue' at the higher end of my available DS tones.
-
I have seen on at least one other connection a similar effect on SNR at the top end of the available tones.
I forced a modem resync today, just in case a fresh connection changed anything, but it didn't.
Just for info, quite a few of the top end tones are reporting zero for SNR.
Paul - Those 0's in the final 'end of line range' tones arent that unusual.
Admittedly Ive mostly seen it before on adsl/adsl2+ lines, but the DMT theory is still exactly the same for VDSL, so it will happen on fttc lines too.
During the channel analysis at sync time, if a bin doesnt have sufficient SNR to load any bits, then they are marked as unusable.. and thats where you see the 0's.
Now there may be some bins either side, that scrape through with just enough SNRm to load one bit, so the SNR values will show.
The reality is those 0's you see arent really meaning 0dB SNR, just that they have been marked as unusable by the modem during the sync process so show as 0.
-
Having looked at your bitloading graph Im pretty certain this will be the case with your line.
The firmware upgrade may have very slightly boosted your SNR in tones 1550 and above. Your SNR seems a bit erratic and mushy in that area not following a smooth tail off ie 5dB at tone 1728 and 8dB at 1747. Again not that unusual when a line reaches its tail end tones, but suggesting something a wee bit EMI like or even fext in that area on your line.
Whats happened during channel analysis is your modems gone something like
Tone 1731 6.1dB - Pass - yes I can use you - record the SNR
Tone 1732 5.9dB - Fail - nope I cant use you - mark as 0
Obviously those figures are made up and the SNR you see for tones wont be the same as during channel analysis.
I dont know exactly what the 'pass' mark will be because theres a floor limit also affected by the target SNR and theres some sort of algorithm that does this. But it will likely be somewhere around the 6dB mark. If that lines been up a while and doing bitswap, then power levels may also have changed which will also change the SNR.
Its just that since the upgrade, your tones in the region of 1726-1747 are hovering either side of the 'x' figure.
For simplicity just say x = 6dB. Below 6db and it will display as 0, and anything above will show.
-
What seemed to happen at times with my line (at least before the upgrade) is that various tones that were initially loaded would get bitswapped down to zero over a period of days and weeks, presumably because they experienced occasional bursts of interference. This increased bitloading on the remaining tones, so gradually reducing DS SNRM, which eventually levelled out at about 2-3dB and remained stable for months. A resync would bring the "blackballed" tones temporarily back into use, so restoring 6dB SNRM without a loss in sync speed.
Too early to say if this will still occur with the new firmware.
-
I am quite shocked BE1 when I think back a year ago your current stats looked very similar to my own, apart from your crosstalk has anything been changed in your premises ?
-
I am quite shocked BE1 when I think back a year ago your current stats looked very similar to my own, apart from your crosstalk has anything been changed in your premises ?
Nope. Nothing's changed here.
There has been a gradual decline Since December 2012, being put down to increased crosstalk.
However, the point I was making was that things are reported 'differently' via the new firmware/band plans.
It may be physical changes due to one or both of them or it could just be that the new firmware reports matters more accurately? (certainly differently) for my connection.
These differnces do coincide exactly with when my HG612's firmware was updated.
-
What seemed to happen at times with my line (at least before the upgrade) is that various tones that were initially loaded would get bitswapped down to zero over a period of days and weeks, presumably because they experienced occasional bursts of interference. This increased bitloading on the remaining tones, so gradually reducing DS SNRM, which eventually levelled out at about 2-3dB and remained stable for months. A resync would bring the "blackballed" tones temporarily back into use, so restoring 6dB SNRM without a loss in sync speed.
Too early to say if this will still occur with the new firmware.
Yes that is another explanation, you are quite correct in that after a line has been up for a while bitswapping at the tail end goes to zero in almost alternate tones. You will usually find that tx power gets increased at this stage too. However, there should still be some SNR showing for the tones which arent bit-loaded, even if it is low.
I could be wrong, but with it happening to BE on a fresh resync and many of those tones showing as 0dB (real) SNR I suspect its more to do with the floor level & tones being disregarded by the router as unusable.
-
Hi,
For information I show my stats before and after the firmware update. The pre graphs are for 24 hours and the post graphs for 12 hours (my updated happened on the night of the 25/26th) - unfortunately I'm now getting some strange graphs if I try and plot over 12 hours - however this is probably down to me running some beta programs and I've now got my kickers in a bit of a twist regarding version control. I'm awaiting the next "official" release of the stats programs and will then a clean install and start from scratch. Any idea when that might be?
I was obviously running the unlocked firmware from Asbokid before the BT update but had disabled the BT agent. There had been a previous attempt by BT agent to update the modem which seemed to have failed. I also lost both telnet and GUI access. So I reflashed with the unlocked firmware but this time disabled BT agent. Also following the clue given by Howlingwolf's comment in another thread regarding changes to the default config file I then imply turned the modem led lights out via the GUI, logged out, then logged back in and enabled the led lights. Hopefully this was enough to change the default config. This time I also disabled HGstats data harvesting.
Subsequently I woke the BT Agent up and the modem was updated with the new BT firmware the following evening - this time telnet access remained. I made no other changes other than firing up HGstats to restart logging and graphing.
To my untutored eye there is not much difference to the before and after graphs, although US bit swapping does look slightly different.
I also attach parameter data from before and after. As you can see the band plan has changed to get rid of the US/DS overlap and some other minor tweaks. DS speed has improved somewhat.
Regards BBN
-
Well, this firmware was rather big for me.
Before hand I would get 0 Bitswaps for hours on end, since the firmware update I'm now having 54 bitswaps a minute for hours on end.
I believe I have the same as you two...
-
I also attach parameter data from before and after. As you can see the band plan has changed to get rid of the US/DS overlap and some other minor tweaks. DS speed has improved somewhat.
Something looks a bit odd there.
Neither of those pbParams band plans that you posted look like they are from a HG612 with fully updated firmware.
This is what most of us have seen that are connected to Huawei DSLAMS:-
This was the previous band plan from ages ago:-
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
This is the intermediate band plan from a HG612 that hasn't had its firmware updated:-
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3971)
This is the band plan from a fully updated HG612:-
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
-
Bald Eagle,
See attached.... I think that is the version of the BT Update?
Regards
-
It is the new firmware version, but your band plans don't match what others are seeing, so it looks like only a 'partial' update?
-
BE.....
I'm now way above my pay grade.
I've just interrogated the modem again, and can confirm that the band plan is the still the same as that shown (for the post update position) in my previous post.
So I'm at a loss.
Maybe I'm just special? :lol:
Edit: I disabled BT agent after the BT update. Should I wake it up again if the modem has only had a "partial" update?
-
Maybe I'm just special? :lol:
Edit: I disabled BT agent after the BT update. Should I wake it up again if the modem has only had a "partial" update?
That can only be your own decision.
I don't have a great connection & the slightest thing seems to upset it.
However, as I have never attempted to block anything, I thought I'd at least try out the firmware update for a while.
-
<snip>
Checking the modem's time via telnet this morning (typing "date" at the Busybox prompt - without the quotes), as expected the time was one hour fast as on VDSL2 connection's the modem's date/time aren't synchronised with any time servers.
The modem's time doesn't seem to be used for much anyway (other than date/time stamping events that we can no longer see now that we don't have GUI access).
<snip>
Not having a powered-up HG612 within paw-reach I am unable to confirm the following . . . so please test and see, yourself.
- Establish a telnet connection to the HG612
- Log in as usual
- At the ATP> prompt, issue a display log command
I'm sure Asbokid has documented quite a few of the commands that are applicable at the ATP> prompt . . . but I just can't remember exactly where! ::)
-
What seemed to happen at times with my line (at least before the upgrade) is that various tones that were initially loaded would get bitswapped down to zero over a period of days and weeks, presumably because they experienced occasional bursts of interference. This increased bitloading on the remaining tones, so gradually reducing DS SNRM, which eventually levelled out at about 2-3dB and remained stable for months. A resync would bring the "blackballed" tones temporarily back into use, so restoring 6dB SNRM without a loss in sync speed.
Too early to say if this will still occur with the new firmware.
I used to see that all the time on adsl. Its probably a common things on lines with weak snr, and especially when is interference.
I think bitloading if it ever turns a tone off, it then stays off until a new sync event. So as you said the overall snrm goes down.
-
What seemed to happen at times with my line (at least before the upgrade) is that various tones that were initially loaded would get bitswapped down to zero over a period of days and weeks, presumably because they experienced occasional bursts of interference. This increased bitloading on the remaining tones, so gradually reducing DS SNRM, which eventually levelled out at about 2-3dB and remained stable for months. A resync would bring the "blackballed" tones temporarily back into use, so restoring 6dB SNRM without a loss in sync speed.
Too early to say if this will still occur with the new firmware.
Yes that is another explanation, you are quite correct in that after a line has been up for a while bitswapping at the tail end goes to zero in almost alternate tones. You will usually find that tx power gets increased at this stage too. However, there should still be some SNR showing for the tones which arent bit-loaded, even if it is low.
I could be wrong, but with it happening to BE on a fresh resync and many of those tones showing as 0dB (real) SNR I suspect its more to do with the floor level & tones being disregarded by the router as unusable.
the bitloading adapts to available snr kitz.
in my adsl days generally my modem would mark the tone unuseable once bitloading hit 0, if I ever seen a used tone hit 0 it became unused until a fresh sync event.
I dont know if vdsl is still the same but on adsl 3db of snr was required per bitloading on a tone, adsl1 had a min bitloading of 2 so 6db of snr was required to make it useable, with 45db of snr needed for a 15 bitloading on the tone, I remember in my ukonline days adsl2 would squeeze some extra sync with half a dozen tones using 1 bitloading with their 3db of snr but within a few hours they would all be disabled by bitswapping as far too fragile :D. Once I seen tones get disabled their snrm would always report 0 as if the modem turned them off completely.
Obviously bear in mind the target snrm had to be factored in also, so if a 6db target noise margin was set then on adsl1 12db of snr was needed to make a tone useable and 9db on adsl2.
-
<snip>
I think bitloading if it ever turns a tone off, it then stays off until a new sync event. So as you said the overall snrm goes down.
b*cat nods in agreement.
-
Can confirm my Interleaving has dropped from 1215 to 591 early this morning, also with a higher sync thats 14 days after updates came in, but can my line hold this sync before the DLM raises the Interleaving Depth again :-\
-
It is the new firmware version, but your band plans don't match what others are seeing, so it looks like only a 'partial' update?
My cabinet still hasn't updated (ECI) though my modem was a couple of weeks ago.
-
newtonstar post your --stats output and I will give an opinion if DLM will react.
-
hhmm, I would of thought you would have more download speed than that, my line is virtually the same as yours, but im syncing at 51meg down and 8meg up, surley 21.8 attenuation isn't that much of a difference to 24
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 8548 Kbps, Downstream rate = 58100 Kbps
Bearer: 0, Upstream rate = 8637 Kbps, Downstream rate = 51911 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.6 6.2
Attn(dB): 21.8 0.0
Pwr(dBm): 12.2 6.3
VDSL2 framing
Bearer 0
MSGc: 18 52
B: 51 237
M: 1 1
T: 64 33
R: 12 16
S: 0.0319 0.8751
L: 16064 2322
D: 1015 1
I: 64 127
N: 64 254
Counters
Bearer 0
OHF: 8631172 62193
OHFErr: 48 73
RS: 2209456302 3465978
RSCorr: 210451 97
RSUnCorr: 606 0
Bearer 0
HEC: 84 0
OCD: 3 0
LCD: 3 0
Total Cells: 1764136143 0
Data Cells: 7091186 0
Drop Cells: 0
Bit Errors: 0 0
ES: 14 65
SES: 0 0
UAS: 25 25
AS: 17675
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 2.04 14.49
OR: 93.75 32.00
AgR: 52004.85 8669.06
Bitswap: 14479/14480 1842/1844
Total time = 4 hours 56 min 0 sec
FEC: 211583 97
CRC: 48 73
ES: 14 65
SES: 0 0
UAS: 25 25
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 11 min 0 sec
FEC: 17048 0
CRC: 0 2
ES: 0 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 21329 1
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 4 hours 56 min 0 sec
FEC: 211583 97
CRC: 48 73
ES: 14 65
SES: 0 0
UAS: 25 25
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 4 hours 55 min 35 sec
FEC: 211583 97
CRC: 48 73
ES: 14 65
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
newtonstar post your --stats output and I will give an opinion if DLM will react.
Which one the current stats or ongoing as i don't have a full 24 hour graph as i am frugal with electric bills :blush: so heres the current stats.
hhmm, I would of thought you would have more download speed than that
I am about 800 meters from the cab so that could be the reason for the Max attainable DS of 35000 and don't think I can use the higher tones in the D3 band.
-
<snip> and 8meg up, surley 21.8 attenuation isn't that much of a difference to 24
Please remember the units, dB. A logarithmic ration. So although ( 24 - 21.8 ) is indeed 2.2, what does that signify as a logarithm (base 10)?
About a factor of three in absolute values, if I remember correctly. :-\
-
<snip> and 8meg up, surley 21.8 attenuation isn't that much of a difference to 24
Please remember the units, dB. A logarithmic ration. So although ( 24 - 21.8 ) is indeed 2.2, what does that signify as a logarithm (base 10)?
About a factor of three in absolute values, if I remember correctly. :-\
Hello BC look I thinking of turning off the modem as it's looking like errored seconds are rising and it seems like my line only has a 2 day window before the interleaving is increased by Miss DLM
i'll upload a monty and wait for reply.
for some reason my line does not like to sync to anything above 29000mbps and when it gets to the 30000mbps the DLM hits me why has this been going on since day one on FTTC >:(
-
newtonstar post your --stats output and I will give an opinion if DLM will react.
Which one the current stats or ongoing as i don't have a full 24 hour graph as i am frugal with electric bills :blush: so heres the current stats.
hhmm, I would of thought you would have more download speed than that
I am about 800 meters from the cab so that could be the reason for the Max attainable DS of 35000 and don't think I can use the higher tones in the D3 band.
do as boe323 did, since BE's tool ddoesnt run it.
login to the modem via telnet.
run
xdslcmd info --stats
paste the output.
-
do as boe323 did, since BE's tool ddoesnt run it.
login to the modem via telnet.
run
xdslcmd info --stats
paste the output.
You meen the Plink log from BE1 current stats ;)
-
<snip>
. . . to anything above 29000mbps and when it gets to the 30000mbps . . .
<snip>
Fur rises! Units! >:(
Either 29 Mbps and 30 Mbps or 29000 kbps and 30000 kbps. :P
Having stated that, the fur settles back and b*cat plods off to attend to his food bowl. :yum:
-
<snip>
. . . to anything above 29000mbps and when it gets to the 30000mbps . . .
<snip>
Fur rises! Units! >:(
Either 29 Mbps and 30 Mbps or 29000 kbps and 30000 kbps. :P
Having stated that, the fur settles back and b*cat plods off to attend to his food bowl. :yum:
Yeah BC 29000kbps and 30000kbps now go and give that scratch pole a good seeing to :D
PS BC now have another kitten 3 months old and don't get to much sleep these nights of all the kittens we had this one is mad and look forward to neuter day :no:
-
<snip>
. . . to anything above 29000mbps and when it gets to the 30000mbps . . .
<snip>
Fur rises! Units! >:(
Either 29 Mbps and 30 Mbps or 29000 kbps and 30000 kbps. :P
Having stated that, the fur settles back and b*cat plods off to attend to his food bowl. :yum:
yeah that has it.
your FEC is in the millions and over 7k CRC in 24 hours, doesnt look great. Although not necessarily aweful either.
You got an older plink from the higher interleaving?
-
<snip>
. . . to anything above 29000mbps and when it gets to the 30000mbps . . .
<snip>
Fur rises! Units! >:(
Either 29 Mbps and 30 Mbps or 29000 kbps and 30000 kbps. :P
Having stated that, the fur settles back and b*cat plods off to attend to his food bowl. :yum:
yeah that has it.
your FEC is in the millions and over 7k CRC in 24 hours, doesnt look great. Although not necessarily aweful either.
You got an older plink from the higher interleaving?
The DS errored seconds was high at 500 per hour normally I would see 368 in 10 days so turned off HG612 for 30 minutes and lost some sync 30221kbps down to 28670 kbps but DS SNR has increased to 6.4db which is good for the evenings.
So what seems to be the problem is the retrain reason 1 happens at 4am thats the quiet time for ADSL and FTTC and come the evening the SNR starts to lower below 5db and attainable line rate also starts to lower which in turn starts to give me alot or errors, in a nutshell my resync should be at 6pm not 4am :(
EDIT: the Bandplan updates have made no difference that I can see on my line after 14 days ;)
Edit the upload does seem to have increased since bandplan changes.
-
The DS errored seconds was high at 500 per hour normally I would see 368 in 10 days so turned off HG612 for 30 minutes and lost some sync 30221kbps down to 28670 kbps but DS SNR has increased to 6.4db which is good for the evenings.
So what seems to be the problem is the retrain reason 1 happens at 4am thats the quiet time for ADSL and FTTC and come the evening the SNR starts to lower below 5db and attainable line rate also starts to lower which in turn starts to give me alot or errors, in a nutshell my resync should be at 6pm not 4am :(
EDIT: the Bandplan updates have made no difference that I can see on my line after 14 days ;)
Perhaps a bit extreme, and assuming if DLM re-syncs you that the setting persists (I imagine it would), you could try capping your sync rate (only available on the very recent HG612 firmware).
For example: xdslcmd configure1 --maxDataRate 26000 5500 31500
The above example would re-sync your connection at a capped downstream rate of approximately 26,000kbps and a capped upstream rate of approximately 5,500kbps. This should give you some SNR breathing room and as such help reduce the errors. I tested this last night (the --maxDataRate) and it worked on my FTTC connection. Presumably the setting would last until a reboot or if you did xdslcmd configure --xyzparameterhere. Note that xdslcmd configure1 --xyzparameterhere doesn't cause all other unspecified parameters to go back to their current/default setting.
Another setting I've not had an opportunity to try is --Ginp, I'm hoping someone else on this forum can test that on a VDSL2 connection to see if my theory about xdslcmd configure1 --Ginp 0x0 can disable/unsupport the capability of having impulse noise protection on the downstream and upstream.
-
Perhaps a bit extreme, and assuming if DLM re-syncs you that the setting persists (I imagine it would), you could try capping your sync rate (only available on the very recent HG612 firmware).
For example: xdslcmd configure1 --maxDataRate 26000 5500 31500
Thankyou thats is extreme and if it works at least I have more control over my line, as the DLM/DSLAM/MSAN seems to think my line can go faster but then says sorry you can't and still wondering if the DATA socket is confusing it's electronic brain as somehow I am loosing 2000kbps inside my premises.
-
would this command be similar to no interleave if it disables inp?, xdslcmd configure1 --Ginp 0x0 , that's a thought, is there a new command to force fastpath, like there is on on fritzbox?, maybe its possible now the dlm as been updated.
-
would this command be similar to no interleave if it disables inp?, xdslcmd configure1 --Ginp 0x0 , that's a thought, is there a new command to force fastpath, like there is on on fritzbox?, maybe its possible now the dlm as been updated.
That would be my guess, however I don't know for sure even if that's the case, or whether the DSLAM can override this if it is the case.
-
now have another kitten 3 months old and don't get to much sleep these nights of all the kittens we had this one is mad and look forward to neuter day :no:
Purrfect. :D
. . . somehow I am loosing 2000kbps inside my premises.
An excess of the new kitteh's frolics, perhaps? :angel:
-
now have another kitten 3 months old and don't get to much sleep these nights of all the kittens we had this one is mad and look forward to neuter day :no:
Purrfect. :D
. . . somehow I am loosing 2000kbps inside my premises.
An excess of the new kitteh's frolics, perhaps? :angel:
:tongue: i've checked around the master socket for any kitty mositure :o and :no: thank god.
I let him out for 30 minutes in the morning and afternoon but still he uses the litter tray and there is plenty of places to go in my garden :doh:
-
Kind of getting fed up here as a retrain reason 1 came in again a 5:am this morning and increased the Interleaving again from 561 to 1193 all in less than 13 hours, this definitely has something to do with these BandPlan changes >:( >:( >:(
Thats 3 Interleaving changes in two weeks, now have to wait another 14 days :'(
all very confusing indeed.
-
I would now leave your connection alone, don't turn off or resync, I suspect it resynced earlier because of request sent during the day. I could be wrong, if you where playing with settings etc and the modem didn't resync then it will resync during those hours, but what do I know, im a noob, I recon though if you leave it be now, it will get better.
-
I would now leave your connection alone, don't turn off or resync, I suspect it resynced earlier because of request sent during the day. I could be wrong, if you where playing with settings etc and the modem didn't resync then it will resync during those hours, but what do I know, im a noob, I recon though if you leave it be now, it will get better.
99% of the time I leave the modem to do its own thing maybe should have left it alone last night but kind of new the out come as errors ranked up during the evening and that's was before unplugging the modem, its nothing major no massive loss of speed, it's just not staying consistant since the 12th of october (UPDATE DAY)
-
I also got a resync this morning at 0512 according to the HG612 stats program, but I haven't touched the modem in over 2 months. So now retrain reason code 1.
Only thing that has changed is the addition of a Samknows Whitebox.
One thing I have noticed is the max attainable has dropped closer to my sync speed.
Attached a couple of charts, before the BT update and after and the latest resync.
-
Hmmm, def everyones loosing actual attainable rate for up and down after the update
-
the bitloading adapts to available snr kitz.
Yes agreed (http://www.kitz.co.uk/adsl/adsl_technology.htm#bit_swapping) - I knows that :D.
Sorry if I didnt explain it well what I meant about about the tx power.
One of the parameters that can occur during the bitswap process is the gain in power, in all of the tones can be redistributed slightly to try and increase the overall SNR. This gives a tad more overhead for the other tones to be able to load an extra bit(s) which it may not have been able to do during the original sync process. This is why during a fresh sync your power may be at 18dBm, but after a while it may show as say 19 or 20dBm. Im not quite sure how else to phrase what I meant. :/
The bitwapping process can adjust bits and power. These 2 aspects are called bit-swap and gain-swap.
>> in my adsl days generally my modem would mark the tone unuseable once bitloading hit 0, if I ever seen a used tone hit 0 it became unused until a fresh sync event.
If the SNRm does get so low that 0 bits are loaded, yes the router can then mark that tone as unused.
That tone wont become available again until a fresh resync and the SNRm will be reported as 0dB as you say.
However, some routers do still continue to show the 'real' SNR even if its too low too load any bits.
I don't know if the HG612 is one of them or not. BE gave his SNR (not SNRm) figures.
>> I dont know if vdsl is still the same but on adsl 3db of snr was required per bitloading on a tone, adsl1 had a min bitloading of 2 so 6db of snr was required to make it useable, with 45db of snr needed for a 15 bitloading on the tone,
Agreed again (http://www.kitz.co.uk/adsl/adsl_technology.htm#bit_loading). DMT technology is still the same behind it. adsl1 used a less efficient coding algorithm for error correction overheads, which is why it needed the extra bit loaded & 6dB minimum.
iirc its something to do with the less error correction overhead that allows the 1 bit min loading.
TBH I think we are all singing from the same hymn sheet. :)
GB gave another very valid reason why a line could show the messy zero bits like what we see at the end of BE's range and Im not disagreeing with what he says.
All I was trying to say is that I have a strong feeling that on BE's line it was more to do with how the channel analysis (http://www.kitz.co.uk/adsl/adsl_technology.htm#sync) had deemed his line during the sync up process, rather than after a period of bit loading.. purely for the fact it was still there after a fresh resync.
BE said "I forced a modem resync today, just in case a fresh connection changed anything, but it didn't." <<---- That is why I suspected channel analysis. If it was due to bitswapping, then I'd expect those tones to show at least some SNR after a fresh boot.
Obviously bear in mind the target snrm had to be factored in also, so if a 6db target noise margin was set then on adsl1 12db of snr was needed to make a tone useable and 9db on adsl2.
oops got me.. I simplified things in my example by using 6dB.
Although I am fully aware there's a floor level which is loosely based around the target snrm (http://www.kitz.co.uk/adsl/adsl_technology.htm#bit_allocation), what I did forget to include was the fact that it needs another 3dB to load one bit (even though I know this). It was supposed to be a very quick example showing what happens during chan analysis - I did say it was a quick example using made up figures. In reality, its actually far more complex than Sync speed = (Tones_in_use * (SNR - Target SNRm) / 3dB)) because the router also has to allow somewhere for interleaving and error correction (BER rate) when it calculates the sync speed. There is an algorithm out there somewhere involving QAM, but my eyes just glaze over when I look at it. ???
My example would be about right for a very rough example for adsl2+ & VDSL.... but because BToR sets a min 6dB* of SNRm then my example should have said 9.1 for the pass & 8.9 for fail when it comes to BE's connection :blush:
* or whatever the target SNRM is set at.
-
FWIW, my VDSL2 connection has been in sync for around 3.5 days.
It does appear that on VDSL2 connections tones deemed to be unuseable when SNR is very low/non-existent can be brought back into play as conditions improve (without needing to wait for a resync).
See the attached examples from last night (22:00) this afternoon (14:00) & tonight (22:00).
-
FWIW, my VDSL2 connection has been in sync for around 3.5 days.
It does appear that on VDSL2 connections tones deemed to be unuseable when SNR is very low/non-existent can be brought back into play as conditions improve (without needing to wait for a resync).
See the attached examples from last night (22:00) this afternoon (14:00) & tonight (22:00).
yeap also seeing the D2 tones fragment (a visual term for unused and used data) when DS SNR go's below 6db and those tones look'd very steady during my 15 months on FTTC until the 12 of october, I can not emphasise this enough to the Big Brains here the update has made changes here you can dismiss it with openreach technical jargon till the cows come home, but I am telling you the update is not working for me ok !
-
If anything, it seems to have made a very slight improvement on my 1000m or so long connection.
Pre-update montage attached.
-
. . . on my 100m or so long connection.
<Cough> (Yet another fur-ball). And not forgetting the other 900 metres of your D-side? :P
-
If anything, it seems to have made a very slight improvement on my 100m or so long connection.
Pre-update montage attached.
I would have thought your "100m" connection would be able to use the D3 band and give you a higher sync than what you have. ::)
-
. . . on my 100m or so long connection.
<Cough> (Yet another fur-ball). And not forgetting the other 900 metres of your D-side? :P
hahaha, Im glad it isnt just me that does things like that :lol:
-
O.K, already!!!
Original post edited accordingly :-[
-
Sorry if I didnt explain it well what I meant about about the tx power.
One of the parameters that can occur during the bitswap process is the gain in power, in all of the tones can be redistributed slightly to try and increase the overall SNR. This gives a tad more overhead for the other tones to be able to load an extra bit(s) which it may not have been able to do during the original sync process. This is why during a fresh sync your power may be at 18dBm, but after a while it may show as say 19 or 20dBm. Im not quite sure how else to phrase what I meant. :/
The bitwapping process can adjust bits and power. These 2 aspects are called bit-swap and gain-swap.
>> in my adsl days generally my modem would mark the tone unuseable once bitloading hit 0, if I ever seen a used tone hit 0 it became unused until a fresh sync event.
If the SNRm does get so low that 0 bits are loaded, yes the router can then mark that tone as unused.
That tone wont become available again until a fresh resync and the SNRm will be reported as 0dB as you say.
However, some routers do still continue to show the 'real' SNR even if its too low too load any bits.
I don't know if the HG612 is one of them or not. BE gave his SNR (not SNRm) figures.
>> I dont know if vdsl is still the same but on adsl 3db of snr was required per bitloading on a tone, adsl1 had a min bitloading of 2 so 6db of snr was required to make it useable, with 45db of snr needed for a 15 bitloading on the tone,
Agreed again (http://www.kitz.co.uk/adsl/adsl_technology.htm#bit_loading). DMT technology is still the same behind it. adsl1 used a less efficient coding algorithm for error correction overheads, which is why it needed the extra bit loaded & 6dB minimum.
iirc its something to do with the less error correction overhead that allows the 1 bit min loading.
TBH I think we are all singing from the same hymn sheet. :)
Yes I agree, although in my case I am learning some new verses! :) Thanks for the explanation, Kitz, I was not aware of gainswapping. On my line the Tx power never seems to change by more than 0.1dBm.
GB gave another very valid reason why a line could show the messy zero bits like what we see at the end of BE's range and Im not disagreeing with what he says.
All I was trying to say is that I have a strong feeling that on BE's line it was more to do with how the channel analysis (http://www.kitz.co.uk/adsl/adsl_technology.htm#sync) had deemed his line during the sync up process, rather than after a period of bit loading.. purely for the fact it was still there after a fresh resync.
BE said "I forced a modem resync today, just in case a fresh connection changed anything, but it didn't." <<---- That is why I suspected channel analysis. If it was due to bitswapping, then I'd expect those tones to show at least some SNR after a fresh boot.
Yes, I guess it depends on the predominant types of noise/interference/crosstalk seen by the particular line. The sync process can only take a detailed snapshot of the line characteristics over a period of a few seconds, whereas bitswapping can then carry out dynamic adjustments as conditions change. On BE's line the crosstalk may be more or less constant, whereas on mine the noise on some tones seems to be more intermittent (e.g. HF radio interference in particular atmospheric conditions?), so that it is less likely to be "seen" during sync.
From BE's stats the new algorithms seem to be managing to load one or two bits on some D2 tones up to about Tone 1750 on his line, whereas the old ones gave up completely above about Tone 1550.
-
O.K, already!!!
Original post edited accordingly :-[
If anything, it seems to have made a very slight improvement on my 100mm or so long connection.
Eh? That must be an appallingly bad line. :P
A length of 100 mm == 10 cm == 1 dm == 0.1 m ~= 4 inches!