Print

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

[bossian]

Can I use both?

You can, to a certain extent. But sooner or later there may be a conflict, so it's probably best to run them separately at different times.

Been running both now for about two weeks without conflict 

The HG612 CLI did 'tell me off' the other day though, because dslstats & 612_modem_stats were running... 
I was messing around with something for the site and I also had the web GUI and a cmd telnet session open...  and got a message in the telnet window saying something like "too many open admin sessions...closing" in the telnet window.

mmmmm interesting.......I'm not actualy using the FTTC connection, I'm routing all my traffic through my virgin connection.

So as long as I don't saturate the HG612 with requests, it could well handle both apps?

[Bald_Eagle1]

So, as I originally asked, can I have some links to tutorials for both please.....

Does this help?:-

https://docs.google.com/file/d/0B7Kcea04kkOEVkF4cUN0OUdhcVk/edit?usp=sharing

[roseway]

I don't have a tutorial as such, but the DSLstats website is at http://dslstats.plainroad.me.uk and most of the information you need is there.

[bossian]

OK, so I have gone with BE as he got here first, I'll look at adding roseway's later in the week, want to get all settled first.

So I'm up and running and have monitoring running 24/7. And since starting just over an hour ago theres already been a resync!

Anyway, I will leave it alone till tomorrow to look at the graphs etc, but I did get these.......

xdslcmd info --stats

xdslcmd: ADSL driver and PHY status

Status: Showtime

Retrain Reason:   0

Max:   Upstream rate = 29960 Kbps, Downstream rate = 106780 Kbps

Path:   0, Upstream rate = 4296 Kbps, Downstream rate = 48242 Kbps



Link Power State:   L0

Mode:         VDSL2 Annex B

VDSL2 Profile:      Profile 17a

TPS-TC:         PTM Mode

Trellis:      U:ON /D:ON

Line Status:      No Defect

Training Status:   Showtime

      Down      Up

SNR (dB):    17.4       26.4

Attn(dB):    0.0       0.0

Pwr(dBm):    13.3       4.3

         VDSL2 framing

         Path 0

B:      31      24

M:      1      1

T:      64      1

R:      16      16

S:      0.0211      0.1781

L:      18197      1842

D:      1991      112

I:      48      41

N:      48      41

         Counters

         Path 0

OHF:      749941      219406

OHFErr:      0      0

RS:      239980519      2742482

RSCorr:      402      0

RSUnCorr:   0      0



         Path 0

HEC:      0      0

OCD:      0      0

LCD:      0      0

Total Cells:   117835898      0

Data Cells:   23364      0

Drop Cells:   0

Bit Errors:   0      0



ES:      0      0

SES:      0      0

UAS:      36      36

AS:      1270



         Path 0

INP:      7.00      3.50

PER:      1.68      5.78

delay:      11.00      5.00

OR:      94.77      179.70



Bitswap:   6      0



Total time = 21 min 50 sec

FEC:      402      0

CRC:      0      0

ES:      0      0

SES:      0      0

UAS:      36      36

LOS:      0      0

LOF:      0      0

Latest 15 minutes time = 6 min 50 sec

FEC:      0      0

CRC:      0      0

ES:      0      0

SES:      0      0

UAS:      0      0

LOS:      0      0

LOF:      0      0

Previous 15 minutes time = 15 min 0 sec

FEC:      402      0

CRC:      0      0

ES:      0      0

SES:      0      0

UAS:      36      36

LOS:      0      0

LOF:      0      0

Latest 1 day time = 21 min 50 sec

FEC:      402      0

CRC:      0      0

ES:      0      0

SES:      0      0

UAS:      36      36

LOS:      0      0

LOF:      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

Since Link time = 21 min 9 sec

FEC:      402      0

CRC:      0      0

ES:      0      0

SES:      0      0

UAS:      0      0

LOS:      0      0

LOF:      0      0



xdslcmd info --pbParams

xdslcmd: ADSL driver and PHY status

Status: Showtime

