Alternatives to Draytek 2860

Hi guys,

With my continuing saga, some of it may be done to the current Draytek modem/router in use.

Without going into a long winded reason, it appears the Draytek is causing a lot of resyncs by itself, and also logging a lot of errors that just are not seen on the line (according to the engineers test equipment), which it is seeing as a problem and dropping my speeds. It's almost like its performing DLM by itself, which may be a good thing as i guess this would prevent the real DLM intervening if there were problems.

He plugged his meter into the phone socket, whilst i had my laptop plugged into the Draytek.

His tester read 0 ES, and yet the Draytek was pulling in 10+ immediately after connecting.

So, i thought i would maybe try an alternative to see if it is the Draytek.

I have an HG612, and after plugging that in, i get a much lower sync, and with the phone plugged in, i get no CRC errors, but an awful lot of FECS and HEC errors. (Draytek showed a fair amount of FECS but 0 HEC??).

I am considering asking my ISP if they can speak to Openreach about changing me from the ECI cabi am currently on, to a Huawei that is a couple of meters next door to it.

Anyhoo, can anyone recommend a modem or modem/router that can be bridged and that will not be so keen to keep logging errors?

Thanks

I've had good results on an ECI cab with both a Draytek 2850 and a Netgear D7000. The D7000 can be used in modem only mode. It might be worth trying the Netgear modem - DM200, which is Openreach MCT approved.

Edited by caffn8me (Fri 08-Mar-19 23:58:36)

I've had better results with using a DrayTek instead of a HG612 or Broadcom chipset (connected to an ECI DSLAM, sadly). I'm using a 2860Vac and 2862 with no problems (bonded lines), also making sure that they are running reasonably up to date firmware.

Not all lines tend to have the same experience when it comes to using various modems.

Edited by Ixel (Sat 09-Mar-19 10:32:02)

Thanks guys.

After doing a bit more hunting around, it seems it may be the _BT firmware that can sometimes cause issues on ECI cabs.

Not convinced, but i have downloaded the 'standard' non _BT version and will give it a try tomorrow.

Edited by Alucidnation (Sun 10-Mar-19 23:32:10)

Well a bit of an update.

Threw caution to the wind and after reading some positive reviews, i grabbed a Zyxel VMG1312 B10A and plugged that in.

I know each case is different, however, still getting errors, albeit at a lightly less amount and a couple of different types.

Quick copy & paste..

Total time = 4 hours 51 min 52 sec
FEC: 0 2
CRC: 7183 0
ES: 83 0
SES: 15 0
UAS: 393 378
LOS: 0 0
LOF: 11 0
LOM: 13 0

On the Draytek, many 10's of thousands of FEC errors up and down, but no LOF or LOM or SES (from memory).

However, DS CRC on the Zyxel are quite a bit more along with the others.

Is this due to being a different chipset?

Also 'since link time'.

Is this time from when the dsl connection was made?

System time is showing nearly 5 hours and i havent rebooted.

Having said that, i did see a retrain reason of 4 when i went in via CLI.

Would that be something to do with the lower link time?

What is reason 4?

Edited by Alucidnation (Wed 13-Mar-19 15:31:16)

FEC errors are generally nothing to worry about, as they aren't service impacting. However, it may be an indicator of an underlying fault on the line. I was at an address quite a bit of time ago where I had odd results between Broadcom and Lantiq. Broadcom would shoot up in CRC errors constantly while DrayTek (Lantiq) handled it fine. The underlying fault was never fully resolved but was possibly blamed on old underground cables.

The Lantiq chipset might be better at handling errors in your case, making them FEC errors more than CRC errors. If you're on fastpath, Lantiq wil also apply FEC (R: 16) on the downstream where Broadcom won't. This is a low level form of error correction with a possible minor impact on sync rate but won't affect latency. How much it can effect sync rate depends on the distance and quality of the line itself. It doesn't surprise me that the Broadcom has SES, LOM and LOS.

At my old address, I had an odd experience too. The engineer's tester modem indicated no problems where my Broadcom device did. However, when he plugged into the master socket via the port instead of via the attaching crocodile cables from his tester to the pair of wires for the line his tester then showed a similar number of errors. Credit to him he tried his best and spent two days pretty much finding the best pairs along the route and also tried changing filters (which I did). He improved the line but the underlying problem remained in some form. Thankfully I no longer live there.

Edited by Ixel (Wed 13-Mar-19 15:41:43)

