Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
   Compare ISP   Rate your ISP
   Glossary   Glossary
Please login or register.

Login with username, password and session length
Advanced search  


Pages: 1 [2] 3 4 ... 10
 on: April 19, 2019, 02:05:08 PM 
Started by Liz - Last post by tubaman
intermittently missed letter commentator  :-[

 on: April 19, 2019, 02:01:37 PM 
Started by risk_reversal - Last post by Weaver
I use a similar system of 3G / 4G backup but using a Firebrick router. I have a Huawei USB 3G NIC in the router and the mobile data service I use is that from Andrews & Arnold which has very low standing charge and you pay for traffic by the byte. I find it ideal for this.

 on: April 19, 2019, 01:59:06 PM 
Started by kitz - Last post by tubaman
and had decided

 on: April 19, 2019, 12:36:24 PM 
Started by Ignite - Last post by Ignite
Thank You rp00.  I've now got it up and running.

 on: April 19, 2019, 11:19:54 AM 
Started by risk_reversal - Last post by aesmith
Failover should be transparent in terms of not needing any action to initiate.  I'm making the assumption that the TP-Link works the same as any other router with 4G failover in that you configure the interfaces in order of preference, and it will not use the 4G if your primary PPP connection is up and logged in.    It will fail over to a different IP address, so sessions may well not be maintained at the end user level.

In any case if you choose to sign up to Smarty, using this "refer a friend" link from my account will give both of us a free month, I get a free month if you sign up and use the service for 14 days, you get your second month free.

(I used a similar link in the first instance, so paid for the first month and will get the second one free)

 on: April 19, 2019, 10:09:32 AM 
Started by bndwdthseekr - Last post by Weaver
> Should I enable SRA? I can, and have used it before, but I figured why bother if my sync is set so low it will never have to 'adapt' the rate anyway.

You’re of course absolutely right about that. SRA only makes sense if someone has a target SNRM established and is aiming to keep the SNRM and hence the reliability or error rate at a fixed level. However if you at some point we’re to have the opportunity of choosing a fast ISP, one with a variable rate and low target SNRM, then SRA would keep it reliable and healthy as it would simply slow down when conditions got bad rather than getting unreliable and then dropping the connection altogether. Or looked at in the upside down direction, if the SNRM varies during the day, and downstream does vary for most people, if it is low-ish, then you can run the link at the best speed regardless of what time if day it is that you sync in the first place. Most people on low varying SNRMs find that this random pot luck thing, the time if day when you first sync, sets their speed and reliability randomly for days or weeks - until the next resync anyway. So they might feel the urge to choose a ‘good’ time of day to sync if they want speed or a ‘bad’ one if they want reliability. And luckily if course none of this nonsense currently applies to you.

 on: April 19, 2019, 06:52:37 AM 
Started by bndwdthseekr - Last post by bndwdthseekr
I would 'shop for' another ISP if I could... my two options now are Hughesnet, and Frontier. The hughesnet is too high latency to do anything with.... and there's a 30gb monthly cap. I have both right now.

Should I enable SRA? I can, and have used it before, but I figured why bother if my sync is set so low it will never have to 'adapt' the rate anyway.
Code: [Select]
BFR#xdslctl profile --show
The output of the command is :

        G.Dmt   Enabled
        G.lite  Enabled
        T1.413  Enabled
        ADSL2   Enabled
        AnnexL  Enabled
        ADSL2+  Enabled
        AnnexM  Disabled
        VDSL2   Enabled
Phone line pair:
        Inner pair
        bitswap         On
        sra             Off
        trellis         On
        sesdrop         Off
        CoMinMgn        Off
        24k             On
        phyReXmt(Us/Ds) Off/On
        TpsTc           AvPvAa
        monitorTone:    On
        dynamicD:       On
        dynamicF:       Off
        SOS:            On
        Training Margin(Q4 in dB):      226

I would be happy to provide a link to your firmware modder if he thinks he can unlock any hidden gems in the firmware  ;)

 on: April 19, 2019, 05:04:48 AM 
Started by bndwdthseekr - Last post by Weaver
So I read this all wrong before, now I’m seeing the standard Broadcom stats and we are ADSL G.DMT / G.992.1 (‘ADSL1’) the most basic ancient crudest ADSL protocol.

R = 0. Don’t know why, where’s the FEC gone? The answer would seem to be that it isn’t needed as the SNRM is so enormously high - at 19.8dB downstream / 16dB upstream - that there never are any errors.

Also no interleaving.

In the UK we all run much faster, with the fastest speeds the line can take and a low SNRM of 6dB downstream / 6dB upstream (for most domestic users anyway). Some lucky souls such as me can risk 3dB down / 6dB upstream and some business users are 9dB / 9dB (I used to be on that).

So I’m guessing that you are capped at a sync rate of 6944kbps down /1024kbps up.

So a good line which would run dramatically faster at the right target SNRM and with FEC, interleave and hooefully G.INP and/or SRA from Santa.