Retrain Reason:   0

Max:   Upstream rate = 29960 Kbps, Downstream rate = 106780 Kbps

Path:   0, Upstream rate = 4296 Kbps, Downstream rate = 48242 Kbps



Discovery Phase (Initial) Band Plan

US: (0,95) (880,1195) (1984,2771)

DS: (32,859) (1216,1959) (2792,4083)

Medley Phase (Final) Band Plan

US: (0,95) (880,1195) (1984,2771)

DS: (32,859) (1216,1959) (2792,4083)

       VDSL Port Details       Upstream        Downstream

Attainable Net Data Rate:      29960 kbps        106780 kbps

Actual Aggregate Tx Power:        4.3 dBm          13.3 dBm

============================================================================

  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3

  Line Attenuation(dB):    0.1    16.9    26.6     N/A    9.4    22.2    36.7   

Signal Attenuation(dB):    0.1    16.8    26.6     N/A    9.4    22.2    36.7   

        SNR Margin(dB):    27.3    0.0    26.4     N/A    17.6    17.4    17.4   

         TX Power(dBm):   -5.0   -128.0    3.8     N/A    10.4    7.3    7.1   



I'm not sure about what all this lot means, but I can see that my line can sustain a much higher rate than what I'm getting!

[Bald_Eagle1]

I'm not sure about what all this lot means, but I can see that my line can sustain a much higher rate than what I'm getting!

It basically means you have quite a serious problem.

Firstly, the difference between Attainable Rates (Max:) & Sync speeds (Path:) is huge:-

Max:   Upstream rate = 29960 Kbps, Downstream rate = 106780 Kbps
Path:   0, Upstream rate = 4296 Kbps, Downstream rate = 48242 Kbps


Line & Signal attenuation per band is pretty low:-

  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3
  Line Attenuation(dB):    0.1    16.9    26.6     N/A    9.4    22.2    36.7   
Signal Attenuation(dB):    0.1    16.8    26.6     N/A    9.4    22.2    36.7


SNRM per band is quite high, suggesting much higher Sync speeds should be possible - apart from ZERO dB SNRM in the U1 band:-
   
        SNR Margin(dB):    27.3    0.0    26.4     N/A    17.6    17.4    17.4

That could just be a modem reporting error at the time the data was grabbed, but it looks completely wrong!



DS Interleaving depth is pretty high at 1991 & US Interleaving depth is unusually high at 112:-

D:      1991      112

US Interleaving depth is usually very low or zero, even on generally poor or long distance connections.

Impulse Noise Protection is higher than the starting point of 3.00 & 0.00 when Interleaving is first applied:-

INP:      7.00      3.50
delay:  11.00      5.00

delay is also higher than the usual starting point of 8.00 & 0.00

Various error counts are low or non-existent for the 21 minutes or so the connection has been in sync.

Bitswapping was also at a low rate.


So, just looking at the data collected over a short timeframe, your connection could be suffering from impulsive bursts of noise (intermittently or with a regular timed pattern), you may have a bridged tap/star wiring somewhere in your internal wiring set up (The Hlog graph stored in the Current_Stats folder should identify if that is the case) or there may be an external source of interference or a possibly intermittent line fault.

DLM has detected problems & tried to mitigate them by applying Interleaving etc. at quite high levels, thus clobbering Sync speeds accordingly in an attempt to provide stability rather than speed.

It appears that your Sync speeds haven't been banded yet, unless they are banded & the connection was unable to even achieve the banding cap at the time it resynced.

Can you think of anything electrical that may have been switched on or off at the time the connection resynced?

Possibly making or receiving a phone call could have been the trigger, which would suggest a HR fault.



A quick look at the snapshot montage (line_stats-P) also stored in the Current_Stats folder may just provide some immediate clues.



You can manually generate snapshot Plink logs, optionally graphing the data at any time, either manually via HG612_current_stats.exe (in the Scripts folder) or via the "Run snapshot stats" button in the Settings Editor's GUI.


