Print

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

[hendry]

Thanks for taking time to edit the posts to remove the number. I wasn't too worried as that number won't have anyone answering it since we use another VOIP number.

Had to get my parents to reboot the VMG1312-B10A router as the Web UI was unresponsive.

http://s.natalian.org/2016-08-02/xDSLstats.txt

I guess you want some stats over a longer period of time? ? Just let me know. I have remote access to it over SSL.

A&A are being helpful. We aren't plugged straight into the nte5 test socket. Since my parents can't recognise a filter, A&A are sending out a new one for them to try.

[William Grimsley]

Line looks fine. I think the copper quality is really poor, but DLM certainly hasn't intervened a great deal.

[kitz]

Had to get my parents to reboot the VMG1312-B10A router as the Web UI was unresponsive.

It happens occasionally on the VMG8324 too, its one of the things we have found buggy with the f/w.  Dont know what triggers it and it can be ok for months, then a few happen within a couple of weeks.

Code: [Select]

VDSL Port Details       Upstream         Downstream
               Line Rate:      0.454 Mbps       18.009 Mbps
    Actual Net Data Rate:      0.435 Mbps       17.964 Mbps
          Trellis Coding:         ON                ON
              SNR Margin:        6.5 dB            6.5 dB
            Actual Delay:          0 ms              0 ms
          Transmit Power:        6.2 dBm           6.3 dBm
           Receive Power:       -5.9 dBm         -24.2 dBm
              Actual INP:        0.0 symbols       0.0 symbols
       Total Attenuation:       12.2 dB           33.8 dB
Attainable Net Data Rate:      0.543 Mbps       18.366 Mbps
Thanks for the stats, as William said cant see much wrong there and doesnt look like too much DLM intervention.
Running the telnet command adsl info --stats will out put more info so we can see how much Interleaving and Error correction has been applied.
Judging from an SNRm of 6.5dB not a great deal. 

However 18.009/17.964 Mbps is noted as a possible banding.  No proof, more like what b*cat would call "a tingle in my whiskers".
If the line always syncs at 17.964 then it is, but the line hasnt really got that much more to give at that snapshot in time.

There are a lot more diagnostics that can be obtained from your modem which DSLstats will be able to give. Things like QLN, hlog and bitloading but another tingle in whiskers feeling in your case it may not show anything obvious. However its worth checking these just for the sake of elimination.  These graphs show us a true indication of your wire health.  Graphing SNRm over a period of time also shows us how stable a line is.   Basically these checks are similar to some of the checks which an Openreach engineer could see on his JDSU, but he doesnt have the luxury of being able to be there and monitor 24/7.   If you can it may be an idea to install DSLstats and get it to send the data to MDWS for logging.    If you need help with any of this just ask.
   

IMHO the line is vastly under performing. Its not falling within the clean 32.4/22.4 range.  Impacted is a cop out which should be reserved for lines with poor internal wiring.  

We aren't plugged straight into the nte5 test socket. Since my parents can't recognise a filter,

There is no filter due to you having a SSFP on the NTE. 
However if you remove this to check directly from the test socket and isolate other internal wiring.. then a filter will be needed as an adapter.  Unlike the SSFP, the  test socket is a telephone jack which cant accept RJ11/RJ45 plugs.

Presumably the grey cable plugged into the front of the SSFP is RJ11 which goes directly to your modem.  It is noted there appears to be some other extension cable directly wired in to the NTE which looks like CAT5 quality.

[burakkucat]

Once the circuit is being used for anything other than telephony (from DC up to ~4 kHz), one must stop thinking about it as two wires carrying limited bandwidth audio, audio signalling tones and DC loop signalling and start thinking about it in terms of a radio frequency transmission line.

In this particular case using a flat configuration, non-twisted pair, cable to link the modem to the SSFP and routeing that same cable thorough a hole with (what looks like) a mains electricity cable is extremely sub-optimal. From what I have seen of the EU environment, the location of the modem and all the associated wiring is sub-optimal. Until it is all rationalised -- with the modem located near the NTE5/A plus SSFP pairing and linked to the SSFP via the shortest possible twisted pair cable (think radio frequency transmission lines) -- then some of the poor performance is actually self-inflicted.