Must admit, Im not surprised.

I guess the old Openreach network is slowing starting to fall apart!

Any, complete stats..

VDSL Port Details Upstream Downstream
Line Rate: 15.677 Mbps 60.340 Mbps
Actual Net Data Rate: 15.654 Mbps 60.246 Mbps
Trellis Coding: ON ON
SNR Margin: 6.0 dB 6.3 dB
Actual Delay: 0 ms 0 ms
Transmit Power: 6.8 dBm 6.9 dBm
Receive Power: -6.4 dBm -8.3 dBm
Actual INP: 0.0 symbols 0.0 symbols
Total Attenuation: 0.0 dB 18.5 dB
Attainable Net Data Rate: 15.680 Mbps 60.341 Mbps
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 1.9 26.5 43.7 N/A N/A 13.2 34.8 55.5
Signal Attenuation(dB): 1.9 26.3 43.6 N/A N/A 18.4 34.5 55.6
SNR Margin(dB): 6.0 6.1 6.0 N/A N/A 6.3 6.2 6.2
TX Power(dBm): -4.6 -19.0 6.5 N/A N/A 10.0 7.3 7.4
====================================================================================

VDSL Counters

Downstream Upstream
Since Link time = 9 min 29 sec
FEC: 0 2
CRC: 81 0
ES: 69 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 3 min 26 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: 2 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 5 hours 18 min 26 sec
FEC: 0 2
CRC: 7185 0
ES: 84 0
SES: 15 0
UAS: 393 378
LOS: 0 0
LOF: 11 0
LOM: 13 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
Total time = 5 hours 18 min 26 sec
FEC: 0 2
CRC: 7185 0
ES: 84 0
SES: 15 0
UAS: 393 378
LOS: 0 0
LOF: 11 0
LOM: 13 0

Hmmm, just gone into CLI (messing about really), and noticed in there that the since link time is different from the GUI log...

xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 4
Last initialization procedure status: 0
Max: Upstream rate = 15673 Kbps, Downstream rate = 60310 Kbps
Bearer: 0, Upstream rate = 15654 Kbps, Downstream rate = 60246 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 6.0
Attn(dB): 18.5 0.0
Pwr(dBm): 6.9 6.8

VDSL2 framing
Bearer 0
MSGc: 18 14
B: 239 238
M: 1 1
T: 64 57
R: 0 16
S: 0.1268 0.4859
L: 15144 4198
D: 1 1
I: 240 255
N: 240 255

Counters
Bearer 0
OHF: 9702668 431180
OHFErr: 82 0
RS: 0 3745536
RSCorr: 0 2
RSUnCorr: 0 0

Bearer 0
HEC: 98 0
OCD: 7 0
LCD: 7 0
Total Cells: 2289232223 0
Data Cells: 27031544 0
Drop Cells: 0
Bit Errors: 0 0

ES: 85 0
SES: 15 0
UAS: 393 378
AS: 19762

Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 2.03 6.95
OR: 94.28 23.01
AgR: 60340.29 15677.14

Bitswap: 179/180 5/5

Total time = 5 hours 38 min 18 sec
FEC: 0 2
CRC: 7186 0
ES: 85 0
SES: 15 0
UAS: 393 378
LOS: 0 0
LOF: 11 0
LOM: 13 0
Latest 15 minutes time = 8 min 18 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: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 5 hours 38 min 18 sec
FEC: 0 2
CRC: 7186 0
ES: 85 0
SES: 15 0
UAS: 393 378
LOS: 0 0
LOF: 11 0
LOM: 13 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 = 5 hours 29 min 21 sec
FEC: 0 2
CRC: 82 0
ES: 70 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0

Hi guys,

Running DSL stats at the moment, and i noticed a 'blip' on my connection graph at around 5pm.

Would this contribute to errors on the line?

https://thumbsnap.com/kSdTRNZU

Also, my crc error count is somewhat 'substantial' i think?

https://thumbsnap.com/Esct0QPz

Thanks

Can you post the SNRM graph from the same time.
That's a huge drop in the attainable on the graph but it has gone back to normal now.

DLM counts ES, not CRC's.
Both are low for a line running fastpath.
DLM allows up to 2880 or 1440 ES (depending on the DLM profile your ISP uses) per 24 hours of uptime before taking action to stabilise the line (interleaving). You're well short of that.

Try installing the Vector4 firmware instead of the BT one. Works for me on lines where it starts resyncing on a regular basis.

