Print

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

[Bald_Eagle1]

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

[NewtronStar]

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

[Bald_Eagle1]

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.

 

[NewtronStar]

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.

[Bald_Eagle1]

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.

[NewtronStar]

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

[Bald_Eagle1]

They have been uploaded here:-

http://forum.kitz.co.uk/index.php?topic=13051.msg247983#msg247983

[NewtronStar]

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) 

PS what happens to Modems time when the clocks go back at 2AM ?

[Bald_Eagle1]

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.

[Ronski]

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.

Code: [Select]

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.

[Greybeard33]

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; pre- and post- the update attached to 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.

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.

[NewtronStar]

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"

[Bald_Eagle1]

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.

[kitz]

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.
 

[kitz]

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.