Unfortunately a similar comment can be made about the failure of the land-owner to maintain the trees, i.e. trim them back regularly when they begin to encroach onto the incoming aerial feed to the property.

[hendry]

Wow, that's again for the thorough post. I'm impressed.

Running the telnet command adsl info --stats will out put more info so we can see how much Interleaving and Error correction has been applied.
Presumably the grey cable plugged into the front of the SSFP is RJ11 which goes directly to your modem.  It is noted there appears to be some other extension cable directly wired in to the NTE which looks like CAT5 quality.

Here is the output of the telnet command: http://s.natalian.org/2016-08-03/adslstats.txt

What CAT-X quality should the cable be? It's quite a pain to run a new cable there. It doesn't go along with power btw. Annoying there are no power sockets in that cupboard area, else I would have put the modem there. Tbh I did a test right from the test socket before not long after they installed 21CN and I found the sync rates to be the same as upstairs. Maybe I didn't give it enough time.

I'll try get dslstats going on my rpi2.... but there doesn't seem to be a cli ?! Can't do a GUI setup over this connection!

[hendry]

I presume those tree's are on your parents land, if so they could cut them back so it doesn't affect the line. I also wonder what the speeds would be at the first pole on the land, it may be worth coming up with a solution to get a master socket there (shed/caravan/waterproof cabinet) and then running a network cable and phone line underground back to the house). Another option might be line bonding, you could have 1 ADSL line and 1 FTTC to keep costs down depending on what the ADSL upload speed is like it might give enough boost to help.

I like the idea of putting the modem at the bottom of the driveway, but when I suggested it to A&A, and someone at BT Openreach they thought I was mad.

TBH getting power down there will be very damn tricky. Not sure if PoE would be enough for the ZyXEL. Doesn't help the driveway is quite long. Probably getting as 100m when I account for the twisty bits.

[kitz]

Code: [Select]

D:              1               1

INP:            0.00            0.00
INPRein:        0.00            0.00
delay:          0               0
Very interesting - DLM is leaving you alone

Code: [Select]

Total time = 1 days 5 hours 34 min 46 sec
FEC:            0               891
CRC:            1619            20
ES:             1382            20
Your line is occasionally erroring but its acceptable and within limits.  In view of the fact there isnt any error protection or interleaving applied, for the length of the line if it stays at that rate per day then its actually quite good.  FEC is normal for upstream as RS encoding is switched on by default.

Code: [Select]

SNR (dB):        5.9             6.4
Your SNRm has dropped since yesterday showing that you likely do have daily swings, but swings of <1dB are normal for the majority of lines.
Based on that snapshot then the line seems nice and steady for a long line.  Graphing will show daily swings in more detail.

Code: [Select]

Attn(dB):        32.1            0.0
Line is long and/or has Ali. Based on other lines with similar attenuation you are looking at 20Mbps very tops downstream.   Your upstream though is lower than anticipated (1/2 ?)   Bit-loading/hlog graph may throw more light on this.

Its only been one day, but that line actually looks in quite good nick downstream at least.

[kitz]

What CAT-X quality should the cable be? It's quite a pain to run a new cable there.

It was actually a positive that you were using CAT5 or data quality cable, rather than flimsy cheap flat telephone extension cable.

I'll try get dslstats going on my rpi2.... but there doesn't seem to be a cli ?! Can't do a GUI setup over this connection!

Cant help with that as I dont have an rpi and dont know. Perhaps one of the rpi guys or Eric will have some input on this.

[JamesK]

I'll try get dslstats going on my rpi2.... but there doesn't seem to be a cli ?! Can't do a GUI setup over this connection!

DSLStats does create a configuration file in the .dslstats directory. However, the passwords for connecting to the modem and MDWS are encrypted. So it would be difficult to populate it from the command line.

I found this article one of the best for establishing a GUI connection to the Pi as you can use the standard Windows Remote Desktop Client with it, and it works well over a low-bandwidth connection to.
http://www.modmypi.com/blog/remotely-accessing-the-raspberry-pi-via-rdp-gui-mode
I login to the Pi via RDP, start and configure DSLStats and then close the running session. This is important because DSLStats doesn't run as a service, so the session needs to remain running.

Hope this helps.

[d2d4j]

Hi