In reply to a post by j0hn83:

Can you post the SNRM graph from the same time.
That's a huge drop in the attainable on the graph but it has gone back to normal now.

DLM counts ES, not CRC's.
Both are low for a line running fastpath.
DLM allows up to 2880 or 1440 ES (depending on the DLM profile your ISP uses) per 24 hours of uptime before taking action to stabilise the line (interleaving). You're well short of that.

Hi John,

Thanks for the info.

Unfortunately, that was one of the first days i had installed DSL Stats and didn't have the snapshots set up properly.

Having said that, so far things have been reasonably stable!

In reply to a post by jabuzzard:

Try installing the Vector4 firmware instead of the BT one. Works for me on lines where it starts resyncing on a regular basis.

Thanks.

One of the guys on the Draytek forum posted an alternative MDM2 firmware for me to try.

However, at the moment i'm running a Zyxel modem so that i can monitor the connection with DSL Stats.

Once everything is settled, i may drop back to the Draytek and give it another go.

Did that drop coincide with a landline phone call? That would be normal.

Though the drop in both actual and attainable upstream at the end suggests a re-sync. But the downstreams reverted to previous. Capped?

In reply to a post by RobertoS:

Did that drop coincide with a landline phone call? That would be normal.

Though the drop in both actual and attainable upstream at the end suggests a re-sync. But the downstreams reverted to previous. Capped?

Just gone back through my fault ticket and yes, that was the day an engineer was supposed to do a lift and shift but didn�t.

Three hours later I went out and found him in his van parked up at the end of the road relaxing.

Having read through the firmware update notes I get the feeling that what has happened is that the modem code went through the illegal BT SIN 498 approval process and Draytek have been pushing that as the default in the UK. Meanwhile the modem code has undergone further improvement but in the UK they are sticking with the illegal BT SIN 498 code by default because of the significant cost of putting the new modem code through the illegal BT SIN 498 certification process.

Looking at the notes on the UK and other Draytek sites around the world the latest option for the modem code is the Vector 4 (579F17) firmware.

For a while I had just stuck an ECI Openreach modem in the way on WAN2 (just what I had to hand), to overcome the issue but with the new firmware 3.8.9.4 firmware that came out at the beginning of March I decided to try it with the Vector 4 firmware as it has both G.998.4 and G.998.5 support (aka G.INP and vectoring).

Before the upgrade I took out the ECI Openreach modem and tried it on the 576D17 firmware for the illegal BT SIN 498 and it was still giving issues with dropping sync every few minutes. It was on the 3.8.9.3_BT firmware at this point. I loaded the Vector 4 firmware and rebooted. It's been up for about a week now without dropping sync.

Read from this what you will, but my take away is if you are having problems with a Draytek loosing line sync switching to the Vector 4 firmware should be your first port of call. Certainly looks to have worked for me. Well for my sister I use an Edgerouter X-SFP with UniFi AP-LR and a HG612-3b, both powered via 24v passive PoE from the Edgerouter.

Please could you tell us what is illegal about SIN 498?

Because we are still in the E.U. While we remain members of the E.U. it is against E.U. law for a telecommunications operator to run a compliance scheme like this. BT/Openreach do not have the legal authority to run such a scheme with the threat of disconnection for equipment that does not meet their specification.

Simply put it's not much of a single market if every telecommunications operator in the E.U. is running their own certification scheme. As such certification is now done at an E.U. wide level. There is no if's and no but's it's illegal.

Which EU law, regulation or directive is that please?

Well first off some common sense tells you that it is not much of a single market if you say make a telephone, or modem etc. and have to have it approved in every single country of the E.U. Freedom of movement of goods, people, capital and services are the four fundamental pillars of the E.U. If I cannot freely move my VDSL router from Germany to France to the UK then the single market is broken. All those E.U. directives are about removing the barriers to those fundamental freedoms.

Secondly some more common sense would say "What happened to all those green BABT approved stickers?" The short answer being this is now all handled at an E.U. level and a national sticker standard was not compatible with the single market and was consequently terminated.

However specifically 1999/5/EC, 2002/21/EC, 2014/53/EU and 2017/1354 covers it.

It will all shortly be moot, but right now the threat of disconnection is illegal. It's perfectly permissible for BT/Openreach to have a testing program for equipment to ensure it works optimally with their network. What they cannot legally do is threaten or actually disconnect you for not using equipment tested by themselves. As they do threaten disconnection BT SIN 498 is illegal under E.U. law.