So if you are ISP shopping then you need this requirements list : (1) G.992.5 ADSL2+ with (2) variable rate and 6dB / 6dB target SNRM, (3) interleaving, (4) FEC on and trellis on (you already have trellis modulation), and very nice-to-haves would be: (5) PTM instead of vile ATM, (6) SRA, (7) G.INP - so an ISP with the last three gets extra plus points. I have 1,2,3,4 and 7 (effectively). No one here seems to have 5 and few have 6.

I have Broadcom-based modems so like yours. Mine are four ZyXEL VMG 1312-B10A units run in modem-only mode and they run custom firmware adapted and enhanced by one of our number here (Kitz user ‘Johnson’). Mine speak G.992.3 (ADSL2) at about 3 Mbps downstream sync / 300-500 kbps upstream sync

 on: April 19, 2019, 03:53:43 AM 
Started by Weaver - Last post by Weaver
I made some actual measurements using the rate counters available from AA’s server. It gives upstream/downstream rate samples and min/avg/max latency figures based on timing the PPP LCP echo request (‘ping’-like) CQM test messages that it sends every second or so.

               Firebrick                                    Individual tx measured         
   Sync   Load   Limitr   measure   meas/lim   1-m/l         mtx1    mtx2    mtx3     mtx4    mtx5
1   528   0.95   443.632   437.200   0.985501   0.014499      437.0   436.7   437.9      
2   519   0.95   436.070   425.633   0.976067   0.023933      424.7   425.9   426.3      
3   376   0.90   299.292   296.900   0.992008   0.007992      296.5   297.8   295.8   296.5   297.9
4   499   0.95   419.265   409.933   0.977743   0.022257      408.9   411.2   409.7

The ‘measure’ column is the measured upstream rate for each line and the ‘Limitr’ column is the intended rates, the rates that are supposed to be imposed by the Firebrick’s upstream rate limiters. All figures are kbps. The rightmost columns are individual speed tests and these were averaged to give the ‘measure’ column (arithmetic mean).

This is an idea that I had which has turned out to be very successful, using a much lower modem loading factor on the slowest line. Note here that line 3 is 90% whereas all the others are 95%. In various tests, this arrangement proved to be superior to all-equal modem loading factors, bearing say the all-96% arrangement.

The results:

* You can see that the true ‘measure’ rates are a bit off, but not hugely. The ‘measure/lim’ column shows the ratio of the two and there is 1-the_aforementioned as a mental aid.

I should perhaps do this again using max() instead of averaging the data points, that would give an idea of the links’ true capacities with the effect of limiters included too if they are kicking in. I thought that the effect of limiters might be to have some overshoot and hunting so that’s why I averaged the data points, because I wanted to see what effective rate the limiters were really trying to find and what the real long term data rate was. However I see now that both would be good.

* I can’t see much of a pattern in the aberrations in ‘measure/lim’. Maybe some are a bit low because I am running the modems ‘too hot’ and the modems themselves are limiting throughput not just the Firebrick.

* I can’t see a lot to be gained here by tweaking loading factors, the percentages. I calculate there is only perhaps ~50kbps more to be had from that type of twiddling,  if very very lucky. But I wouldn’t know how to proceed anyway.

It took about 15 mins to do a backup of my iPad Pro to the Apple iCloud network file system yesterday morning. Felt like forever. Uploading pictures is a nightmare.

* It means anyway that the load splitting thing in the Firebrick really does work and throughput is good.

* I still don’t know what the modem load factors should all be exactly, in that I haven’t say raised them all a bit to try and reclaim some of the last remaining speed, if there even is any to be had, and done this kind of true throughout measurement. I don’t know if 100% or 99% actually doesn’t work at all, or does work but is over the top so that 100% is no faster than say 98%.

* Those numbers are based on calculation of protocol overheads and there may be other real-world timing overheads as opposed to bits bloat overheads, which I don’t know about. I don’t know about the effect of PhyR and what if there is a variable slowdown if it is having to work harder or less hard? A high error rate means so many DTUs get L2-retransmitted n [?] times. I haven’t accounted for that and if it’s variable then I would just have to try and guess. Maybe input buffering in the modem would just handle that anyway and I shouldn’t care about it. One other bad thing is the assumption used in the protocol overhead fraction calculation (to convert sync rate into IP PDU max theoretical rate) of a scenario with a certain size of packet being sent. I chose the max size IP PDU, 1500 bytes in my case, to give the most optimistic and favourable rate. Although that is bad, I have the modem loading factor to bring it down to reality as needed.

However short packets are much less efficient because of the huge overhead - 32 bytes in my case, which is for PPPoEoA, ATM etc. Also, since I am unlucky enough to be using ATM, there is the wobble in efficiency created by the 0-47 bytes unknown additional bloat from ATM cells. If the idiots who ordered the DSLAMs for G.992.3/992.5 had only insisted on PTM support as well, then I could have  used that instead of ATM getting me 10% more speed straight away (minus the small overheads OF PTM). <dream>[And I’ll have a large fries, SRA and G.INP with my PTM too. Ah to hell with it, I’ll ‘go large’ too and have Annex I with that lot as well.]</dream> If there were an application that sent a lot of short packets back-to-back flat out then there would be potential trouble because my numbers would be miles out and a modem loading factor of 95% would not be low enough when protocol overheads could be 50% [!] for very short packets.