You can also manually graph the ongoing stats at any time via graphpd.exe (in the Scripts folder) or via the "Run graphPD" button in the Settings Editor's GUI, specifying say 1 hour or 2 hours etc. (1 h or 2 h)



I would definitely keep logging 24/7 for at least a few days to obtain a graphic representation of your connection's performance (or lack of), possibly identifying regular patterns to the issue(s).

[bossian]

Thanks for the reply BE....some very interesting points you've made.

My house wiring was disconnected for a week prior to the last OR engineer visit and the problem was still there. And anyway, it's all new and correctly done.

Noise.....I have numerous bits of kit in the cupboard where the modem is....VMG300 virgin modem, Draytek 2920 dual wan router, PC, laser printer. All of these items, apart from the printer are plugged into a UPS.....could that be a problem?

I've had a further 2 re-sync since this one yesterday, both occurred late evening. I was aware at the times and nothing was switched on and no calls came in. I have had 3 calls today and it hasn't effected anything. I also carried out call backs on my 3 sky box's and again no effect.

Here's the log as is now.....

 xdslcmd info --stats

xdslcmd: ADSL driver and PHY status

Status: Showtime

Retrain Reason:   1

Max:   Upstream rate = 28261 Kbps, Downstream rate = 105524 Kbps

Path:   0, Upstream rate = 4296 Kbps, Downstream rate = 48242 Kbps



Link Power State:   L0

Mode:         VDSL2 Annex B

VDSL2 Profile:      Profile 17a

TPS-TC:         PTM Mode

Trellis:      U:ON /D:ON

Line Status:      No Defect

Training Status:   Showtime

      Down      Up

SNR (dB):    17.3       26.6

Attn(dB):    0.0       0.0

Pwr(dBm):    13.3       5.3

         VDSL2 framing

         Path 0

B:      31      24

M:      1      1

T:      64      1

R:      16      16

S:      0.0211      0.1781

L:      18197      1842

D:      1991      112

I:      48      41

N:      48      41

         Counters

         Path 0

OHF:      28714552      2612330

OHFErr:      18453      0

RS:      598721638      2289058

RSCorr:      6067439      0

RSUnCorr:   5494362      0



         Path 0

HEC:      139491      0

OCD:      0      0

LCD:      0      0

Total Cells:   214278054      0

Data Cells:   4517839      0

Drop Cells:   0

Bit Errors:   0      0



ES:      136      0

SES:      77      0

UAS:      139      139

AS:      48667



         Path 0

INP:      7.00      3.50

PER:      1.68      5.78

delay:      11.00      5.00

OR:      94.77      179.70



Bitswap:   939      24



Total time = 20 hours 51 min 46 sec

FEC:      13223609      0

CRC:      42141      0

ES:      136      0

SES:      77      0

UAS:      139      139

LOS:      49      0

LOF:      0      0

Latest 15 minutes time = 6 min 46 sec

FEC:      0      0

CRC:      0      0

ES:      0      0

SES:      0      0

UAS:      0      0

LOS:      0      0

LOF:      0      0

Previous 15 minutes time = 15 min 0 sec

FEC:      3      0

CRC:      0      0

ES:      0      0

SES:      0      0

UAS:      0      0

LOS:      0      0

LOF:      0      0

Latest 1 day time = 20 hours 51 min 46 sec

FEC:      13223609      0

CRC:      42141      0

ES:      136      0

SES:      77      0

UAS:      139      139

LOS:      49      0

LOF:      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

Since Link time = 13 hours 31 min 7 sec

FEC:      6067439      0

CRC:      18453      0

ES:      82      0

SES:      37      0

UAS:      0      0

LOS:      14      0

LOF:      0      0



xdslcmd info --pbParams

xdslcmd: ADSL driver and PHY status

Status: Showtime

Retrain Reason:   1

Max:   Upstream rate = 28261 Kbps, Downstream rate = 105524 Kbps

Path:   0, Upstream rate = 4296 Kbps, Downstream rate = 48242 Kbps