The EU BEREC guidelines regarding terminal equipment are in relation to provision of an �internet access service�, which is technically not something that Openreach sells to CPs, it purely provides an access service from the customer premise to the handover point of the nearest fibre serving exchange. So that moves the liability onto your ISP who are providing the IAS, however given their contract with OR mandates the MCT process they are somewhat hamstrung in rectifying if OR decide that it is causing issues.

There is also reference to an �objective technological necessity� to mandate obligatory equipment. Given that OR have had issues in the past with uncertified devices causing issues with their DSLAMs (eg the notorious Asus DSL-AC68U) and monitoring systems I don�t think it is as cut and dry as MCT equals a direct contravention. I can�t see a national regulator raising a case where the user connects a device which fails to meet the published technical specification (which a lot of devices do not adhere 100%, especially in the OAM fault diagnosis space), impairs access for other users who are using compliant devices and is then cut off. Given that reporting details on CPE model/manufacturer/firmware to the DSLAM is part of the SIN spec, it is quite easy for OR to determine which devices are and are not compliant.

I think you are reading more in to the "single market" than is required.

Hi Alucidnation, info about my experiences testing various modem to my 900 meter away ECI cabinet. I tried to do tests as scientifically as possible but by the very nature of line noise which can be there one moment and not the next means one has to make a best guess at the results by averaging over several weeks and turning modem on and off when swapping causes my line to slow down by going into interleaved mode. Interleaving takes 3-5 weeks to go. When I first got FTTC around March 2013 about 38down/7.5up Mbits now six years later around 31down/7up Mbits. Even with same modem I've watch the line gradually slow down.

I've tested:
BT's standard supplied modem in 2013,
Plusnet Hub One,
Netgear D7000 version 1,
Draytek Vigor 130

The worst was Netgear router D7000 v1, I found out it uses the Broadcom chip which is probably better suited to Huawei cabs.

Next worst, BT's standard modem, I guess because it designed several years before all the other modems.

Joint best modems: Draytek Vigor 130 and Plusnet Hub One. The Draytek has slightly better up speeds. The Plusnet has slightly better down speeds.

I mainly use Draytek as it gives all the diagnostic details plus better up speed. The Plusnet is all locked down.

BTW did you use the same modem cable as the engineer? So many standard supplied modem cables are low quality. You want to use Cat5e or better cable and have as short as possible and at least 3 inches away from mains power.

OK,

Got up this morning to these...

https://thumbsnap.com/tUtPFtHG

https://thumbsnap.com/7lAzKKCg

https://thumbsnap.com/9X4bjDet

https://thumbsnap.com/hokjeVoH



Average error rates by day

23 Mar 2019
CRC errors per hour: 8.26 Down, 0 Up
FEC errors per hour: 0 Down, 0.15 Up
HEC errors per hour: 1.62 Down, 0 Up
ES per hour: 5.16 Down, 0 Up
SES per hour: 0 Down, 0 Up

22 Mar 2019
CRC errors per hour: 29.9 Down, 0 Up
FEC errors per hour: 0 Down, 0.29 Up
HEC errors per hour: 16.0 Down, 0 Up
ES per hour: 7.83 Down, 0 Up
SES per hour: 0 Down, 0 Up

21 Mar 2019
CRC errors per hour: 12.4 Down, 0 Up
FEC errors per hour: 0 Down, 0.11 Up
HEC errors per hour: 14.6 Down, 0 Up
ES per hour: 8.91 Down, 0 Up
SES per hour: 0 Down, 0 Up




VDSL Counters

Downstream Upstream
Since Link time = 4 min 55 sec
FEC: 1 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 10 min 16 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 = 19 hours 40 min 16 sec
FEC: 1 0
CRC: 0 0
ES: 145 0
SES: 10 0
UAS: 38 28
LOS: 1 0
LOF: 7 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 0 0
ES: 203 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Total time = 1 days 19 hours 40 min 16 sec
FEC: 1 0
CRC: 0 0
ES: 672 1
SES: 10 0
UAS: 67 57
LOS: 1 0
LOF: 7 0
LOM: 0 0
====================================================================================

Edited by Alucidnation (Sat 23-Mar-19 06:58:11)

Hi guys,

Just to bring this to a close, engineer did a lift and shift to a different card and so far all seems good.

Sync back to around 69 with greatly reduced errors although there are still a reasonable amount.

Not enough to alter fly dlm though.