@kitz - I believe the dsl telephone cable is a standard flat non twisted cable

From what could make out, as I posted earlier in the thread, leaves the nte5 through the ceiling in the same hole as 2 power cables, and also, as it travels upto the router, is parallel with the power extension cable

I do not think the confirmation was given over what the grey cable into the nte5 actually is - presume it is for extension phones

I agree with burrucat, it is not ideal

It could be the magnetic field of the power is stopping the upload frequencies perhaps

Many thanks

John

[hendry]

Thank you d2d4j for your comment.

I do not think the confirmation was given over what the grey cable into the nte5 actually is - presume it is for extension phones

Yes, it's just a grey cable that came with the original modem. I haven't replaced it for many years since the hole it came through is very painful to work with since I don't think I can re-crimp such a cable! I agree it's less than ideal. I will try replace it when I'm next in Cornwall.

https://www.flickr.com/photos/hendry/3503827772

As mentioned before, I did bring the modem down and test directly with the test socket, but I didn't notice any syncing changes, so I wasn't too concerned. Perhaps I didn't wait long enough!

I'm thinking I could power the ZyXEL with a PoE adaptor and run a single cat6 down which I would crimp myself. Wish those PoE things weren't so darn expensive!

[WWWombat]

Code: [Select]

D:              1               1

INP:            0.00            0.00
INPRein:        0.00            0.00
delay:          0               0
Very interesting - DLM is leaving you alone

 I'm concerned about a slightly different aspect

Code: [Select]

MSGc:           26              34
B:              239             13
M:              1               1
T:              53              17
R:              0               16
S:              0.4248          0.9836
L:              4520            244
D:              1               1
I:              240             30
N:              240             30

The worst aspect of this line is the abject upstream speed, right?

For some reason, the sync has chosen to allocate (upstream) 16 bytes in every RS block as the FEC parity ... but the block is only 30 bytes long. Over 50% of upstream bandwidth used for error protection when, from the RS counters, there are few errors.

Why would the modems choose this when DLM is asking for nothing?

[kitz]

Yup upstream, which is why I was interested in seeing the bitloading graph, upstream is about 1/2 of what I'd expect for the atten. 

>> but the block is only 30 bytes long

Good spot.  Why is the block only 30 bytes? 

DLM applies upsteam FEC by default regardless if the line is interleaved or not.  (ECI cab)
This are my own framing params showing 16 RS checkbytes. (VMG8324 & ECI cab)

Code: [Select]

MSGc:           18              150
B:              239             236
M:              1               1
T:              23              5
R:              0               16
S:              0.0955          0.3771
L:              20104           5410
D:              1               1
I:              240             255
N:              240             255
Supposedly N= K+R with K being the number of bytes in DMT Frame.
Note that 'B' (no of bytes in the data frame) is very low at only 13 bytes... so 13 bytes of what could be useful data* and yet 16 bytes of redundancy overheads?  Is that right  


----
clarification of 'what could be': ie before other overheads.
 

[hendry]

Since that DSLstats program requires a GUI, I was hoping just to write a script to retrieve the stats every hour.

I wrote a script that does that and puts them here: http://archive.webconverger.com/dslstats.zip

I was hoping to try upload them to https://www.mydslwebstats.co.uk/ but the site is down for me.

Btw my Dad claims that the modem is now connected straight in the socket from yesterday afternoon and I think upstream rate is slightly better. ~500 to ~550 Kbps ? Am I reading that correctly?

I'm using epoch for the filenames btw. To get them human readable:

Code: [Select]

date -u -d @1470298977

[kitz]

Hi

Since that DSLstats program requires a GUI, I was hoping just to write a script to retrieve the stats every hour.

I'm absolutely no help in this area, but Ive not heard of other rpi users having to write further scripts.   I'm way out of my depth on this area, but there is a discussion here and here

I was hoping to try upload them to https://www.mydslwebstats.co.uk/ but the site is down for me

That may be down to your current location and Tony may have blocked a range of IPs from which your coming in from.   Both of us have problems with shall I say certain regions and spammers/bots.  I myself have a Singapore blacklist in place.
Tony may be able to do something about this and I'll contact him giving your current IP.   Uploading from your parents address wont be an issue, just you being able to view the site from abroad, to be able to sign up.