I don’t know enough about this, but a rate limiter could have parametrisation to allow it to convert for protocol overheads in a complex way if there were enough parameters.

 on: April 19, 2019, 03:36:09 AM 
Started by bndwdthseekr - Last post by bndwdthseekr
okay, so that's while the tech was working on the unit.... here's my current stats:

Code: [Select]
BFR#xdslctl info --stats
The output of the command is :
/bin/xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    0
Last initialization procedure status:   0
Max:    Upstream rate = 1336 Kbps, Downstream rate = 12172 Kbps
Channel:        FAST, Upstream rate = 1024 Kbps, Downstream rate = 6944 Kbps

Link Power State:       L0
Mode:                   G.DMT Annex A
TPS-TC:                 ATM Mode(0x0)
Trellis:                ON
Line Status:            No Defect
Training Status:        Showtime
                Down            Up
SNR (dB):        19.8            16.0
Attn(dB):        26.0            15.0
Pwr(dBm):        19.8            10.9
                        G.dmt framing
K:              218(0)          33
R:              0               0
S:              1.0000          1.0000
D:              1               1

                        Bearer 0
SF:             2042933         2042886
SFErr:          0               2
RS:             0               0
RSCorr:         0               0
RSUnCorr:       0               0

                        Bearer 0
HEC:            0               1
OCD:            0               0
LCD:            0               0
Total Cells:    568779550               0
Data Cells:     49411669                0
Drop Cells:     0
Bit Errors:     0               0

ES:             0               0
SES:            0               0
UAS:            72              72
AS:             34730

                        Bearer 0
INP:            0.00            0.00
INPRein:        0.00            0.00
delay:          0               0
PER:            0.00            0.00
OR:             32.00           32.00
AgR:            6948.85 1051.89

Bitswap:        0/0             375/375

Total time = 9 hours 51 min 40 sec
FEC:            0               0
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            72              72
LOS:            0               0
LOF:            0               0
LOM:            0               0
Latest 15 minutes time = 6 min 40 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
Previous 15 minutes time = 15 min 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
Latest 1 day time = 9 hours 51 min 40 sec
FEC:            0               0
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            72              72
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 = 9 hours 38 min 49 sec
FEC:            0               0
CRC:            0               2
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0

Code: [Select]
BFR#sh control vdsl 0/0/0
Controller VDSL 0/0/0 is UP

Daemon Status:           Up

                        XTU-R (DS)              XTU-C (US)
Chip Vendor ID:         'BDCM'                   'IFTN'
Chip Vendor Specific:   0x0000                   0x71B0
Chip Vendor Country:    0xB500                   0xB500
Modem Vendor ID:        'CSCO'                   '    '
Modem Vendor Specific:  0x4602                   0x0000
Modem Vendor Country:   0xB500                   0x0000
Serial Number Near:   xxxxxxxxxxx 2911/K9 15.7(3)M3
Serial Number Far:
Modem Version Near:    15.7(3)M3
Modem Version Far:     0x71b0

Modem Status:            TC Sync (Showtime!)

DSL Config Mode:         AUTO
Trained Mode:   G.992.1 (ADSL) Annex A
TC Mode:                 ATM
Selftest Result:         0x00
DELT configuration:      enabled
DELT state:              successful

Full inits:             3
Failed full inits:      0
Short inits:            0
Failed short inits:     0

Firmware        Source          File Name
--------        ------          ----------
VDSL            user config     flash0:23mar2017_39m_B_38u_24o_rc1_sdk_4.14l.04a-j.bin

Modem FW  Version:      4.14L.04A
Modem PHY Version:      A2pv6C039m.d24o_rc1
Trellis:                 ON                       ON
SRA:                     disabled                disabled
 SRA count:              0                       0
Bit swap:                enabled                 enabled
 Bit swap count:         0                       378
Line Attenuation:        26.0 dB                 15.0 dB
Signal Attenuation:      26.0 dB                  0.0 dB
Noise Margin:            19.8 dB                 16.0 dB
Attainable Rate:        12168 kbits/s            1336 kbits/s
Actual Power:            19.8 dBm                10.9 dBm
Total FECC:             0                        0
Total ES:               0                        0
Total SES:              0                        0
Total LOSS:             0                        0
Total UAS:              72                       72
Total LPRS:             0                        0
Total LOFS:             0                        0
Total LOLS:             0                        0

                  DS Channel1     DS Channel0   US Channel1       US Channel0
Speed (kbps):             0             6944             0              1024
SRA Previous Speed:       0                0             0                 0
Previous Speed:           0             6944             0              1024
Total Cells:              0        576105764             0                 0
User Cells:               0         52139749             0                 0
Reed-Solomon EC:          0                0             0                 0
CRC Errors:               0                0             0                 0
Header Errors:            0                0             0                 1
Interleave (ms):       0.00             0.25          0.00              0.25
Actual INP:            0.00             0.00          0.00              0.00

Training Log :  Stopped
Training Log Filename : usbflash0:ciscoext/DSLtrainlog

Pages: 1 [2] 3 4 ... 10