Discovery Phase (Initial) Band Plan

US: (0,95) (880,1195) (1984,2771)

DS: (32,859) (1216,1959) (2792,4083)

Medley Phase (Final) Band Plan

US: (0,95) (880,1195) (1984,2771)

DS: (32,859) (1216,1959) (2792,4083)

       VDSL Port Details       Upstream        Downstream

Attainable Net Data Rate:      28261 kbps        105524 kbps

Actual Aggregate Tx Power:        5.3 dBm          13.3 dBm

============================================================================

  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3

  Line Attenuation(dB):    0.1    17.8    27.8     N/A    9.8    23.1    38.1   

Signal Attenuation(dB):    0.1    17.6    27.7     N/A    9.8    23.1    38.1   

        SNR Margin(dB):    18.7    17.5    27.0     N/A    18.1    16.4    17.3   

         TX Power(dBm):   -5.0   -33.2    4.7     N/A    10.4    7.3    7.1   



And here's my first 24hrs (almost) graphs....

[Bald_Eagle1]

Now I have seen your second set of raw stats I can see that it did resync (Retrain Reason 1).

Apparently Retrain Reason 1 signifies Rdi Detector - but I have no idea what that is.

Retrain Reason 1 is very rare.

Usual VDSL2 Retrain Reasons are 0 (Loss Of Signal) & 2 (Negative Margin).

Even though your connection has resynced, Sync speeds are identical to earlier, so it suggests your line is banded after all, but at very unusual speeds.

Just for curiosity, who is your ISP?


The large gaps in your graphs concern me.
Was ongoing logging or even the PC switched off during those periods?

BTW, the Full Monty montage of the ongoing graphs provides a bit more data than the one you posted.


Could you also post an example or axamples from differing times of day/night of your snapshot data (Bitloading etc.)?



 

[bossian]

The gaps in the graphs we're down to my logging into my server with my everyday account after being in the admin one. Have set the task to run always, whatever account is running.

My ISP is Plusnet.

I saw the 'reason 1' from the last re-sync, I had a shut down this afternoon and it re-sync'd on 'reason 0'

After more research, decided to remove the UPS from the equation today, (this afternoons shut down) Not sure if it makes noise, but I do know the sine wave of the output is more square than a slope and even though it's never caused a problem with the other modem and router, I'm not sure if it would affect the vdsl modem.

I have realised I have a digital MW radio at home, going to try that in my 'plant' room tomorrow. Think it's worth a try....

So below, I have dumped the last 2 hours and a 2 hour stint from this morning.....

[bossian]

Well 1st night of a full set of graphs and I notice a re-sync around 11 last night and another at 5:48 this morning.....with a retrain reason of 1 again?

Nothing happened at home last night around 11ish....was just watching a film from 10:30 till midnight. And as for the last one....we was all tucked up in bed. So this is deffo starting to point to outside influences on my drop outs.

Anyway, here's my graphs from the 6am collection.....

[ColinS]

R/N=16/48=25% from your stats.  This means that the data bits transmitted are carrying a 25% overhead to allow your interleaving depth of 1991 to recover from bits errors.  This goes some way to explain why your actual sync rate is so low compared with your attainable.  And as BE has suggested you may also have been capped at a lower profile.

Unfortunately, it doesn't explain why this has happened to you. 

[bossian]

So another 24hrs on and another set of graphs, except this time I have another set of good graphs to compare them too

As mentioned before, I have another FTTC line (BT Business) at my work place that is on the same exchange, I have installed a second HG612 I got off eBay there. That line is performing perfectly with the full 80/20.

Having two sets of graphs to compare side by side is allowing me to now see the differences and the things that stick out are....

Signal to noise ratio
DS_RS
All the attenuations
US SNRM
DS SNRM

What do you guys think?

[Bald_Eagle1]

Your connection resynced 3 times yesterday.

It's hard to spot minute sync speed changes due to the scale of the graphs.
Has it remained at exactly the same sync speeds as previously?
i.e. Path:   0, Upstream rate = 4296 Kbps, Downstream rate = 48242 Kbps.

