Print

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

[Bald_Eagle1]

Hi BE,

Any chance of sending me the Plink log for those particular graphs?

You may have discovered a "glitch" in the scripts.

[Blackeagle]

Emailed to you Paul.

[Bald_Eagle1]

Thanks for that BE.

It looks as though "something" has corrupted your Plink log timestamped 20120415-1351.

It contains data where it shouldn't & in some areas looks completely different to your Plink log from 20120413-2205.

Also when graphing it a Hlog data error is displayed (unlike when graphing your first Plink log).

Have you obtained the snapshot data since & if so, do the graphs look more "normal" (like your original set) i.e. only the 3 DS band plans shown for QLN?

Cheers,


Paul.

[Blackeagle]

Hmmm, that is strange then as I graphed it before I emailed it to you and I didn't notice any errors. However, grabbing my current stats I got

Code: [Select]


Gathering statistics from the modem


Please wait a few seconds.........................


LOGDATE =2012.04.16
LOGTIME =19:00:44

FILEDATE =20120416-1900

MAIN_FOLDER =C:\HG612_Modem_Stats

C:\HG612_Modem_Stats DOES exist

SUBFOLDER = C:\HG612_Modem_Stats\Current_Stats\Current_Stats_20120416-1900

SUBFOLDER does not exist, so creating it

=~=~=~=~=~=~=~=~=~=~=~= Plink log 2012.04.16 19:00:44 =~=~=~=~=~=~=~=~=~=~=~=
*1
**2
***3
****4
*****5
******6
*******7
********8
********8a
*********9
**********10
***********11

All done!


 ****************************************************************************
 ****************************************************************************

  Creating Huawei HG612 Connection Statistics Graphs.

  Using Data from C:\HG612_Modem_Stats\Current_Stats\Current_Stats_20120416-1900
\Plink_20120416-1900.log - Obtained 16/04/12 19:00

 ****************************************************************************

 Discovery Phase (Initial) Band Plan = US: (0,95) (880,1195) (1984,2771)
 Discovery Phase (Initial) Band Plan = DS: (32,859) (1216,1959) (2792,4083)

    Medley Phase (Final) Band Plan   = US: (0,95) (880,1195) (1984,2771)
    Medley Phase (Final) Band Plan   = DS: (32,859) (1216,1959)

        Attainable Rates: Downstream = 41672 k, Upstream = 9140 k
             Sync Speeds: Downstream = 34999 k, Upstream = 2000 k

 ****************************************************************************



 Producing graphs for VDSL2 profile 17a

 *
 **
 ***
 ****
 *****



 Creating Bits-20120416-1900.png
 Creating  SNR-20120416-1900.png
 Creating  QLN-20120416-1900.png
 Creating Hlog-20120416-1900.png

multiplot> plot 'Data_Hlog.txt' using 1:($4>-95.999 && $4<0 ? $4 : 1/0) lw 1 lc
1 notitle w lines

            ^
           line 0: warning: Skipping data file with no valid points

 Converting Pbparams data to Pbparams-20120416-1900.jpg
 Converting  profile data to  profile-20120416-1900.jpg


Creating Montage of:-

 pbparams-20120416-1900.jpg
  profile-20120416-1900.jpg
     Bits-20120416-1900.png
      QLN-20120416-1900.png
      SNR-20120416-1900.png
     Hlog-20120416-1900.png


Press any key to continue . . .

[Bald_Eagle1]

Hmmm,

The first Plink log you graphed & also sent to me looked as expected.
i.e. all US tones in the QLN data have a value of -160.00 & all US tones in the Hlog data have a value of -96.00.

Your more recent Plink logs contain different data values for US tones, hence the 'Data_Hlog.txt' error & the unusal appearance of your QLN graph.

I can only think that re-configuring your router setup has somehow introduced these discrepancies, error message & unusual looking graph.

Otherwise, your first set of graphs & the first Plink log would have also contained the same discrepancies etc.

For curiosity, how were the modem, router & PC(s) set up when your Plink log & graphs looked correct/normal?