If so, they are most unusual speeds to be banded at.

Plusnet could confirm your current Profile Name, someting on these lines:-

11.2M-22.4M Downstream, Interleaving Off - 2.5M-5M Upstream, Interleaving Off

Curiously, multiplying your sync speeds by 1.024 results in  4399 US & 49400 DS (approx).
Those look more like banded speeds, but we don't usually need to apply a conversion factor to the speeds reported by the HG612.


You mentioned the HG612 was already unlocked when you obtained it.
I wonder if the previous user has altered any settings?

It may just be worth performing a factory reset of the HG612.


In the Device page of the modem's GUI Status page, what is reported for these:-

Firmware version  A2pv6C030b.d22g 
Batch number  BC1P10.028.A2pv6C030b.d22g 

Those are the details for the original unlocking BLOB.


You also mentioned this:-

mmmmm interesting.......I'm not actualy using the FTTC connection, I'm routing all my traffic through my virgin connection.

I wonder if differing modes of connection in close proximity to each other could be having some effect?


One obvious 'problem' seems to be your U1 band.

THe 'V' shape of the D1 band shown in your bitloading & SNR snapshot graphs is normal.
We THINK that's intentional - possibly to avoid too much crosstalk at ADSL frequencies.

However, it's not usual to see such low SNR in the U1 band (your graph is attached).

Your ongoing US SNRM graph also shows issues generally, but particularly with the U1 band - i.e. it sometimes isn't used at all (graph attached).


I have no idea what could be causing these issues, but I do suspect a line fault rather than electrical interference.

 

[bossian]

Thanks again for your help BE, so much more for me to take in and try and understand.

My HG612's status.....

Firmware version  A2pv6C030b.d22g 
Batch number  BC1P10.028.A2pv6C030b.d22g 

If I factory reset it, will it need re-hacking? If so, can you point me towards a good guide?

I have updated my PN ticket and have asked for my current profile, will post when it come through.

You also mentioned this:-


mmmmm interesting.......I'm not actualy using the FTTC connection, I'm routing all my traffic through my virgin connection.


I wonder if differing modes of connection in close proximity to each other could be having some effect?

The 2 modems are in close proximity to each other, around 300mm, I will go and have a bit of a change around shortly, see if it changes anything.

This is a very heavy internet household and apart from one PC and an iPhone using the FTTC connection, everything else runs across the virgin connection.

Actually, before I re-arrange....I'm going to put all traffic over the FTTC and shut down Virgin for an hour.

I'm strongly starting to believe this is all a line fault, but the more I do to determine this the more ammunition I can present to Plusnet.

I shall report back in an hour......

[bossian]

Ok so, I powered down the VMG300 Virgin modem at 12:40 and restarted at 13:40. My router is set to failover on my WAN's, so it just routed all traffic across the VDSL.

I can see changes in some stats at this time, but something happened at 13:10ish and again at 13:18ish.....from my looking in my router logs, I can see a re-sync.

Here's my stats over 2 hours

[Bald_Eagle1]

Looking at your Connection Up Time graph it resynced twice - at around 12:40 & again at around 13:12.

The connection had only been up for 1.4 hours anyway at 12:40, so that's 3 resyncs within a short time frame.

We can see some fluctuation of DS SNRM, but US seems all over the place.

This looks rather similar to the issues that Kitz is seeing at the moment.
Do you live near each other?

You are both also with Plusnet & both connected to ECI DSLAMS.

If I'm not mistaken, you both also obtained pre-unlocked HG612 modems (maybe even from the same person who unlocked them?).

One setting that affects US performance is QOS.
It is enabled by default in the HG612's settings.

Is it disabled in your HG612(s)?

Disabling QOS does appear to increase US throughput for some users, but as it disables Quality of Service, I wonder if that could possibly be the cause?

Kitz was also seeing the issue on her ADSL connection, so everything I have mentioned above may be purely coincidental.