Others using the HG612 on an ECI DSLAM don't appear to see these "glitches", but I'm not sure which routers they are using or how they have them set up.

[Blackeagle]

It was just a misconfigured DNS server entry thats all, can't see how it could affect any data supplied by the modem.

Attached is a PuTTY log of a telnet session to the modem.  It contains the edited (for size) result of xdslcmd info --linediag.  Hlog & QLN data is present.

[burakkucat]

From that putty log, I obtain the following two graphs --

[Bald_Eagle1]

It was just a misconfigured DNS server entry thats all, can't see how it could affect any data supplied by the modem.

I don't know, BE.

Something has changed bewteen your Plink log of 13th & your more recent log.

Attached is a PuTTY log of a telnet session to the modem.  It contains the edited (for size) result of xdslcmd info --linediag.  Hlog & QLN data is present.

Even that looks just as strange as the more recent Plink log.

US isn't supposed to be reported for QLN & Hlog (as per the first log with values of -160.00 & -96.00 all the way trhough the US tones (& a little beyond)

[Blackeagle]

What can I tell you BE ??

This is the data coming back from the Huawei.  I have attached the last graph I have of QLN as you would have expected it, and then one showing US data.  This is well before I changed my network config.  I wonder if BTAgent or TR-069 has altered something.

Code: [Select]

Welcome Visiting Huawei  Home Gateway
Copyright by Huawei Technologies Co., Ltd.
Login:admin
Password:
ATP>sh


BusyBox v1.9.1 (2010-10-15 17:59:06 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# xdslcmd --version
xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C030b.d22g
******* Pass *********
#

Perhaps you get a different version ??

[Bald_Eagle1]

Perhaps you get a different version ??

No, identical version.

The only other difference is that you are connected to an ECI DSLAM & most of us are connected to Huawei DSLAMS.

That still doesn't explain why your first logs & graphs looked "normal" though.

[Blackeagle]

As far as I understand it, Hlog is not dynamic but produces its data during the training phase, as does QLN.  Therefore I assume that this data was measured when my (currently only) re-sync occurred. This was at 5:35 AM 15/04  This is further bourne out by the last graph of QLN I have before this time, a graph from later that same day, and a graph from this evening which is exactly the same as the graph from sunday.

Now, I do not have a logical explanation for the lack of upstream data versus it suddenly being reported, but it clearly is.  This may be yet another bug with the Huawei modem but I'm not yet tempted to drop the line to see     

The Huawei/ECI combination is an interesting one as OR have supplied matched equipment, no doubt for improved throughput and sync as matching chipsets should perform best together.  I have noted since using the Huawei that my throughput speeds do not appear to be good versus my sync speed.  Indeed using the ECI, I have not had a speedtest less than 29.46 Mbps   yet with the Huawei, my fastest test has been 27.86 Mbps. Sync on the Huawei at the time was 34999Kbps.  All tests have been carried out on the same speedtest although times have varied and obviously, I have no idea of the sync speed on the ECI.......yet !!

If my connection stays steady for a few more days, I think a change of modem may be in order to see if the speed changes much.

[Bald_Eagle1]

Now, I do not have a logical explanation for the lack of upstream data versus it suddenly being reported, but it clearly is.  This may be yet another bug with the Huawei modem but I'm not yet tempted to drop the line to see     

Another one of FTTC's mysteries/secrets.

Have you any interesting graphs from the ongoing log to show us?

[GigabitEthernet]

I don't know if it is the same on vDSL, but with the Huawei on ADSL it reported the errors incorrectly in the web interface.

[Bald_Eagle1]

Yes,

They are also mixed up in it's GUI on VDSL2, incorrectly showing FEC errors when Interleaving is OFF etc.

[Blackeagle]

This is currently the total amount of data I have so far.  Note the big downstream SNR drop recently tonight 

Connection is still up though.  I wonder just how far that downstream SNR can drop before a re-sync is required.  I've seen it at 2.8dB tonight, which would have had most ADSL routers dropping like flies.