Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: kitz on September 08, 2014, 01:32:42 AM
-
ASUS has now entered the vDSL modem/router market with the ASUS DSL-AC68U (http://www.asus.com/Networking/DSLAC68U/)
New for sale from today at broadband buyer (http://www.broadbandbuyer.co.uk/products/19269-asus-dsl-ac68u/). The Price at £202.69 may be a bit too steep for some though :(
Dual-Band Wireless-AC1900 Gigabit ADSL/VDSL Modem Router
Dual-purpose wireless router and DSL modem, featuring DSL WAN port and switchable Ethernet WAN/LAN ports in a single space-saving device
Compatible with ADSL2/2+, ADSL, VDSL2, fiber and cable services for complete future-proofing
Combined maximum data rate of 1900 Mbps allows smooth streaming of 4K/UHD videos, online gaming or other bandwidth-intensive tasks
Dual dedicated CPUs for wired and wireless connections to maximize both range and stability
AiRadar with universal beamforming optimizes signal strength in any direction to give up to 150%* coverage and is backward compatible with 802.11a/b/g/n clients
Multi-purpose USB 3.0 port supports file sharing, printers, 3G/4G dongle sharing and media streaming — with up to 10 times faster data transfer than USB 2.0
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.asus.com%2Fmedia%2Fglobal%2Fproducts%2Fa1hV6dbr0aJWiWD9%2Ft0yoA65U4uPoupjx_setting_fff_1_90_end_500.png&hash=cbefb662dfd9bfdf1df2d3f3701722737a5cb335)(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.asus.com%2Fmedia%2Fglobal%2Fproducts%2Fa1hV6dbr0aJWiWD9%2Fz3UWk5TuAVN33DGm_setting_fff_1_90_end_500.png&hash=1f7fb4649913cf374e36c06a4514837d3c667db4)
-
A couple of things people ought to consider if they are thinking of purchasing it. For some each listed item might be a deal breaker.
It has only has 1x USB port although it is a USB 3 as opposed to 2 x USB ports (USB 2 and USB 3) on the ASUS RT-AC68U.
At present ( 9th September 2014), there is no 3rd party firmware (tomato, DD-WRT, Asuswrt-merlin) available to flash it for more advanced features.
-
I noticed yesterday the fact that it only had one USB port and also that its lost the dedicated WAN port when compared to the RT-AC68U.
I suppose its biggest selling point by far will be the fact it works on both ADSL & VDSL by having an integrated DSL modem.
There is little choice for UK consumers looking to purchase a VDSL modem/router and this is one of the very few that will fit the bill.
-------
ETA
The rumour is that it contains a Lantiq chipset.
-
also that its lost the dedicated WAN port when compared to the RT-AC68U.
I missed that. At this price point I think they have thrown away flexibility. Perhaps they thought people who would be purchasing it did not care and were just run of mill punters who just want to plug and play without thinking about it. Having said that BT Open Reach (Kelly communications) seem to be doing the installs for ISPs (in my area with talktalk they are) and they fit a separate VDSL Modem even if the router supplied (HG635) has its own integrated VDSL Modem.
-
At this price point I think they have thrown away flexibility.
No doubt one of the LAN ports will also be an uplink port, so just like the vast majority of other DSL routers, its no big deal.
If youre buying for DSL then its not really a loss of switch ports as you'd still have 4 LAN. Its not the router you'd buy anyhow if you had cable, but the flexibility is still there, just you'd only have 3 LAN.
From the photos its obvious that the dedicated WAN port has been removed to make way for the DSL port. No idea why they removed the USB2 port though.
-
My new Asus AC68U coming tomorrow as I am going pick it up at pcworld
Store collection item(s)
Quantity Product code Product price Total
ASUS - DSL-AC68U Wireless Router - AC1900 Dual Band 1 113929 £ 119.99 £ 119.99
Cost of products and services £ 119.99
Total cost £ 119.99
VAT (included) £ 26.66
So, I save £40 off with voucher! :P ;D
-
£40 off is a good deal. Even at £159.99 thats still quite a lot cheaper than broadband buyer.. which is highly unusual.
What also worries me is that broadband buyer is advertising it as VDSL2/ADSL2+ modem router, yet theres no mention of VDSL on PCWorld... nor even ADSL when it comes to that.. not even where they list the ports... and its about the price youd expect to pay for the cheaper RT version. Just double check when you pick it up that it is VDSL modem router and not an RT-AC68U.
The ASUS site definitely specifies the DSL-AC68U as being a VDSL/ADSL modem router (http://www.asus.com/Networking/DSLAC68U/)
Dual-Band Wireless-AC1900 Gigabit ADSL/VDSL Modem Router
VDSL2/ADSL2+/ADSL2/ADSL multimode
Up to 100Mbps/100Mbps upstream/downstream
Support Annex A/B/I/J/L/M
Support all VDSL2 profiles -8a, 8b, 8c, 8d, 12a, 12b, 17a and 30a
VDSL2 interface compliance with ITU-T993.2
G.992.1 (G.dmt), Annex A, and B Compliant
G.992.2 (G.lite), Annex A, and B Compliant
ANSI T1.413 Compliant
G.992.3 (ADSL2) Compliant, Annex A, B, L, and M
G.992.5 (ADSL2+) Compliant, Supporting Annex A, B, and M
G.993.2 Compliant, Annex A, B, up to profile 30a with external AFE.
G.993.5 (Vectoring)
ATM and PTM (dual-priority)
-
Looking at the firmware for the DSL-AC68U, it really must have two CPUs. The firmware contains two squashfs filesystems, one containing a set of programs compiled for an ARM cpu, and the other filesystem, the one with the DSL driver, contains another set of programs compiled for a MIPS cpu.
The picture of the back of it on pcworld.co.uk does show the DSL port.
-
Thanks Kitz
I check on pcworld site as it does metion spec: Model DSL-AC68U (that should be VDSL modem/router) I will check the model label tomorrow if it was RT, will not buy it. If it was DSL-AC68U then I buy it.
Updated:
I am now not buying it cos someone from overclockers say this VDSL cause DLM because of increasing CRC errors. http://forums.overclockers.co.uk/showpost.php?p=26933594&postcount=55
-
I am now not buying it cos someone from overclockers say this VDSL cause DLM because of increasing CRC errors
Thanks for bringing that to our attention.
I'm not impressed with this router - whether it's because I was testing and had swapped over between the OR modem and the DSL-AC68U a few times, or had a dodgy RJ11 that caused a load of CRC errors, but DLM kicked in an forced some interleaving on my line for couple of weeks back on the OR modem.
ECI cabinet - the DSL consistently syncs 3 - 4Mbps lower on downstream but upstream rate is higher by about 2 - 3Mbps compared to the ECI modem.
I may wait for another firmware update before trying the DSL-AC68U again - for the moment I'm back with the RT-AC68U and OR modem combination which is stable for me for weeks on end.
In all fairness he did say he wasnt sure if it was because he was testing. We've seen members here who have fallen to the same DLM trap purely because of testing and swapping routers, so it would be interesting to see how that developed.
I must say though that I was surprised earlier when you mentioned you were buying this.. especially in view of your opinions on the DSL-N66U which contains a similar MediaTek chipset.
I have mentioned to you a few times that in view of your line being similar to mine (after it went live) that you may be best looking at one with a Broadcom chipset.
You'll find that most of the regs on here like the stability & performance of the Broadcom chipsets and we believe chipset to be an important factor when it comes to DSL performance. Its also why Ive specifically listed chipset information in the list here (http://forum.kitz.co.uk/index.php?topic=14436.0).. but I'll spell it out again.. try looking for a combined unit with a BCM chipset. Youve already seen that the MediaTek & Lantiqs dont perform quite as well on your line.
-
It looks like the DSL-AC68U uses a Broadcom chip for its WiFi. That's in the ARM part.
If you can get telnet access to a shell, to the MIPS part, there are commands such as wan and adslphxcmd and its always worth looking under /proc/ for anything interesting. There are various references to tc3162 - tc presumably indicating TrendChip. The RaLink and TrendChip companies merged and the resulting company is now called MediaTek.
-
If you can get telnet access to a shell, to the MIPS part, there are commands such as wan and adslphxcmd and its always worth looking under /proc/ for anything interesting.
ok heres a list what do i need to do.
ASUSWRT DSL-AC68U_3.0.0.4 Mon Aug 25 03:53:12 UTC 2014
admin@DSL-AC68U:/tmp/home/root#
3ginfo.sh du lsmod setconsole
ATE e2fsck lsusb setup_dnsmq
[ eapd madwimax setuprsa.sh
[[ ebtables md5sum sh
acsd echo mdev sigmon
ad egrep memalloc sleep
add_account ejusb minidlna smbd
add_folder email miniupnpd smbpasswd
add_multi_routes emf mkdir sort
adslate env mke2fs spectrum
afpd epi_ttcp mkfs.ext2 strings
afppasswd et mkfs.ext3 swapoff
app_base_library.sh ether-wake mkhfs swapon
app_base_link.sh expr mknod switchmode
app_base_packages.sh ez-ipupdate mkntfs sync
app_cancel.sh fdisk mkswap sysinfo
app_check_folder.sh fgrep mod_account syslogd
app_check_pool.sh find mod_folder tail
app_fsck.sh find_modem_node.sh modem_enable.sh tar
app_fsck_all.sh find_modem_type.sh modem_signal.sh taskset
app_get_field.sh firmware_check modify_if_exist_new_folder tc
app_init_run.sh flock modprobe tcpcheck
app_install.sh free more telnet
app_move_to_pool.sh free_caches mount telnetd
app_remove.sh fsck.ext2 mt-daapd test
app_set_enabled.sh fsck.ext3 mtd-erase2 test_disk1
app_stop.sh fsck.minix mtd-unlock test_disk2
app_switch.sh fsync mtd-write2 test_endian
app_update.sh ftpget mv test_if_exist_account
app_upgrade.sh ftpput nas test_if_exist_share
arp gctwimax netstat test_of_var_files
arpstorm gencert.sh netstat-nat test_share
ash get_account_list networkmap test_system
asus_lp get_all_folder nice tftp
asus_sd get_apps_name nmbd top
asus_sg get_folder_list nohup touch
asus_sr get_permission nslookup tp_init
asus_tty get_phy_speed ntp tr
asus_usb_interface get_phy_status ntpclient traceroute
asus_usbbcm get_var_file_name nvram traceroute6
asuswebstorage gpio nvram_erase true
auto_det grep openssl tune2fs
auto_macclone gunzip openvpn u2ec
autodet gzip ots udevtrigger
avahi-daemon halt pc udhcpc
awk head pidof udpxy
basename hotplug ping umount
bcrelay hotplug2 ping6 uname
blkid how_many_layer pppd uniconv
brctl httpd pppoe-relay unzip
busybox hub-ctrl pptpctrl updown.sh
cat icon.ico pptpd uptime
chat icon.large.ico preinit uqmi
check_spectrum.sh ifconfig printf usb_modeswitch
chk_app_state igmpproxy ps usb_notify
chkhfs igs psta_monitor usbled
chkntfs infosvr public.pem usbtest.sh
chmod initial_all_var_file push_log usleep
chown initial_folder_list pwd vconfig
chpasswd initial_var_file radio vi
chpasswd.sh inotify radvd vsftpd
clear insmod rc wanduck
cmp ionice rcheck watch
cnid_dbd ip rdnssd watchdog
cnid_metad ip6tables read_sms wc
comgt ip6tables-restore readlink webs_update.sh
console iptables reboot webs_upgrade.sh
cp iptables-restore renice wget
create_if_no_var_files iptables-save req_dsl_drv which
crond kill restart_wireless wimaxc
cru killall rm wimaxd
cut klogd rmdir wl
date l2tp-control rmmod wlcconnect
dbd l2tpd route wlconf
dd led_ctrl rsasign_check wlcscan
ddns_updated less rstats wpa_cli
del_account lighttpd run_app_script wpa_supplicant
del_folder lighttpd-arpping run_pptpd wps_monitor
df lighttpd-monitor run_telnetd wpsaide
dhcp6c lld2d scsi-start write_3g_ppp_conf
dhcp6s lld2d.conf scsi-stop write_smb_conf
dirname ln sdparm write_webdav_conf
disk_monitor logger sed xtables-multi
disk_remove login send_sms zcat
dmesg lpd service zcip
dnsmasq ls set_permission
-
Im not a linux bod so perhaps others may be able to suggest some more commands, but the usual one to try first is
cat /proc/cpuinfo
-
This was also posted on the plusnet forum (https://community.plus.net/forum/index.php/topic,131806.32.html), in summary we haven't yet figured out how to get to a shell inside the MIPS part with the DSL modem, but some of the DSL stuff has been stored under /tmp/adsl/ - I think most of it is available from the web interface anyway.
-
ok thanks - I hadnt been to the PN forum for a few days :)
-
Hi guys, i'm planning to purchase this from COMPUTERUNIVERSE (ID: 90562684, SKU: 90IG00V1-BM3G00 ) and was wondering if it will match adsl and vdsl standards here in Canada wich usually are the same for uk.
asked seller if This device is global produced by Asus , or produced only for Germany but answer was not clear.
can someone help with this?
kindest regards
-
Hi.
Id hate to say for sure but if you look at the specs on the asus website (http://www.asus.com/Networking/DSLAC68U/) it says
VDSL2/ADSL2+/ADSL2/ADSL multimode
Up to 100Mbps/100Mbps upstream/downstream
Support Annex A/B/I/J/L/M
Support all VDSL2 profiles -8a, 8b, 8c, 8d, 12a, 12b, 17a and 30a
VDSL2 interface compliance with ITU-T993.2
G.992.1 (G.dmt), Annex A, and B Compliant
G.992.2 (G.lite), Annex A, and B Compliant
ANSI T1.413 Compliant
G.992.3 (ADSL2) Compliant, Annex A, B, L, and M
G.992.5 (ADSL2+) Compliant, Supporting Annex A, B, and M
G.993.2 Compliant, Annex A, B, up to profile 30a with external AFE.
G.993.5 (Vectoring)
Which implies that it is one global unit and should work in US, Europe and the UK (UK doesnt use same as Germany).
The only problem I can foresee is the power supply & plug will be different if you are purchasing from Germany.
AC 120/230 V (50/60 Hz)
-
in the box was shipped 2 different connectors that you would slide into place one for uk plugs and the other for other countries.
when using command wl country it says its german. i have no idea why it says this. i believe this can be changed
Since using the latest firmware 3.0.0.4.376_2072 i have had no problems with disconnections.
-
thanks guys, igonna take a chance and if not working, i will use it as a simple router in bridge mode with my actual vdsl modem.
ps: here is the response i had from asus north america.
ASUS CASEID=RWTM20140927195421239-172
Dear Mohand,
Thank you for contacting ASUS escaltion mail box.
Regarding about your technicial question about the Router you are instersted to buy in Germany, unforunately we cannot confirm and assist with your question. The reason being is this part No. is not carried by ASUS North America so we have very limited access to check all the specifations and confirm this for you.
However please be advised that Router product does not have global warranty which means you will not be getting Technicial and Warranty Support within Canada for router purchased in Europe.
Thanks and best regards,
Jennie Yao | ASUS Canada
---------- Original Message ----------
From : aitmatouk1@gmail.com
Sent : 9/27/2014 11:54:21 AM
To : "techsupport@asus.com"
Subject : <TSD> Satisfaction-CAN(EN) : product compatibility dsl-ac68u
[CASEID=WTM20140927195421239]
Apply date : 2014/09/27 11:54:21(UTC Time)
[Contact Information]
Name : Mohand Ait matouk
Email Address : aitmatouk1@gmail.com
Country : Canada
[Product Information]
Product Type : Networking
Product Model :
Product S/N :
[Comment]
Subject : product compatibility dsl-ac68u
Topic : 3. Others
Description :
Hi, sorry to use the complaint category but i did not find another way to contact you
about my concern.
i'm planing to buy this product (ASUS 90IG00V1-BM3G00
ASUS DSL-AC68U AC1900 VDSL) from Germany and would like to know if it's a
global product wich will match vdsl and adsl standards here in Canada or if it will
operate only in Germany.
Thanks in advance for your help.
-
After days of unstable connections I randomly disabled UPBO (Upstream Power Back-Off) in the DSL settings and its been rock solid for almost 15hrs now albeit subject to DLM due to the previous instability.
Does anyone know if this should be on or off, by default on this box its on.
ASUS support haven't responded to this question.
-
It should be on - In fact I wasnt aware it was a configurable option, I wonder if it is in other modems?
Upstream Power Back Off is defined in the DSL standards (iirc adsl2 and above) and its one of the requirements listed in the BT document which they test when certifying a modem/router for use by UK ISPs.
It would be interesting to have seen your bitloading with it both on and off, just to have seen the difference, but I dont think you can graph it from the ASUS.
what are the implications of me setting it to off?
hmmmm.. increased bitloading?
The question really should be what are the implications for your neighbouring lines. UPBO is there and used by BT to help prevent cross-talk. If you have a router where the setting is OFF and everyone else is using UPBO then theres a possibility that your line could drown out some of their tones. If everyone turned of UPBO, then as a whole VDSL speeds would be much lower and rather unbalanced depending upon line length. If a short line didnt have UPBO then it would certainly have some impact on any longer lines.
-
I can't see it as an option anywhere in my Billion 8800NL.
-
Nope, me neither.
On my Zyxel, although its listed as a feature for VDSL compliance in the system specs, I cant find an option to configure it.
I certainly dont recall seeing it either on the TPlink, but thats hardly surprising since in comparison to some other routers, it lacks features.
Ive had a look in the CLI to see what I can config, but theres nothing there listed with all the other similar group type features such as phyR and SRA
bitswap On
sra On
trellis On
sesdrop Off
CoMinMgn Off
24k On
phyReXmt(Us/Ds) Off/On
TpsTc AvPvAaPa
monitorTone: On
dynamicD: On
dynamicF: Off
SOS: On
Training Margin(Q4 in dB):
-
no UPBO on FTTC means newtron and co get no upstream bandwidth :/
I think if anyone does that on FTTC they may get disconnected :p
-
no UPBO on FTTC means newtron and co get no upstream bandwidth :/
Yep my thoughts exactly - just think of the problems it could cause if all ASUS owners turned it off. :o I must admit I was a bit surprised to hear to it could be a configurable option.
-
it may be configurable but the dslam may still block it like it blocks SNRM fiddling now.
-
Yep.. which is why I would have liked to have seen bitloading graphs so see how much difference it makes.
-
I'm wondering if it just allows the modem to ignore the BT signals router end. The help tip quotes...
This item allows you to control whether to Enable/Disable UPBO(Upstream Power Back Off) for VDSL. DSLAM could use UPBO to reduce the Tx Power of your xDSL modem router, in some cases abnormal UPBO control from DSLAM could leads to sync up issue(such as not enough Tx Power to sync with minimum rate). Thus with this feature now you could disable UPBO and wont get affected by DSLAM setting.
-
This item allows you to control whether to Enable/Disable UPBO(Upstream Power Back Off) for VDSL. DSLAM could use UPBO to reduce the Tx Power of your xDSL modem router, in some cases abnormal UPBO control from DSLAM could leads to sync up issue(such as not enough Tx Power to sync with minimum rate). Thus with this feature now you could disable UPBO and wont get affected by DSLAM setting.
That is a very interesting quotation. I wonder how long it will be before Beattie notices and "has words" with the manufacturer? :-\
-
This item allows you to control whether to Enable/Disable UPBO(Upstream Power Back Off) for VDSL. DSLAM could use UPBO to reduce the Tx Power of your xDSL modem router, in some cases abnormal UPBO control from DSLAM could leads to sync up issue(such as not enough Tx Power to sync with minimum rate). Thus with this feature now you could disable UPBO and wont get affected by DSLAM setting.
oooh dear.. lol.. Im chuckling here... BT had a fit when users started tweaking SNR Margin.. thats really going to raise their hackles. ;D
I take it that in its current state BT would never pass the DSL-AC68U as an approved VDSL router as per SIN 498. I think we can be pretty damn certain that ASUS hasn't sent one to them for testing and approval.
Im also pretty certain that there's not just BT that would extremely frown upon this.. because PBO is vital for not just VDSL but ADSL too and its why its specifically mentioned in all of the DSL standards. :o
COMPLIANCE REQUIREMENTS.
R.VDSL2.7 The modem shall support Upstream Power Back Off (UPBO) as defined in G.993.2[3]
-
BT threw fits with me when I started overriding their MTU setting on my ADSL connection. I had no choice, their equipment was sending stupidly huge MTU values to my equipment and screwing up my net connection. Forcing the 1492 value at my end made my connection massively more stable, as well as a bit faster. BT didn't want to know that their equipment was misconfigured.
-
Hopefully some progress today...
Not happy with the routers VDSL stability disconnecting every 5-10 minutes unless I disabled UPBO I decided to flash firmware version .2049 firmware, down from .2072.
BINGO!! so far after an 1.5 hours of use, no more random disconnects with the default modem settings.
I notice the DSL firmware in this version is 1.0.1.4 compared to 1.0.1.7 so I suspect this is the issue and have contacted ASUS support about possibly getting the latest router software with the older DSL firmware as a beta test.
Fingers crossed.
-
Thats excellent news - glad that you line is stable again and hope it stays that way :)
Please keep us updated :)
-
....I take it that in its current state BT would never pass the DSL-AC68U as an approved VDSL router as per SIN 498. I think we can be pretty damn certain that ASUS hasn't sent one to them for testing and approval....
Unsurprisingly (as it's the AC68U's little brother), I am 99.9% sure that the DSL-N66U has the Enable/Disable UPBO setting as well. (only 99.9% sure as it's from memory as I had to return it, unfortunately )
-
I can confirm that the DSL-N66U has the Enable/Disable UPBO setting, with options {Auto,Enable,Disable}.
It has the same pop-up help description as quoted earlier.
-
Thanks for the confirmation ... and welcome to both of you :)
-
Sadly after 4 hrs of solid connection the instability returned. I'm back to using the BT HH5 for now having lost faith in the Asus device completely now. Support just go round in circles quoting the same tweaks that don't work.
The Asus is going back to PC World as being unfit for purpose, complete with numerous printouts from other users experiencing the same issue.
???
-
Its not looking to good right now for the Asus modem routers. In view that both models share some similarity then it would appear that ASUS need to pull their finger out and correct the reported issues if they want this router to continue to sell.
As with the DSL-N66U, Ive now added some further comments.
Their (cable) routers such as the RT-N66U seem to get such favourable reviews, but it would appear very badly let down on the DSL side.
Hopefully issues can be resolved with new firmware updates.
---
atm the only ones in the running seem to be Billion & ZyXel winning hands down... with TPlink bringing up the rear. I would have loved to have got my mitts on a TG589vn to test one of those.
TPLink's is stable and good value for its price.. but in all honesty they too could have also had a big flop on their hands. Because I beta tested this unit I was able to give them a lot of feedback which to TPlinks credit they listened to and resolved. They delayed shipping until I'd confirmed the new f/w was stable. But if it had gone on sale in its original state then it too would have been bad on a heck of a lot of lines. If it struggled to maintain my 80/20 line (and caused the DLM to kick in for me), then it wouldnt have been a pretty picture in the wild. It is stable now, but unfortunately the Lantiq chipset doesnt quite seem to be able to match the BCM performance :/ In all fairness they do however appear to match performance of the BToR ECI modems.. and they do seem to be taking my comments very seriously about the lack of linestats.
-
I opted to persevere with the Asus whilst they analysed the data logs I sent them whilst using a HG612 Openreach modem to handle the DSL side of things.
Having a day to myself this weekend I removed the HG612 and reset the Asus and configured as VDSL modem choosing BT Infinity 2 in the set up process. Whilst in the DSL Modem 'tweak' screen I noticed that the last option G.998.4 Improved Noise Protection (G.INP) was by default set to enabled. Now I maybe wrong but isn't this just for Sky curently in the UK. Anyway, I disabled this and so far its like having a different modem. Connection as been solid for an hour and browsing seems snappier.
-
Finally some good news...
Firmware v3.0.0.4.376_693 is stable albeit a downgrade. Asus support think the latest dsl driver is the issue so there will most likely be a new firmware any day soon.
-
:)
-
A further update...
ASUS support asked me to re-flash the most recent firmware (.2072) today and set my DSL Settings as in the attached image.
Note 'bitswap' is disabled.
I've been connected now for almost 8hrs without a single hiccup.
I suspect there's a bug in the latest firmware as enabling bitswap destabilises the connection whereas in the earlier .693 firmware enabling 'bitswap' had no effect.
-
I'm tempted to get one of these but am uncertain about the stability, especially with an ECI DSLAM. The only DSL device to keep my connection fastpath has been the ECI /r modem. Anyway, keep us updated :).
-
Since we discovered bitswap was broken in the last few firmware releases I've been connected almost 34hrs solid. I'm actually synch'ing 72/22 now whereas with the openreach modem would only synch at 62/19. I'm on the same cabinet type has yourself.
-
Since we discovered bitswap was broken in the last few firmware releases I've been connected almost 34hrs solid. I'm actually synch'ing 72/22 now whereas with the openreach modem would only synch at 62/19. I'm on the same cabinet type has yourself.
Oh, very nice! I might order one of these tomorrow then for Saturday delivery. Thanks for the update.
-
Bitswap is one of the requirements specified in BT SIN 498
R.VDSL2.15 The modem shall support bit swap as defined in G.993.2
I think disabling bitswap would at best be a workaround until the problem is fixed properly.
-
Asus are investigating with BT I'm told.
-
I know it's probably slightly off topic, but can someone clarify whether there's a difference between the modem chipset/functionality between the DSL-N66U and the DSL-AC68U? I already own an RT-AC68U and an RT-N66U, I know the differences between those, but obviously not the DSL variant. I assume the modem chipset/functionality is identical.
EDIT: Seem identical, firmware however seems older on the N66U, so I'll go for the AC68U rather than try to save a little bit of money.
-
Apart from the extra usb port and wan port on the DSL-N66U the only real difference is maximum wifi speed. The DSL-N66U is 802.11n up to 900mbps whereas the DSL-AC68U is 802.11ac and theoretically up to 1900mbps.
Both share Broadcom wifi and Mediatek DSL chipsets.
Had I been able to get the DSL-N66U at the time I was purchasing I might have opted for the slightly cheaper N66U as I don't have anything with AC wifi to take maximum advantage of the DSL-AC68U
-
Apart from the extra usb port and wan port on the DSL-N66U the only real difference is maximum wifi speed. The DSL-N66U is 802.11n up to 900mbps whereas the DSL-AC68U is 802.11ac and theoretically up to 1900mbps.
Both share Broadcom wifi and Mediatek DSL chipsets.
Had I been able to get the DSL-N66U at the time I was purchasing I might have opted for the slightly cheaper N66U as I don't have anything with AC wifi to take maximum advantage of the DSL-AC68U
I see. Well I too would go for the DSL-N66U but what concerns me is that it looks like the firmware might be older for the DSL (unless I'm mistaken), so I may have no choice but to either wait and hope ASUS eventually update it, or go for the AC68U.
-
I'd say the DSL-AC68U is probably more future proof if BT start rolling out Vectoring on DSL.
I've seen in the tcconsole diagnostic logs mention of G.Vector
-
do you think it is better to disable bitswap or downgrade the firmware?
-
I downgraded so that my connection was at most compliant with what bt expected. On the DSL-AC68U this was firmware version ending 693.
-
Well I've ordered one from 'broadbandbuyer.co.uk' (used - grade b). Waiting on a confirmation email. Hopefully I'll get it tomorrow as I've paid for Saturday delivery.
-
For a little more PC world have them on the shelf!
I only paid £159.99 new but I think they've gone back up now to £179.99
Just to clarify if your connection is unstable try...
On firmware 2048 upwards disabling bitswap.
However on firmware 693 it's fine to leave it enabled usually, my connection has been rock solid with it on.
-
Yeah, unfortunately PC World is quite a distance from where I am and I don't have a car :P. Broadband Buyer has confirmed the order and sent it to 'packing', so hopefully it'll be sent out today and arrive tomorrow (Royal Mail Special Delivery by 1pm Saturday).
I'll most likely upgrade the router firmware to the latest one and then disable bitswapping prior to plugging in the DSL cable. That should minimise disruptions that DLM may otherwise think is not good. I'll update here on how it goes once I've had time to run the product.
-
PC World have raised the price to £199.99. Think the £159.99 price was a mistake!
Will downgrade the asus tonight and put it back into action. Originally it resulted in DLM reducing my profile from 30M to 20MB
-
tooo pricy for me to buy will await les's results. In the old adsl days when bitswapping was new it had a huge benefit on stability on my adsl line, I remember the speedtouch 546 5.x firmware had no bitswapping and it was a new thing in the 6.x firmware. Also in them days lots of adsl routers had a buggy implementation of bitswapping where it would cease to work after a period of time and when it did stop it was immediatly very noticeable with tones getting stuck at 0db snrm or below without bitswapping to lower the bitloading.
-
PC World have raised the price to £199.99. Think the £159.99 price was a mistake!
That makes me feel lucky
-
Well, 16hours in with using the old firmware and all seems good! :) My original sync speed with the ECI modem was 27196 down, 8496 up. The initial connection with the ASUS last night was 29446 down, 8453 up. At 5am this morning it changed to 29476 and 8281.
If I had been using the latest firmware, DLM would have kicked in by now.
I have however noticed that my line attenuation figures are completely wrong - i.e 0.1db down seems a little off!
I've also sent a note to ASUS about using older firmware, so hopefully a fix will come soon.
Thanks Simon for the tip.
-
Well, 16hours in with using the old firmware and all seems good! :) My original sync speed with the ECI modem was 27196 down, 8496 up. The initial connection with the ASUS last night was 29446 down, 8453 up. At 5am this morning it changed to 29476 and 8281.
If I had been using the latest firmware, DLM would have kicked in by now.
I have however noticed that my line attenuation figures are completely wrong - i.e 0.1db down seems a little off!
I've also sent a note to ASUS about using older firmware, so hopefully a fix will come soon.
Thanks Simon for the tip.
That's great to hear. It's equally interesting that the ASUS so far (from all I've read via Googling) seems to produce higher sync speeds, particularly on the downstream, than the ECI /* and HG612 modems. Mine is out for delivery this morning so should get it later in the morning. I can't wait! I will update it to the latest firmware, disable bitswapping, and go from there. If it remains stable for at least 24 hours then I'll play around with the settings, of course being cautious of re-syncing too often due to DLM. I'm eager to see if I can adjust the tx power to reduce the attainable upstream and slightly increase the attainable downstream, as with crosstalk in the area I'm now getting around 76Mbps attainable downstream (first started with somewhere over 110Mbps).
-
Yes my figures are all reporting wrong but I figured whilst it's stable it's better than nothing. Glad to know it's stable though. Hopefully a new firmware is being readied for release soon.
-
Well, 16hours in with using the old firmware and all seems good! :) My original sync speed with the ECI modem was 27196 down, 8496 up. The initial connection with the ASUS last night was 29446 down, 8453 up. At 5am this morning it changed to 29476 and 8281.
If I had been using the latest firmware, DLM would have kicked in by now.
I have however noticed that my line attenuation figures are completely wrong - i.e 0.1db down seems a little off!
I've also sent a note to ASUS about using older firmware, so hopefully a fix will come soon.
Thanks Simon for the tip.
That's great to hear. It's equally interesting that the ASUS so far (from all I've read via Googling) seems to produce higher sync speeds, particularly on the downstream, than the ECI /* and HG612 modems. Mine is out for delivery this morning so should get it later in the morning. I can't wait! I will update it to the latest firmware, disable bitswapping, and go from there. If it remains stable for at least 24 hours then I'll play around with the settings, of course being cautious of re-syncing too often due to DLM. I'm eager to see if I can adjust the tx power to reduce the attainable upstream and slightly increase the attainable downstream, as with crosstalk in the area I'm now getting around 76Mbps attainable downstream (first started with somewhere over 110Mbps).
I would personally downgrade the firmware so that bitswap can be used.
-
That was what I opted for just in case the Dslam detected something wasn't quite right.
I'm currently waiting for DLM to start restoring my speeds having fallen foul of it whilst liaising with ASUS. however my synch speed seems to have settled at 75/20 which is much better than both my HH5 and HG612
-
Well, 16hours in with using the old firmware and all seems good! :) My original sync speed with the ECI modem was 27196 down, 8496 up. The initial connection with the ASUS last night was 29446 down, 8453 up. At 5am this morning it changed to 29476 and 8281.
If I had been using the latest firmware, DLM would have kicked in by now.
I have however noticed that my line attenuation figures are completely wrong - i.e 0.1db down seems a little off!
I've also sent a note to ASUS about using older firmware, so hopefully a fix will come soon.
Thanks Simon for the tip.
That's great to hear. It's equally interesting that the ASUS so far (from all I've read via Googling) seems to produce higher sync speeds, particularly on the downstream, than the ECI /* and HG612 modems. Mine is out for delivery this morning so should get it later in the morning. I can't wait! I will update it to the latest firmware, disable bitswapping, and go from there. If it remains stable for at least 24 hours then I'll play around with the settings, of course being cautious of re-syncing too often due to DLM. I'm eager to see if I can adjust the tx power to reduce the attainable upstream and slightly increase the attainable downstream, as with crosstalk in the area I'm now getting around 76Mbps attainable downstream (first started with somewhere over 110Mbps).
I would personally downgrade the firmware so that bitswap can be used.
Does the older firmware still have the DSL settings?
-
Yes. Only real difference is no G. INP.
I found it best to set everything up on 2072 firmware then upload the 693 firmware so as soon as it reboots it's good to go as the ISP detection was hit and miss for Infinity 2.
-
An update to say that I've set it up on the older firmware, bitswapping enabled and such like, nothing fancy yet (mostly default, and Rx AGC set as stable).
Below is a screenshot of my connection (little uptime I know):
http://i.imgur.com/M22eb5g.png (http://i.imgur.com/M22eb5g.png) - ASUS statistics
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F3842505654.png&hash=bac8f8875ac906530b371b8e6f1778f571cb46d1)
Previously on the ECI I was getting around under 80Mbps or so attainable downstream and 28Mbps~ or so attainable upstream, syncing 74/20 connection. It's incredible that the ASUS built-in modem chip is getting a much higher attainable on both downstream and upstream! I just need to hope CRC's (or most importantly the ES, which I can't see sadly) remain below the DLM's threshold, and that sync is stable of course.
EDIT:
Allowing 45 minutes of uptime I had 30 CRC errors downstream before changing UPBO to disabled (as a test). So far with only 13 minutes of uptime with UPBO now disabled the upstream is bugged (0) so I can't tell anything there, upstream power has increased from 8.8 to 9.6, however the CRC errors are higher on the downstream, currently at 51. It may be interesting to play around with the tx power as well, e.g. reduce it in order to potentially help downstream, with so much spare SNRM on the upstream (18dB~ before I disabled UPBO as a test) sacrificing some to help downstream might be a good idea, if it works that is.
For the curious (I believe kitz wanted to know the difference in bitloading and SNR graphs between UPBO being enabled and disabled):
Before...
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FOAoHsNA.png&hash=d50c1eb0314002789aae423c133b988dc7e27dee)
After...
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FF91A9EW.png&hash=84fd4502651249027abb673286631ee53ee9e17c)
-
Well sadly you got no US snrm data on your graphs and the bitloading is same on boths indicating its making no difference, but you said the US snrm increased with US backoff disabled?
It looks like in both your graphs US backoff is disabled as your U1 is populated with high bitloading. On my line U1 has very low bitloading.
-
Well sadly you got no US snrm data on your graphs and the bitloading is same on boths indicating its making no difference, but you said the US snrm increased with US backoff disabled?
It looks like in both your graphs US backoff is disabled as your U1 is populated with high bitloading. On my line U1 has very low bitloading.
Yeah it doesn't seem to measure that in the SNR graph sadly. The test is still not entirely conclusive as I wasn't able to get the entire set of statistics (e.g. upload blanked out of me when I re-synced after disabling UPBO, except for certain statistics such as the actual sync rate). After over 6 hours and 30 minutes of uptime so far I've had 304 CRC errors. Assume that the average is 3 CRC per errored second would make it that I've had somewhere slightly below or above 100 ES so far.
I don't know the exact DLM threshold, but I assume it's somewhere around 750-1250 ES in a 24 hour period based on my past experiences of DLM. Re-syncing is another concern, though I assume once per hour or two is reasonably safe? I will try UPBO again later today if so. UPBO is currently enabled.
EDIT:
Found it, nevermind. If Zen's correct, they say on the 'speed' profile it's no more than 2 ES every 1 minute (2880 ES in a 24 hour? Is it really that high?), and no more than 1 re-sync every 1 hour and 12 minutes (ideally, it does however state 20 re-syncs in a 24 hour period, but I'll go for the 1 hour and 12 minute guideline I calculated myself). Source: http://support.zen.co.uk/kb/Knowledgebase/Fibre-Optic-Broadband-FTTC-What-is-DLM-and-how-does-it-work
-
So far (since Friday evening), I've had re-syncs around 8pm each night and at 5am in the morning. It would appear DLM has not kicked in like it did before - my download S/N is always around 6dB. Last night I observed something that I've seen many times on my line during the evenings during which the CRC's jumped dramatically to around 2000. I got worried and thought "here we go again" im going to get DLM'd but it would appear not.
During the evenings my S/N gets really unstable - by this I mean I can see it fluctuate between 6db and 5.4 db in a matter of seconds. It was during this time last night that re-sync happened and the changes were 29476 --> 28666 download and 8281 --> 8352 upload. At 5am this changed to 28623 and 8371 respectively.
All in all it looks like the asus with old firmware is behaving similar to the ECI modem, but with slightly higher sync.
Currently I have RX AGC Gain adjustment set to the default of disabled. Does anyone understand what the effect of the other options are. For instance does changing to stable reducing the line sync?
-
So far (since Friday evening), I've had re-syncs around 8pm each night and at 5am in the morning. It would appear DLM has not kicked in like it did before - my download S/N is always around 6dB. Last night I observed something that I've seen many times on my line during the evenings during which the CRC's jumped dramatically to around 2000. I got worried and thought "here we go again" im going to get DLM'd but it would appear not.
During the evenings my S/N gets really unstable - by this I mean I can see it fluctuate between 6db and 5.4 db in a matter of seconds. It was during this time last night that re-sync happened and the changes were 29476 --> 28666 download and 8281 --> 8352 upload. At 5am this changed to 28623 and 8371 respectively.
All in all it looks like the asus with old firmware is behaving similar to the ECI modem, but with slightly higher sync.
Currently I have RX AGC Gain adjustment set to the default of disabled. Does anyone understand what the effect of the other options are. For instance does changing to stable reducing the line sync?
Not sure, I will try that late this evening though (when nobody's using the internet here). I haven't been synced long enough to know whether I can sync for a full 24 hours yet, however I did get a massive CRC error count (2000 odd) before I re-enabled UPBO, with only near an hour of uptime at the time. Since going back to the original settings my attainable upload isn't what it first was (31000 odd now), and power levels are around 6 dBm on both downstream and upstream. I'm getting roughly what appears to be an average of 1 to 1.5 ES every minute, based on occasional observed CRC increases, borderline to the supposed 2 ES every minute that DLM has on the 'speed' profile. My Rx AGC Gain is set to stable at the moment.
-
I believe DLM is 2880 ES per day but it is possible they take measurements more than once a day so e.g. if they do it every 2 hours and the ES for those 2 hours is more than 240 then DLM kicks in next day.
-
I believe DLM is 2880 ES per day but it is possible they take measurements more than once a day so e.g. if they do it every 2 hours and the ES for those 2 hours is more than 240 then DLM kicks in next day.
I see, fair enough.
Well as the evening's here it seems the error rate is higher now. CRC count is at 952 downstream with 8 hours and 56 minutes of uptime. Currently seeing a rate of 1-3 CRC downstream every 20 seconds, which if it keeps up might trigger DLM. I will update the firmware later this evening to the latest version, disable bitswapping, and observe any changes following 12-18 hours or so from that. I'll keep everything other setting as is for now.
EDIT:
Either it's coincidence or.. well I've just disconnected the phone from the MK2 SSFP and the CRC error rate has significantly dropped. Only had 1 CRC downstream in the last 5 minutes or so.
EDIT 2:
CRC rate dropped to 1-2 CRC every minute or sometimes nearly two minutes. I wonder if it doesn't like my double filter setup (in the past I've always double filtered things, perhaps it's a bad idea). Either that's coincidence or perhaps it's just the microfilter behind the SSFP that's causing it. I've plugged in the DECT phone without the double filter this time, just the SSFP for filtering.
EDIT 3:
Watching the statistics for 15 minutes, at 10 second refresh intervals, and since removing the second filter the CRC error rate on the downstream has significantly dropped. Bad filter or just bad to double filter, or just coincidence that the CRC rate has died off?
Observed ES: 7
CRC from 971 ending at 980
Worst Case ES: 9 (1 for every CRC)
-
Something I've noticed tonight, previously overlooked...
In DSL settings by default the Annex mode is set to A/I/J/L/M. (Noticed no B mode)
By setting this to B/J/M I was able to re enable bitswap on firmware 2072 and its held steady for 2 hrs now which it could never do with bitswap on.
-
Something I've noticed tonight, previously overlooked...
In DSL settings by default the Annex mode is set to A/I/J/L/M. (Noticed no B mode)
By setting this to B/J/M I was able to re enable bitswap on firmware 2072 and its held steady for 2 hrs now which it could never do with bitswap on.
Interesting find. I might try that too once I have updated.
-
Annex A or B related information (NOTE from DSL-N66U f/w 1.0.7.3)
My question to ASUS:
1.
Possible bug in syslog:
Administration -> DSL Settings -> Annex Mode = Annex B/J/M (I selected B on setup)
and yet
System Log -> DSL Log says, "Annex Mode" = "ANNEX_A"
Maybe this is related to the following that I found on the web: "For example, VDSL2 Annex B Plan B (aka Bandplan G.998) used by BT Openreach for its Profile 17a service is compatible with G993.2 Annex A for the Americas (an Annex with only one bandplan)."
Asus Reply:
For question 1, yes, they are compatible. So you can choose Annex B/J/M but running with Annex A. Our driver will choose the proper one.
However, we suggest to choose the correct mode, for your case is Annex A/I/J/L/M.
My interpretation:
1. When I selected Annex B in the quick setup for UK openreach, the DSL-N66U knew that openreach uses VDSL2 Annex B Plan B (aka Bandplan G.998), and also that this is compatible with G993.2 Annex A.
It therefore chooses to configure itself as G993.2 Annex A. Thus G993.2 Annex A is what I see on the logs.
Asus suggest I change the configuration to select Annex A/I/J/L/M directly.
-
On the DSL-AC68U during set up your not asked in the quick set up for a ANNEX mode.
It auto detects Annex B and simply reports this in the DSL LOG.
I have my suspicions that DSL SETTINGS is set to a default across the board because...
DSL MODULATION is set to Multimode not VDSL2
VDSL PROFILE is set to 30a multimode not 17a
If the set up process was truly automated to suit the service chosen these really should be set accordingly.
Hence why I have a suspicion now that Annex Mode also needs setting manually.
At the top of the DSL SETTINGS page it does say "Please contact your ISP to obtain your DSL settings before doing any changes" which does kind of suggest you do need to set these accordingly.
-
The newer DSL-N66U f/w 1.0.7.7 does not ask for mode either.
Note I did set the Annex mode manually to B, yet the log still stated A was being used.
Also Asus response on 30a or 17a:
My question:
2.
Possible error in the quick set up:
I believe BT Openreach uses Profile 17a
yet the quick set up set
Administration -> DSL Settings -> VDSL Profile = 30a multi mode
Asus Reply:
For question 2, 30a multi-mode is compatible with 17a mode, we mostly suggest customer to choose 30a multi-mode.
For some special center offices, we would suggest to use 17a mode for no sync issue, thanks.
My interpretation at the time:
2. The quick setup for openreach knows that its use of Profile 30a will be compatible with openreach using Profile 17a. Asus generally recommend configuring as 30a, unless it presents a sync issue in which case 17a could be tried.
-
That behaves differently to the AC68U has it reports Annex B automatically, changing it to A/I/J/L/M it still reports Annex B but is unstable unless bitswap is disabled. Setting it to B/J/M it also still reports Annex B but seems 'so far' stable after 3hrs with bitswap enabled.
I also have a feeling some of the support agents at ASUS may be misinterpreting questions.
-
Presumably the modem should fallback to the profile, e.g. if Multimode 30a is selected then that implies 17a and the other profiles will be supported as well. Selecting 17a I imagine just revokes 30a from consideration when syncing.
For some reason I've had a massive CRC spike on the downstream somewhere in the last 30-45 minutes. It's now 3379, and slowly rising at a average rate of 1 CRC every minute or two.
@simoncraddock: What is your average downstream CRC rate like on yours?
-
I'm not getting any CRC errors.
-
Presumably the modem should fallback to the profile, e.g. if Multimode 30a is selected then that implies 17a and the other profiles will be supported as well. Selecting 17a I imagine just revokes 30a from consideration when syncing.
For some reason I've had a massive CRC spike on the downstream somewhere in the last 30-45 minutes. It's now 3379, and slowly rising at a average rate of 1 CRC every minute or two.
@simoncraddock: What is your average downstream CRC rate like on yours?
Possibly but the last option in DSL SETTINGS is 'Improved Impulse Noise Protection (G.998.4)' often known as G.INP which I'm led to believe isn't enabled on BT Infinity just SKY Fibre. Asus couldn't give me a clear answer on this one.
-
My CRC has just started jumping up - it is now at 8000+. This seems to happen at this time every night. S/N on downstream has dropped to 5.7dB. Its been around 400 errors for 14 hours up until now!
I am still running on the old firmware. (Now at 9000 errors)!!
-
My CRC has just started jumping up - it is now at 8000+. This seems to happen at this time every night. S/N on downstream has dropped to 5.7dB. Its been around 400 errors for 14 hours up until now!
I am still running on the old firmware. (Now at 9000 errors)!!
Were you getting this on your old equipment?
On Friday evening after 2 solid days 693 firmware went crazy for several hours reporting 0db for everything. I switched back to 2072 today with the intention of leaving it hooked up to my old openreach modem until asus released another firmware. It was then I noticed the annex mode setting and decided to try it. So far 3.5 hrs and all is well.
-
My CRC has just started jumping up - it is now at 8000+. This seems to happen at this time every night. S/N on downstream has dropped to 5.7dB. Its been around 400 errors for 14 hours up until now!
I am still running on the old firmware. (Now at 9000 errors)!!
Were you getting this on your old equipment?
On Friday evening after 2 solid days 693 firmware went crazy for several hours reporting 0db for everything. I switched back to 2072 today with the intention of leaving it hooked up to my old openreach modem until asus released another firmware. It was then I noticed the annex mode setting and decided to try it. So far 3.5 hrs and all is well.
Im not sure whether I was getting a lot of CRC errors at this time of night, but I have noticed in the past that the S/N bounces around at this time of night. Repeated clicks of the refresh I could see a 0.5 - 0.6db change i.e. 6db could suddenly drop to 5.4 and then back again. I've noticed this on the HH5, ECI and Asus. Also what is weird is that I have just forced a reconnect - its at the same sync speed and CRC errors have stopped.
-
I would just like to make a comment regarding the "Annex" setting.
As I am sure you appreciate, there are two annexes -- one for the physical infrastructure and one for the VDSL2 mode band plans. The UK uses Annex A for the physical infrastructure (xDSL over POTS) and uses Annex B for the VDSL2 mode band plans, as deployed by Beattie.
They are two separate, distinct and unconnected annexes -- which can be a snare for the unwary (e.g. support agents). :-X
-
I'm wondering if the ASUS DSL SETTINGS is like the Fritz!Box 7390 because on the Fritz in DSL PARAMs you have to specify ANNEX B. Could the ASUS DSL LOGS/SETTINGS screens be wrongly worded causing confusion.
-
For the curious (I believe kitz wanted to know the difference in bitloading and SNR graphs between UPBO being enabled and disabled):
Thank you for posting the graphs. I cant really see anything too much different. Slightly more D1 bitloading in the after.. but the evidence is clear that the downstream PSD mask is still there.
It looks like in both your graphs US backoff is disabled as your U1 is populated with high bitloading.
I agree - they are too similar in both.
Whilst that is one of the areas that BT has different PSD masks for.. ie.. If hes a fair distance from the cab then he will be allocated a profile with less PBO in U1. However with a sync of 76Mbps.. that aint no long line :D
-
I'm wondering if the ASUS DSL SETTINGS is like the Fritz!Box 7390 because on the Fritz in DSL PARAMs you have to specify ANNEX B. Could the ASUS DSL LOGS/SETTINGS screens be wrongly worded causing confusion.
Not wishing to "muddy the waters" but I will say that may be worth pursuing . . . purely because a Fritz!Box is of Germanic origin and Germany is one of the few nations who uses Annex B for the physical infrastructure (xDSL over ISDN).
-
I don't know the exact DLM threshold, but I assume it's somewhere around 750-1250 ES in a 24 hour period based on my past experiences of DLM. Re-syncing is another concern, though I assume once per hour or two is reasonably safe? I will try UPBO again later today if so. UPBO is currently enabled.
EDIT:
Found it, nevermind. If Zen's correct, they say on the 'speed' profile it's no more than 2 ES every 1 minute (2880 ES in a 24 hour? Is it really that high?), and no more than 1 re-sync every 1 hour and 12 minutes (ideally, it does however state 20 re-syncs in a 24 hour period, but I'll go for the 1 hour and 12 minute guideline I calculated myself). Source: http://support.zen.co.uk/kb/Knowledgebase/Fibre-Optic-Broadband-FTTC-What-is-DLM-and-how-does-it-work
All the evidence seems to go against that. For eg the other weeks maxdsl had 5 resyncs before the DLM got him. The amount of resyncs was confirmed by sight of a graph of his RADIUS logins. He had hardly any errors.. something like 100 for the whole day.
I should have been keeping better track of mine. The DLM has stricken me 2 days in a row now. Day 1 I had 2 LOS. Day 2 I had 2 resyncs when I swapped router - I left the line down for a couple of hours whilst I went out before putting the other router on.
These are my errors for the past 24hrs.. and Im waiting to see what happens tomorrow, as interleaving and banding doesnt seem to have culled my errors.
Total time = 1 days 40 min 46 sec
FEC: 0 15094366
CRC: 5799 49183
ES: 57 2132
SES: 10 1
UAS: 65 65
LOS: 1 0
LOF: 7 0
LOM: 0 0
-
I believe DLM is 2880 ES per day but it is possible they take measurements more than once a day so e.g. if they do it every 2 hours and the ES for those 2 hours is more than 240 then DLM kicks in next day.
Data is collected every 15mins
each of the 96 bins are checked to see if there has been user activity and marked active or dormant. Any instability during inactive or dormant periods is ignored as the end-user will have been unlikely to have been affected by this.
Uptime is calculated from the active bins and any data indicative of instability during these periods is normalised.
Errors and resyncs are normalised to the uptime. This is calculated by dividing the total time in seconds for which the respective line has been in synchronisation and in active use over the past 24-hour period of the monitoring by the number of re-trains or errors recorded in that period
Not finished yet which is why its not live http://www.kitz.co.uk/adsl/DLM.htm
-
...
Interesting, that's a heck of a lot of ES and CRC! I'll be updating the ASUS firmware to the latest version very late this evening (most likely gone midnight when nobody here is using the internet). In the next couple of days, if things remain reasonably stable (need to try and reduce or eliminate the CRC errors on the downstream), I'll test disabling UPBO again and compare the statistics and graphs. It's a shame that the SNR graph doesn't show the upstream and only the downstream.
-
I would just like to make a comment regarding the "Annex" setting.
As I am sure you appreciate, there are two annexes -- one for the physical infrastructure and one for the VDSL2 mode band plans. The UK uses Annex A for the physical infrastructure (xDSL over POTS) and uses Annex B for the VDSL2 mode band plans, as deployed by Beattie.
They are two separate, distinct and unconnected annexes -- which can be a snare for the unwary (e.g. support agents). :-X
After roughly 5.5hrs solid on Annex B/J/M, I'm now trying Annex A out of curiousity.
-
I don't know the exact DLM threshold, but I assume it's somewhere around 750-1250 ES in a 24 hour period based on my past experiences of DLM. Re-syncing is another concern, though I assume once per hour or two is reasonably safe? I will try UPBO again later today if so. UPBO is currently enabled.
EDIT:
Found it, nevermind. If Zen's correct, they say on the 'speed' profile it's no more than 2 ES every 1 minute (2880 ES in a 24 hour? Is it really that high?), and no more than 1 re-sync every 1 hour and 12 minutes (ideally, it does however state 20 re-syncs in a 24 hour period, but I'll go for the 1 hour and 12 minute guideline I calculated myself). Source: http://support.zen.co.uk/kb/Knowledgebase/Fibre-Optic-Broadband-FTTC-What-is-DLM-and-how-does-it-work
All the evidence seems to go against that. For eg the other weeks maxdsl had 5 resyncs before the DLM got him. The amount of resyncs was confirmed by sight of a graph of his RADIUS logins. He had hardly any errors.. something like 100 for the whole day.
I should have been keeping better track of mine. The DLM has stricken me 2 days in a row now. Day 1 I had 2 LOS. Day 2 I had 2 resyncs when I swapped router - I left the line down for a couple of hours whilst I went out before putting the other router on.
These are my errors for the past 24hrs.. and Im waiting to see what happens tomorrow, as interleaving and banding doesnt seem to have culled my errors.
Total time = 1 days 40 min 46 sec
FEC: 0 15094366
CRC: 5799 49183
ES: 57 2132
SES: 10 1
UAS: 65 65
LOS: 1 0
LOF: 7 0
LOM: 0 0
to confirm kitz yesterday you had less than 2880 ES and DLM still took further action?
-
I believe DLM is 2880 ES per day but it is possible they take measurements more than once a day so e.g. if they do it every 2 hours and the ES for those 2 hours is more than 240 then DLM kicks in next day.
Data is collected every 15mins
each of the 96 bins are checked to see if there has been user activity and marked active or dormant. Any instability during inactive or dormant periods is ignored as the end-user will have been unlikely to have been affected by this.
Uptime is calculated from the active bins and any data indicative of instability during these periods is normalised.
Errors and resyncs are normalised to the uptime. This is calculated by dividing the total time in seconds for which the respective line has been in synchronisation and in active use over the past 24-hour period of the monitoring by the number of re-trains or errors recorded in that period
Not finished yet which is why its not live http://www.kitz.co.uk/adsl/DLM.htm
ok I am pretty sure they dont do action based on 15 min data tho as I have breached 2 ES per minute on multiple 15 min stints.
-
data is collected every 15 mins, but normalised over the days uptime period.
-
Unfortunately the new firmware with the settings shown earlier caused thousands of CRC errors, in spikes, with only a few minutes of uptime. I've disabled bitswapping and so far it's about 0.7 CRC per minute on downstream.
UPBO set to 'Auto'
SNR Down: 8.4 dB
SNR Up: 12.4 dB
Line Attenuation Down: 10.2 dB
Line Attenuation Up: 0.1 dB
Data Rate Down: 73999 kbps
Data Rate Up: 20000 kbps
MAX Rate Down: 90472
MAX Rate Up: 29542
POWER Down: 12.3 dbm
POWER Up: 6.0 dbm
UPBO set to 'Disable'
SNR Down: 8.5 dB
SNR Up: 18.8 dB
Line Attenuation Down: 10.8 dB
Line Attenuation Up: 0.1 dB
Data Rate Down: 73999 kbps
Data Rate Up: 20000 kbps
MAX Rate Down: 90716
MAX Rate Up: 38780
POWER Down: 12.0 dbm
POWER Up: 8.6 dbm
The differences are the line attenuation downstream slightly higher, upstream SNRM higher, upstream power higher, attainable upstream higher (from 29542 to 38780). Perhaps the additional upstream can be traded for a bit better downstream by reducing the tx power with UPBO disabled, this is something I will experiment with over the next few days for sure. Disabling bitswapping has so far stopped the downstream SNRM from swinging up and down by up to 1.0dB here.
-
Almost 9hrs uptime with the following settings ...
Modulation : VDSL2
Annex: A
SRA: disabled
Bitswap : On
UPBO: Auto
Improved Noise Protection : On
Everything else disabled.
Will monitor it over the day.
Edit: Approx. 12 hrs no drops
Edit: Approx. 17 hrs no drops
-
It would appear I got DLM'd this morning, even though I was running with the old firmware. Even with the old firmware I got a spike of CRC errors around 8pm last night - 3000 in total before a resync. It's weird that it always seems to go belly up around that time. S/N was 5.7dB at the time.
Im back onto the ECI modem for now to try and get some speed back - I've only at best got 28M to start with!
-
I'd have a guess at a possible line fault with that sudden surge.
-
Reconnections every 15 minutes here, not good. I'll try your settings.
It seemed to be fine when I left it at 3am~, then at 6am~ it started losing connection every 10-15 minutes. I don't know if the error count really shot up and caused the loss of sync sadly as I wasn't at the router at the time (just until a moment ago). I imagine DLM will bash my connection tomorrow morning :(.
EDIT:
Sadly no luck. One thing I am wondering though is if half of the settings are taking effect without rebooting. Reason I say that is because when I enabled UPBO I powered off the device first, unplugged the cable, switched it back on, changed the setting, rebooted and then plugged the cable back in and it seemed to improve the upload attainable speed (as in the previous post somewhere not long ago). However, when changing to the settings you mentioned (and re-enabling UPBO) the attainable upload speed and power levels remained the same and I didn't do a reboot this time, though it did re-sync when I applied the settings, unless of course 'Auto' just chose to keep the previous state and remembered that it was set to disabled.
I've now put the old firmware back on the device. UPBO disabled the attainable upload has returned to around 30000~. Power levels downstream and upstream are now around 6 dBm again.
I can confirm that the previous re-syncs in the early hours on the new firmware appear to have been CRC related, suddenly thousands of CRC errors until a re-sync. It must've re-sync at least 10-15 times. I dread to think what DLM will do tomorrow morning, unless I'm in another frozen state like I was on 60/20. At the moment my connection is 74/20 with no interleaving and I can easily get 80/20, I've been like this for months (since February I believe).
EDIT 2:
Definitely confirmed that changes to UPBO didn't seem to take effect on the connection unless the device was restarted (e.g. power off/on, or a reboot from ASUSWRT). So this might be the case for some of the other settings as well?
-
These are my current settings, still going strong almost 13 hrs now.
No drops or CRC errors, synch speed stable at approx. 76/20
-
These are my current settings, still going strong almost 13 hrs now.
No drops or CRC errors, synch speed stable at approx. 76/20
I see. Well I'll probably give it 48 hours (unless no further serious instability occurs) before I play with firmware and settings again, just incase DLM strikes me (if it isn't going to already :-\). This time when I do it I'll be sure to reboot/power cycle the device, before making the connection, after I've applied the DSL settings.
-
Im getting confused now...... I thought BT used Annex B.
Just out of interest, openreach were outside my house this morning - fiddling in the manhole. He wouldn't be specific on what he was doing, but I did find it odd that a plastic bag is used to keep the rats nest dry. This is then covered by the plastic casing.
-
Its Annex A, Plan B
Currently sat at roughly 17 hrs on my latest settings, no drops, no CRC errors.
-
Im getting confused now...... I thought BT used Annex B.
As burakkucat enlightened me
I would just like to make a comment regarding the "Annex" setting.
As I am sure you appreciate, there are two annexes -- one for the physical infrastructure and one for the VDSL2 mode band plans. The UK uses Annex A for the physical infrastructure (xDSL over POTS) and uses Annex B for the VDSL2 mode band plans, as deployed by Beattie.
They are two separate, distinct and unconnected annexes -- which can be a snare for the unwary (e.g. support agents). :-X
So as I now understand it, from the VDSL2 spec, https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.993.2-201112-I!!PDF-E&type=items
The UK used a Europe bandplan as defined in ANNEX B of the VSDL2 spec.
There is just one bandplan in Annex A and it's for the USA.
However these bandplans have variants for whether they are over POTS or ISDN. The spec says:
"Different variants are defined for band plans 997, 998, 998E17, 998E30, 998ADE17 and 998ADE30 to accommodate different underlying services (POTS and ISDN), and different US0 bandwidths."
Now Annex A of some physical infrastructure spec is xDSL over POTS, and Annex B is xDSL over ISDN.
So openreach uses an ANNEX B bandplan from the VDSL2 spec (G.993.2) over an Annex A (from some spec) physical infrastructure.
[ some is probably G.992.1 : https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.992.1-199907-I!!PDF-E&type=items ]
I now believe the ASUS "DSL Setting" -> "Annex Mode" setting to refers to the physical infrastructure not the G.993.2 annex. It can justifiably be in the DSL settings as it determines which variant of the the bandplan is used.
-
Correct I hope Asus reword the DSL LOG to state Bandplan rather than Annex Mode, it's confusing. The installation guide shows nothing at all about DSL SETTINGS which is rather poor.
If I can get to the 24hr mark with my current settings I'm hoping I've cracked the VDSL2 settings for this device to remain stable.
-
No such luck here, tried the latest firmware three times now and all three attempts end up with thousands of CRC errors which eventually cause loss of sync (even with factory reset and then matching the settings here).
Version ending 693 is fine, though 1-2 CRC's occur every minute or two plus an occasional spike of CRC errors (a dozen or so). I'm wondering if it's worth me trying versions 2048, 2049 and 2050 to see if they make any difference? Clearly there must still be something not quite right in the latest version.
-
I still think you have a line fault of some kind. Have you asked bt to run a test at all?
-
I still think you have a line fault of some kind. Have you asked bt to run a test at all?
I agree. Nope I haven't asked for a test from Zen, I don't believe I have sufficient reason to request a test / report a fault :(. I do remember the last engineer a few months ago, or possibly a year ago (can't remember) saying he did something at the cabinet with my pair as his device detected a battery contact fault (or something to that effect). Although the line seemed fine at the time, he still spent around 3 hours here going through the cabinet and manholes to trace the problem. I'm pretty sure I remember him saying that even though whatever he did with the pair (swapped wires or something) in the cabinet fixed most of the battery contact fault, it still partially lingered but due to time constraints he couldn't spend anymore time on the job.
I pay for the Zen Unlimited Fibre Office package, which is the most expensive package but comes with critical care - although I don't believe that entitles me to still ask for a test / report a fault if the line is synced at 74/20 (BT estimates a high 74.1Mbps and low of 64.3Mbps - clean). I don't think they'll see CRC errors as a fault, but maybe I'm wrong, what do you think? Do you think it's also worth me testing the other versions?
-
If your synch is that high which is almost the same as mine I think you have every right as it should be a clean line really at those speeds.
-
I agree.
I get this on the HG612, which I assumed was normal due to an incompatibility between Huawei modem's chipset and the ECI cabinet, I also had this on the Fritz!Box 7390 (when I owned one) and a similar CRC rate on the Cisco 887VA (when I owned one). The ECI /r has been the only device to date which keeps the line on fastpath, although capped at 74/20 (in the past it has been 60/20, but that I believe was due to something I did). I'm eager to see what DLM does tomorrow morning.
I'll open a thread in the FTTC section and see what general consensus is regarding whether I should get the confidence together in believing I'm right to ask for a test / report a potential problem with the state of the CRC errors. It's quite frustrating as it's only a minor CRC error (2 at best) every minute or two, you could count like clockwork pretty much, except for the less often occasional CRC error spike, and as a result all these add up the ES to a high number which may eventually cause DLM to intervene. I'd like to know what the ECI /r says in regards to CRC errors, but unfortunately the statistics from that aren't reliable.
-
Good news - I didn't get DLM'd. I couldn't resist - I had to play again lol. Im now on latest firmware and my first connection was at 30324MB down. Settings were
RX Gain - Stable
SRA - Disabled
Bitswap Enabled
INP - Disabled
Over the past hour, my CRC has been increasing totalling around 1800 - but I would expect that at such a high sync rate and a S/N dropping to 5.3dB. The line then dropped, and it re-synced at 29453MB S/N 6.0dB Now that I guess is how it is supposed to work? Im wondering if disabling SRA is the big player here because u=in the past there was never a clean transition. .....or it may just be a fluke? Andy thoughts?
-
No such luck here, tried the latest firmware three times now and all three attempts end up with thousands of CRC errors which eventually cause loss of sync (even with factory reset and then matching the settings here).
Version ending 693 is fine, though 1-2 CRC's occur every minute or two plus an occasional spike of CRC errors (a dozen or so). I'm wondering if it's worth me trying versions 2048, 2049 and 2050 to see if they make any difference? Clearly there must still be something not quite right in the latest version.
Whats your S/N? Appreciate you have a fast connection, but if your S/N is low then expect CRC errors. If it is high which i'm guessing yours is then something is not right........
-
No such luck here, tried the latest firmware three times now and all three attempts end up with thousands of CRC errors which eventually cause loss of sync (even with factory reset and then matching the settings here).
Version ending 693 is fine, though 1-2 CRC's occur every minute or two plus an occasional spike of CRC errors (a dozen or so). I'm wondering if it's worth me trying versions 2048, 2049 and 2050 to see if they make any difference? Clearly there must still be something not quite right in the latest version.
Whats your S/N? Appreciate you have a fast connection, but if your S/N is low then expect CRC errors. If it is high which i'm guessing yours is then something is not right........
Hovers between 8.5 to 9dB. I've even briefly tried adjusting the stability thingy to 13dB, it still produces a similar amount of CRC's.
-
Good news - I didn't get DLM'd. I couldn't resist - I had to play again lol. Im now on latest firmware and my first connection was at 30324MB down. Settings were
RX Gain - Stable
SRA - Disabled
Bitswap Enabled
INP - Disabled
Over the past hour, my CRC has been increasing totalling around 1800 - but I would expect that at such a high sync rate and a S/N dropping to 5.3dB. The line then dropped, and it re-synced at 29453MB S/N 6.0dB Now that I guess is how it is supposed to work? Im wondering if disabling SRA is the big player here because u=in the past there was never a clean transition. .....or it may just be a fluke? Andy thoughts?
I'm also curious to know if by having SRA enabled alongside BITSWAP is the root cause of instability. I know VDSL2 from BT doesn't support SRA, it was dropped from on anything above ADSL2. I've left G.INP enabled and so far it doesn't appear to have any negative impact and I've held a connection for roughly 20 hours now.
-
Good news - I didn't get DLM'd. I couldn't resist - I had to play again lol. Im now on latest firmware and my first connection was at 30324MB down. Settings were
RX Gain - Stable
SRA - Disabled
Bitswap Enabled
INP - Disabled
Over the past hour, my CRC has been increasing totalling around 1800 - but I would expect that at such a high sync rate and a S/N dropping to 5.3dB. The line then dropped, and it re-synced at 29453MB S/N 6.0dB Now that I guess is how it is supposed to work? Im wondering if disabling SRA is the big player here because u=in the past there was never a clean transition. .....or it may just be a fluke? Andy thoughts?
I'm also curious to know if by having SRA enabled alongside BITSWAP is the root cause of instability. I know VDSL2 from BT doesn't support SRA, it was dropped from on anything above ADSL2. I've left G.INP enabled and so far it doesn't appear to have any negative impact and I've held a connection for roughly 20 hours now.
From what I understand SRA allows a change in rate without a full sync. In my case I'm wondering whether when the error rate got too high the modem was expecting a transition but as Bt do not support it, it couldn't happen. This then caused errors to increase and continuous interruptions. What's interesting is that I have not had the flashing exclamation mark yet telling me my connection is unstable.
-
I've just done a quick google and found this article which details a ADSL2+ connection from a HG612 modem.
http://huaweihg612hacking.wordpress.com/2011/09/01/understanding-the-vdsl2-stats-from-the-hg612/
Towards the bottom line 257, note SRA=OFF
-
Well I had another re sync followed by 7000crc errors in 3 mins. I pulled the plug and gone back to eci modem. Really had enough now.
-
can you access the stats on that modem to see if the crc errors are still present?
-
No not on the eci or hh5. I've gone back to the old firmware that seemed more stable and less crc errors.
-
No not on the eci or hh5. I've gone back to the old firmware that seemed more stable and less crc errors.
So far 693 is the only version I can get stable here, some CRC errors still as well. I am considering trying 2048, 2049 and 2050 this evening to see if any of those are as stable, but I'm equally concerned that DLM might have a surprise waiting for me in the early hours of the morning.
-
I can't understand why I'm now very stable on 2072 and you guys have loads of problems with crc errors. Even during the first week of struggling to maintain a 5 min connection I've never received any crcs.
Everything seems to point to underlying line problems if your using the exact same setting as me as I'm now at 30 hours and holding steady with a synch of 76/20.
-
I don't think it's line problems as such. I'm approx 1km from the cabinet and therefore can only sync to 30MB max. S/N under this condition plays a large part as in the evenings it drops below 6. On a clean line such as yours you have plenty of headroom and hence a much cleaner line with no interference.
I've gone back to the old firmware and it's been up for 8 hours with only 90 crc errors.
-
No not on the eci or hh5. I've gone back to the old firmware that seemed more stable and less crc errors.
So far 693 is the only version I can get stable here, some CRC errors still as well. I am considering trying 2048, 2049 and 2050 this evening to see if any of those are as stable, but I'm equally concerned that DLM might have a surprise waiting for me in the early hours of the morning.
Agreed, 693 is the only version that is stable. Would appreciate your feedback on the other versions - looks like each one had a driver update for the xDSL part. I will try and do the same.
-
I haven't tested 2048 to 2050 yet, but just posting to say that it looks like DLM has speed banded me, fortunately no interleaving though :). I suspect the speed band was caused by the re-syncing in the early hours of the morning on 2072. If I wait a couple of days to just over a week and limit my re-syncs to one per day, or none at all, I imagine my speed will return to normal again (hopefully).
An interesting note is that I'm wondering if DLM has two forms of capping, meaning:
- Speed bands are used depending on attainable rate, and also used if re-syncs occur too often
- Interleaving/INP/delay are used if the connection has a high ES (that exceeds the threshold defined by the DLM profile)
My current speed is 49/15. My speed band was 74/20.
-
Just out of curiosity, how can you tell your speed band.
When DLM kicked in for me, it reduced my download to 20Mb (from around 27). However during the course of the week, it got removed and I was back to normal.
-
Just out of curiosity, how can you tell your speed band.
When DLM kicked in for me, it reduced my download to 20Mb (from around 27). However during the course of the week, it got removed and I was back to normal.
Mainly due to the fact that my connection speed is stuck at that and I have a massive amount of SNRM and a higher attainable rate. If I had a Fritz!Box 7390 then it would show me the max and min DSLAM rates on downstream and upstream. When going through telnet and checking /tmp/adsl/info_adsl.txt I get the following:
fwVer= FwVer:5.5.1.20_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=14.2 dB
AttenDown=0.1 dB
SNRMarginUp=25.6 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=14993 kbps
WanListMode=1
FECDown=0
FECUp=0
CRCDown=34
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=45 min, 43 secs
ADSLActiveTime=0 min, 21 secs
PowerDown=9.1 dbm
PowerUp=9.4 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb203
AttainUp=42208
AttainDown=81704
ShowtimeStart=21
TotalStart=63
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
-
So far my connection's holding for nearly 2 hours with version 2050. CRC's still exist in a small way but at least it's newer firmware, has the option for 'improved impulse noise protection' (which I believe is a future possibility with BT Openreach, right now it's not supported).
I think I might write a very basic app to measure the possible ES and the CRC rate, perhaps by a graph too. Best way I think is to use telnet and read the info_adsl.txt file in the /tmp/adsl/ directory, every second or two if possible.
Current Settings
DSL modulation: VDSL
Annex mode: Annex A
Stability Adjustment (ADSL): Disabled
Stability Adjustment (VDSL): Disabled
Tx Power Control (VDSL): Disabled
Rx AGC GAIN Adjustment (VDSL): Stable
UPBO - upstream power back off (VDSL): Auto
SRA (Seamless Rate Adaptation): Disabled (BT doesn't support this yet anyway, as far as I know)
Bitswap: Enabled
VDSL Profile: Multimode 17a
Improved Impulse Noise Protection (G.998.4): Enabled
-
I will give version 2050 a run this evening.
-
I will give version 2050 a run this evening.
im being a noob - can you please tell me how to access that data whilst in telnet. :-[
-
I will give version 2050 a run this evening.
im being a noob - can you please tell me how to access that data whilst in telnet. :-[
cat /tmp/adsl/info_adsl.txt
admin@DSL-AC68U:/www# cat /tmp/adsl/info_adsl.txt
outDiscards=405
inDiscards=119
outBytes=267257197
inBytes=595618661
outPkts=787770
inPkts=883777
fwVer= FwVer:5.5.1.124_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=15.7 dB
AttenDown=10.2 dB
SNRMarginUp=15.6 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=14993 kbps
WanListMode=1
FECDown=0
FECUp=2
CRCDown=362
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 5:28, 2 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=11.9 dbm
PowerUp=5.6 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb203
AttainUp=29216
AttainDown=85696
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
-
Updated to 2050. Initial sync went weird and threw up 1500 CRC's errors. It had another attempt and seems ok.
However the stats below show some serious error correction taking place. With the HH5, my down sync is usually around 26 - 27MB so I guess I shouldn't be surprised as the line is being pushed.
Interleave depth seems high.......
In 15 mins I have had 3 CRC errors.
Settings are as Ixel apart from Improved Impulse noise which I have disabled (didn't think BT had this???).
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.0 dB
AttenDown=18.5 dB
SNRMarginUp=0.0 dB
AttenUp=0.0 dB
DataRateDown=29884 kbps
DataRateUp=7692 kbps
WanListMode=1
FECDown=8466489
FECUp=0
CRCDown=1
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=7 min, 53 secs
ADSLActiveTime=0 min, 15 secs
PowerDown=0.0 dbm
PowerUp=4.0 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=0
AttainDown=39820
ShowtimeStart=15
TotalStart=31
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=433
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
-
...
Interesting. Also no, BT don't currently support it yet but they might do in the future. Disabling it is fine as far as I know. Your downstream power and upstream attainable rate are odd (glitched it looks like).
I've been up for over 9 hours with 434 downstream CRC errors.
-
Well after approx. 58hrs up time I'm fairly happy and convinced disabling the SRA option has stabilised my connection finally. Hopefully DLM will start restoring my speeds in the coming days. Fingers crossed the Asus maintains a stable connection.
-
I'm still on version 2050 with an uptime of over 22 hours, 912 CRC's downstream, 7 CRC's upstream. Speeds banded at 49/15 still, hoping DLM will not keep them there forever and that in a few days it will gradually restore the 74/20 I had prior to using and testing the ASUS.
-
You probably won't know for another 2-3 days. That's what's annoying about DLM, quick to punish but slow to reward.
-
the important figure is the ES. If thats missing on asus routers I suggest you ask for it to be added.
I had 17k crc the other day but no DLM as the ES was only 500.
-
the important figure is the ES. If thats missing on asus routers I suggest you ask for it to be added.
I had 17k crc the other day but no DLM as the ES was only 500.
Yeah, I agree. I did try developing an application to monitor for CRC changes, sadly the DSL stats are only updated every 10 seconds from what I can see, making the ES untrackable.
-
I've been in contact with asus support about a number of things today and have mentioned the following...
1. Can ES be displayed in DSL LOG if possible.
2. In DSL LOG 'Annex mode' is changed to Annex Bandplan.
Ardsar, if your reading check your PM.
-
I've been in contact with asus support about a number of things today and have mentioned the following...
1. Can ES be displayed in DSL LOG if possible.
2. In DSL LOG 'Annex mode' is changed to Annex Bandplan.
Ardsar, if your reading check your PM.
Excellent, lets hope they can do the above changes. ES (and if possible SES) would be very useful.
-
After approx. 20hours with firmware 2050, it went unstable. I had 3 or 4 resyncs in a short period of time. After each resync, the CRC rate went through the roof followed by a resync and this just kept on repeating until I pulled the plug on it. Not sure what to do now..
The downstream S/N at the time was 5.5dB, upstream was 6dB. Surely that is not low enough to cause instability?
What is weird is that when the CRC started to ramp up, resyncing at a slightly lower rate to bring the target S/N back to 6dB didn't help. ?!?!?
-
Yesterday ASUS sent me a 'BETA' firmware to try address the instability UK owners may be encountering...
Here's a link to the firmware (sorry no change log)
DSL Firmware: 1.0.1.7b testDMT_1022
DSL Driver: FwVer:5.5.1.124_A_A60901 HwVer:T14.F7_0.1
Download here:
https://drive.google.com/folderview?id=0B3xctZoK6T9HRkd4UHNmdl9WLUk&usp=sharing
Asus ask testers to set DSL settings to:
Modulation: MultiMode
Annex: A/I/J/L/M
Stability Adj (ADSL): Disabled
Stability Adj (VDSL): Disabled
TX Power Control: Disabled
RX AGC Gain: Disabled
UPBO: Auto
SRA: ON
Bitswap: Enabled
VDSL Profile: 30a
G.INP: DISABLED.
Try with SRA ON and OFF before submitting feedback form after 24hrs.
Asus also wish to assure users of the following:
Please also help to inform others in UK that ASUS is aware of the issues customers currently encounter in UK in some cases, we are working hard on a solution and next firmware that could address such interruption issue will be released ASAP. Many thanks.
-
SRA should have no effect given openreach dont use it yet.
-
I've explained this to Asus but I think they just wanted data.
I've been running almost 24hrs with SRA OFF with this firmware and it's been very stable for me with just 2 CRC errors on the Upstream.
Max Rate Down/UP jumped from around 74/20 and is hovering around 84/21 today.
Edit: Still going strong at: 1 day 2 hrs +
-
I've been on this firmware now for 18 hours and have had 5 line resyncs and high crc errors. I'm starting to think my line suffers serious xtalk and interference. The interleaved depth is now showing as 1225. The number seems a little odd ?
-
Mine is going reasonably ok as well, just wish the CRC's would be much lower. I'm designing a simple app which will estimate the ES, it's an estimate because the stats only refresh every 10 seconds unfortunately. The graph shown in the screenshot below isn't functional yet so ignore that. Hopefully ASUS will implement ES in their statistics output. I'm not using ASUS's settings as yet, but I am using the unreleased beta firmware.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FRmeuNTI.png&hash=4cd417daca0b7863c9c115ee0bf386547577e356)
-
With your attainable rates so high you must be almost sat on top of the cabinet so I'm surprised your sync rate isn't higher, unless the few FEC errors indicate a low level of interleaving is currently applied by DLM.
Either there's a bit of crosstalk on your cabinet which can't be helped or there's something else not quite right.
Not looked but does the BT Master Socket still have the test port behind the face that can accept a standard filter adapter?
-
I've been on this firmware now for 18 hours and have had 5 line resyncs and high crc errors. I'm starting to think my line suffers serious xtalk and interference. The interleaved depth is now showing as 1225. The number seems a little odd ?
Ask your ISP to test your line, it costs nothing and could reveal the cause of your problems. The longer you leave it the worse it's likely to get.
Also as mentioned above check if there's a test socket beind your BT Master Faceplate, could be a bad filter?
-
I've been on this firmware now for 18 hours and have had 5 line resyncs and high crc errors. I'm starting to think my line suffers serious xtalk and interference. The interleaved depth is now showing as 1225. The number seems a little odd ?
Ask your ISP to test your line, it costs nothing and could reveal the cause of your problems. The longer you leave it the worse it's likely to get.
Also as mentioned above check if there's a test socket beind your BT Master Faceplate, could be a bad filter?
Getting BT to do a line test ???. I will try. Got a friend with a wired phone so I can try the quiet line test first. I've just changed the Master faceplate (original was a MK2, ive changed it to a MK3) and no difference.
-
With your attainable rates so high you must be almost sat on top of the cabinet so I'm surprised your sync rate isn't higher, unless the few FEC errors indicate a low level of interleaving is currently applied by DLM.
Either there's a bit of crosstalk on your cabinet which can't be helped or there's something else not quite right.
Not looked but does the BT Master Socket still have the test port behind the face that can accept a standard filter adapter?
DLM's banded me (without interleaving applied), hopefully temporarily, due to all the re-syncs I had consecutively one morning on the latest official firmware. Cabinet is about 200m-300m cable run distance if I recall correctly. It's within 30-40 steps walking distance.
-
After 10 resyncs today I've pulled the plug. Not sure if it's my line or this router so have put the eci modem back. Does anyone know if you can obtain crc data. It has been unlocked but I can only get to the link status and the bit loading and snr plots.
-
After 10 resyncs today I've pulled the plug. Not sure if it's my line or this router so have put the eci modem back. Does anyone know if you can obtain crc data. It has been unlocked but I can only get to the link status and the bit loading and snr plots.
Last I recall the statistics from the ECI are unreliable. Might be wrong though.
-
That's why I have both the HG612 and the ECI, if in doubt plug the HG612 to view the line stats.
-
As far as I can tell DSL sync was lost around 2am last night (according to router log). No sign of DLM intervention however as sync rates remain the same. Attainable downstream has dropped by approximately 1.5Mbps. Error seconds I've worked out seems to be an average of between 15 to 20 ES per hour (360 to 480 daily), which is within DLM's speed profile's threshold. All I'm hoping for is that DLM will raise the speed banding soon and not leave me permanently on 49/15.
DSL Firmware Version 1.0.1.7b_testDMT_1022
DSL Driver Version FwVer:5.5.1.124_B_A60901 HwVer:T14.F7_0.1
DSL Link Status up
DSL Uptime 0 days 8 hours 11 minutes 36 seconds
DSL modulation ITU G.993.2(VDSL2)
Annex mode ANNEX_B
SNR Down 15.5 dB
SNR Up 15.7 dB
Line Attenuation Down 11.2 dB
Line Attenuation Up 0.1 dB
Data Rate Down 48999 kbps
Data Rate Up 14993 kbps
MAX Rate Down 94092
MAX Rate Up 30224
POWER Down 11.6 dbm
POWER Up 5.1 dbm
CRC Down 291
CRC Up 1
I'll try ASUS's settings as soon as DLM relents, if it ever does :(.
-
I am not sure why you seem to get banded before interleaving I think is odd.
On my line I get banded when my sync is too low for the current band, so e.g. if I am on min 40 max 80 band and sync at 50, DLM will reband me to maybe 37 to 74 or min 40 max 60. Then if I sync at a higher speed and the banding is capping me it gets released a few days later, thats what I observed on my line.
Of course we know from you and kitz there is other triggers for banding as you seem to get it for error's, and kitz also got it for error's on her US.
-
As far as I can tell DSL sync was lost around 2am last night (according to router log). No sign of DLM intervention however as sync rates remain the same. Attainable downstream has dropped by approximately 1.5Mbps. Error seconds I've worked out seems to be an average of between 15 to 20 ES per hour (360 to 480 daily), which is within DLM's speed profile's threshold. All I'm hoping for is that DLM will raise the speed banding soon and not leave me permanently on 49/15.
My attainable rate fluctuates all day. Currently with the new firmware it will rise and fall between 79 and 85 mbps, rising and falling bit by bit.
-
I am not sure why you seem to get banded before interleaving I think is odd.
On my line I get banded when my sync is too low for the current band, so e.g. if I am on min 40 max 80 band and sync at 50, DLM will reband me to maybe 37 to 74 or min 40 max 60. Then if I sync at a higher speed and the banding is capping me it gets released a few days later, thats what I observed on my line.
Of course we know from you and kitz there is other triggers for banding as you seem to get it for error's, and kitz also got it for error's on her US.
I have a theory that DLM uses interleaving and banding if the error seconds threshold has been exceeded, where it only uses banding if the connection has resynced too often (and of course depending on the sync rate of the modem). In my case the ES hasn't exceeded what Zen states (if it's correct), but I did lose sync quite a bit in the early hours of a morning 2 or 3 days ago.
...
My attainable rates barely change, except for when I lost sync around 2am this morning. Usually it's pretty much the same day and night here.
-
Here's mine within 1 minute...
13:28
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs22.postimg.org%2Fcvdh3tzwx%2F1328.jpg&hash=21a1ac237829df585c8e97b272b4c6f53a2bf27b)
13:29
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs8.postimg.org%2F5lm12c7t1%2F1329.jpg&hash=2f065f5aed624c536078b6e92530a429dff111f7)
My connection as just gone through 48.5 hrs without a hiccup.
-
I've designed an app in C#.NET which will now graph the errors and other statistics from the modem (on a 24 hour chart, updated once a minute, while data is fetched from the DSL-AC68U every 10 seconds). If it proves stable and reliable enough then I'll release it for those curious who wish to do the same.
I'm mainly doing it to see if there's any pattern to my errors, especially when I receive rare spikes of CRC's.
Interestingly my attainable downstream is higher again at the moment (was around 93.5Mbps after I lost sync at 2am), now showing 95Mbps~.
-
Daft as it sounds does it coincide with street lighting on and off, noticed some towns are reducing lighting levels between 1 and 2am and also some are replacing them with LED lighting which brings forth a whole new raft of interference.
-
Daft as it sounds does it coincide with street lighting on and off, noticed some towns are reducing lighting levels between 1 and 2am and also some are replacing them with LED lighting which brings forth a whole new raft of interference.
I don't think so, but you have a point. I will observe the street lighting and see if I can notice any pattern there once I've got some graphs and notice a pattern on them.
-
I've designed an app in C#.NET which will now graph the errors and other statistics from the modem (on a 24 hour chart, updated once a minute, while data is fetched from the DSL-AC68U every 10 seconds). If it proves stable and reliable enough then I'll release it for those curious who wish to do the same.
I'm mainly doing it to see if there's any pattern to my errors, especially when I receive rare spikes of CRC's.
Interestingly my attainable downstream is higher again at the moment (was around 93.5Mbps after I lost sync at 2am), now showing 95Mbps~.
Your app sounds really useful and I look forward to when you release it.
Its gone quiet in here, so I assume the beta firmware is playing nicely with most?
-
I'm currently on the HH5 because BT are reporting I have a line fault, so until that's resolved on Wednesday (hopefully) its probably for the best. I'm also waiting delivery of a branded/unlocked ZyXel VMG8324-B10A to try out.
Once I have my line fixed and the ZyXel in hand I'll decided what I'm doing with the ASUS.
Chances are for the foreseeable future I'll use the ZyXel in conjunction with the ASUS, I'll have to see how they both perform against each other. The ZyXel shows comprehensive linestats in the GUI and is a Broadcomm modem so its looking likely it will end up in Bridge mode linked to the ASUS.
-
How did you get them to investigate and report a line fault. I thought your sync was close to the max possible?
-
I already had a open case from 2 weeks prior which they said was fixed last week but I complained that they hadn't reset my IP profile. Tier2 support then checked my line and said they were still showing a fault and would schedule an engineer to come out on Wednesday to check my line again and reset my IP Profile.
-
I still recommend to use broadcom based modems and also I probably recommend the billion over the zyxel if you want stability and unbuggy firmware.
-
I only paid £50 for the ZyXel so it's not a bad buy.
I have both a HG612 (unlocked) and a ECI B-FOCuS V-2FUb/r Rev.B possibly to sell if it performs well.
-
I'll post some graphs later tomorrow now that I've got the graphs pretty much the way I want them to show. Should be releasing the app soon.
Unfortunately while the beta firmware seems stable for me, I'm still getting a trickle of 1-2 CRC's every 1-4 minutes. During the daytime it seems far worse than at night, usually CRC's every 1-2 minutes, but at night it's both less often and less CRC's overall. I don't think I'm going to be able to get rid of the DLM banding anytime soon, even though my attainable is 98/21 (reduced transmit power to achieve a higher downstream and but lower upstream, to try and reduce CRC's). Stuck on 49/15 at the moment, definitely below the estimates for both clean and impacted ranges.
-
I've uploaded some graphs/charts from today at http://imgur.com/a/jHtL2
I've noticed there's a pattern to the CRC's, during daylight there's a lot more CRC's than there are when it's dark. For some reason the SNR glitched with the device reporting a 51dB DS SNR at one point. Waiting for the MK3 SSFP and toroid ferrite to arrive, hopefully this week. The error seconds aren't likely to be completely accurate as the statistics from the device only update every 10 seconds.
I think I might plug in the HG612 I have and take a look at the hlog and qln to see if much has changed since some months ago, perhaps use it for a couple of days and also compare CRC's and see if that follows a similar pattern to the ASUS DSL-AC68U.
-
Interesting.
My CRC's seem to be worse during the evening / at night however i'm not sure due to constant resyncs.
-
BT finally tested and reset my profile today, ASUS started recording CRC errors immediately.
That's it for now, had enough of messing so I've connected the ECI OpenReach Modem up to it and it can stay like that.
:no:
-
From what I've seen on my line, connecting the Asus results in a higher sync and also reports attainable rates 10M higher than with the ECI. Currently I have had the ECI connected for 3 days to try and recover my line and it is currently syncing at 25M. If I were to connect the asus I know it would sync at aaround 29M.
The ECI modem is currently reporting max attainable of 31M, whereas asus would report anything between 38 - 44MB!
I suspect the asus is more sensitive and hence the higher attainable and sync rates. However with this increase in sensitivity comes instability. Either that or the firmware has serious issues at identifying what the line is capable of.
Such as shame.
-
Indeed. I'm waiting for the MK3 SSFP and ferrite toroid to arrive, if neither help the CRC's then I'll plug in the HG612 and see what results that has. Otherwise I'll go back to the ECI /r until the line speed eventually recovers. If it's like my 60/20 banding last time then it will be several months before DLM puts me back to 80/20.
-
This was my comparison:
ASUS: Max Rate: DS=78500 mbps US=22448 mbps
ASUS: Data Rate: DS=58363 mbps US=20000 mbps
BTOM: Data Rate: DS=58280 mbps Us=18900 mbps (using speed test)
Very little difference really on the actual final data rate.
-
I am already using the MK3 faceplate - have had it for a few weeks now. :(
-
I ignore variances on the attainable rate, just look at the actual sync rate to determine if a FW performs better.
On my billion 8800nl the snrm fluctuates by small amounts, on my DS maybe 0.1db or so yet the DS attainable can suddenly jump up by 3mbit or so on a 0.1db snrm change.
So if 2 different devices have the same sync speed, same snrm but report different attainables, really its just one guessing different to the other.
-
I ignore variances on the attainable rate, just look at the actual sync rate to determine if a FW performs better.
On my billion 8800nl the snrm fluctuates by small amounts, on my DS maybe 0.1db or so yet the DS attainable can suddenly jump up by 3mbit or so on a 0.1db snrm change.
So if 2 different devices have the same sync speed, same snrm but report different attainables, really its just one guessing different to the other.
That's the point. The Asus on my line syncs a lot higher than either the home hub 5 or the eci modem at the same s/n. Asus generally connects around 29m down whilst eci is currently connected at 26 with 6db margin. I guess 3M higher is not much for those on an 70m line but it is for us that struggle lol.
-
thats fine.
-
Posting some more graphs from my device - http://imgur.com/a/KuMmt
What mostly peaks my curiousity is the major fluctuation on the SNR for both US and DS between 16:30~ to 21:00~. I haven't noticed this before. I imagine this could either be something interfering with the connection and relates to the CRC errors I have, or possibly a fault beginning to show itself, or perhaps it's just the ASUS's modem? Obviously without a Hlog and QLN there's no real easy for anyone here to analyse this I'd assume.
I'm really hoping the MK3 SSFP will arrive tomorrow at the very least, as soon as it does I'll probably run the ASUS for another 24-48 hours to observe if it has helped or not. After that, if it hasn't helped or a problem may still exist, then I'll switch to the HG612, start logging and then make a thread in the FTTC issues section. I hope it's not another possibility of a battery contact again.
EDIT: Updated album. Seems I had a disconnection shortly after that (a major CRC spike again). Since reconnection my power has changed, SNRM is a tad lower on downstream (though I believe stabilised), and less errors occurring at the moment. Also around 11:45am I did a reconnection myself (switching from MK1 to MK2 SSFP as I was comparing).
-
Has anyone had an official update from Asus. It's now over a week that they release beta firmware that is clearly not resolving everyone's issues. I've gone back to using the HH5 and surprise surprise DLM has reduced my line.
-
I've switched to the HG612 temporarily - due to the concerning stability issue yesterday from 4pm. Still getting the trickle of CRC errors but the Hlog and QLN I don't believe show anything unusual to identify a possible fault unfortunately (am on 'MyDSLWebStats' as Ixel). Just reconnected a moment ago now that the trickle of CRC errors is rising as usual, nothing still identifiable on the Hlog or QLN :(.
EDIT: Just got the MK3 SSFP about 30 minutes ago, reconnected again as I wanted to swap from MK2 to MK3.
-
has it made any difference?
-
has it made any difference?
So far I can't say it has made a noticeable difference to the trickling CRC's. Lost a bit of attainable though.
-
Studying the TC Console instructions, it appears to open up access to the modem's operating system/firmware via LAN port 4. Telnet access becomes available on IP 169.254.0.1. I'm able to get in with the login admin - 1234
tc>ls
bin dev lib mnt proc sys userfs var
boaroot etc linuxrc opt sbin tmp usr
tc>uname -a
Linux tc 2.6.36 #50 SMP Wed Oct 22 17:57:22 CST 2014 mips unknown
tc>cat /proc/cpuinfo
system type : Ralink MT751020 SOC
processor : 0
cpu model : MIPS 34Kc V5.5
BogoMIPS : 430.89
wait instruction : yes
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0490, 0x0ff8, 0x0ffb]
ASEs implemented : mips16 dsp mt
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available
processor : 1
cpu model : (null) V5.5
BogoMIPS : 323.58
wait instruction : yes
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0490, 0x0ff8, 0x0ffb]
ASEs implemented : mips16 dsp mt
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available
processor : 2
cpu model : (null) V5.5
BogoMIPS : 323.58
wait instruction : yes
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0490, 0x0ff8, 0x0ffb]
ASEs implemented : mips16 dsp mt
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available
processor : 3
cpu model : (null) V5.5
BogoMIPS : 323.58
wait instruction : yes
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0490, 0x0ff8, 0x0ffb]
ASEs implemented : mips16 dsp mt
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available
tc>
There's also a web interface on 169.254.0.1 - same login. See screenshot: http://i.imgur.com/MfdSduP.png
-
tonight im at 3036 crc errors after 30mins. Is that a world record yet?
-
tonight im at 3036 crc errors after 30mins. Is that a world record yet?
At one time I was at 10000+ CRC within 5 minutes :P.
EDIT: I've just figured out how to use the TC Console interactively. Going on telnet is no good as the commands return nothing back to the interface. All output seems to be redirected to the TC Console application. You can set tc diag from 1 to 0 in order to make it so you can type commands such as 'wan'.
-
I've just captured a 24hour log which contains several re-syncs and hence DLM reducing my line. Hopefully this will provide them with something to work on.
Asus has now been locked in the cupboard until this is resolved.
Can someone please give me the email address to send this log to.
Thanks
-
My ASUS seemed to be fairly stable using these settings:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs25.postimg.org%2Fc0yidfyzj%2FPIC1.jpg&hash=6cb4a46e2586106d5fedb16cf0734c46ea08f225)
At the moment I'm torn between two bits of kit, a ZyXel and the ASUS.
The ASUS reports a max attainable speed of 75/25 the ZyXel 69/22.
The above settings stablised the ASUS connection to produce just 0/3 CRC errors in the first hour.
-
My ASUS seemed to be fairly stable using these settings:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs25.postimg.org%2Fc0yidfyzj%2FPIC1.jpg&hash=6cb4a46e2586106d5fedb16cf0734c46ea08f225)
At the moment I'm torn between two bits of kit, a ZyXel and the ASUS.
The ASUS reports a max attainable speed of 75/25 the ZyXel 69/22.
The above settings stablised the ASUS connection to produce just 0/3 CRC errors in the first hour.
I see. Well, if and when DLM restores my downstream sync rate then I'll go back to the ASUS. At the moment I'm on 49/20 (was 49/15, from 74/20). I have a feeling I could be waiting a couple of months though, so may have to try it sooner. I'll give it up to one month of solid uptime on the ECI modem, if nothing has changed then I'll go back to the ASUS and try that or whatever's been said at that time.
-
For those near max sync, adding stability adjustment of 6db probably helps. However for those like me that only get around 26M, adding a 6db stability reduces the downstream to around 20 which kind of defeats the whole purpose of this.
Sent the 24hour log off to Asus last weekend. Really disappointed that they have not even bothered to reply. Not good!
-
I've not heard anything either for over 12 days.
I might drop an email to them to see if there's any progress.
Update: I've decided to sell the ASUS on eBay and stick with the ZyXel VMG8324-B10A (f1000).
The ZyXel whilst not as impressive in hardware specs is reliable for me now.
-
I got a reply this morning. Clearly they only have one representative who has been on holiday.
He sent me the same beta firmware again, so I guess that means NO PROGRESS.
The only feedback I got about the 24hour log was my max speed and distance to the cabinet. :no:
I also wish they would stop telling us to play with the stability adjustment - setting target S/N should be left to the DLM. This is the only device I know with stability adjustment (maybe for a known reason).
-
I got a reply this morning. Clearly they only have one representative who has been on holiday.
I also wish they would stop telling us to play with the stability adjustment - setting target S/N should be left to the DLM. This is the only device I know with stability adjustment (maybe for a known reason).
I guess that's Paul Lee they are referring to.
They sent me those settings also, but to be honest they shouldn't be needed to make a connection stable. The ZyXel box I've been using recently doesn't need them and I get far less errors, plus I now have more confidence in it holding the connection with the latest firmware. I'm tempted to try returning the ASUS to PC World as unfit for purpose.
I stuck the ASUS back on-line yesterday for 12 hours and despite maintaining a connection all day DLM smacked me down by 2mbps, so the 2mbps I gained last week with the ZyXel was swiftly taken from me as punishment. The ZyXel is back in place so hopefully by Wednesday I'll be bumped up again.
-
Hi,
I just bought this modem-router
I'm surprised :'(
DSL-AC68U does not support the loopback? ???
-
It would seem via the TC Console I'm able to override the downstream DSLAM parameters. As most people are aware I'm presently stuck on 49/20, well as of a few minutes ago I'm now back on 80/20. I set the max data rate to 10000 (x8) = 80000Kbps and wala.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F3905117273.png&hash=39a13af1cd06ebe1f0ead73f36764bc4c4c825fe)
>tcapi get Info_Adsl lineState
up
>tcapi show Info_Adsl
outDiscards=78
inDiscards=4
outBytes=84605781
inBytes=343251590
outPkts=220260
inPkts=307165
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.1 dB
AttenDown=10.2 dB
SNRMarginUp=9.7 dB
AttenUp=0.1 dB
DataRateDown=79999 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=0
FECUp=2
CRCDown=8
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=7 min, 26 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=10.9 dbm
PowerUp=4.4 dbm
AttainUp=27616
AttainDown=95748
ShowtimeStart=19
TotalStart=38
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
I wouldn't advise going beyond your package speed limit however, if you do wish to explore this. But it does appear to override the max sync rate on the downstream, so is useful in overriding the DLM banding. I suspect the INP and delay would also be overriden (earlier today I forced my connection to be interleaved with INP 2 and a max delay of 16ms).
-
hahaha ooooookay, nice.
-
That's so funny, wait till this news spreads!
-
Well, the bad news is while the connection was stable overnight, the CRC's racked up by around 7-8am this morning. Seems I get more errors during daytime than I do at night. I've temporarily resorted to interleaving my connection at 49/20 (INP 3, delay 8ms).
>tcapi get Info_Adsl lineState;tcapi show Info_Adsl
up
outDiscards=244
inDiscards=8767
outBytes=430504426
inBytes=1141743620
outPkts=932369
inPkts=1186123
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=12.1 dB
AttenDown=10.3 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=8853
FECUp=321
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=47 min, 28 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.8 dbm
PowerUp=5.0 dbm
AttainUp=25394
AttainDown=110104
ShowtimeStart=18
TotalStart=154
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
I will gradually increase the sync rate and/or reduce the INP/delay every 24 hours according to how many ES and CRC's there are on the downstream.
-
Got in my hands before 2 days ago this unit and i play with it
It gave me few errors around 600 with adsl connection & everything disable (only bit swap enable)
I have enable the VECTOR G 993.5 and i have 0 CRC errors (very few up) for nearly a day & the spectrum is working very good, it does recovers the missing tones well
I have latest beta ending with ...2139
(note my high snr is due to my profile)
Here my settings ... worth to try and for vdsl users ... it seems very stable ... because i have find a bug will not change the or reset the errors after changing the parameters at dsl settings ... when load 100% the changes from the small loading tab, give a manual reboot
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1167.photobucket.com%2Falbums%2Fq631%2Fbabis3g%2F20hrsupvector_zpsaa40fece.png&hash=b27996d86f99d521b8d0158e64f9eda6ea28c5b2) (http://s1167.photobucket.com/user/babis3g/media/20hrsupvector_zpsaa40fece.png.html)
-
ADSL2 and VDSL are very different beasts and what might work fine on lower speeds can wreck VDSL connections.
I'm beginning to think there's a bug in the attainable rate calculations which is over rating a lines true capability thus in turn causing instability with the DSLAM. Every time I put the ASUS on-line DLM reduces my speed and increases Interleaving depth within 24hrs . Every time I put my ZyXel or BT gear on-line things start returning to normal.
-
ADSL2 and VDSL are very different beasts and what might work fine on lower speeds can wreck VDSL connections.
I'm beginning to think there's a bug in the attainable rate calculations which is over rating a lines true capability thus in turn causing instability with the DSLAM. everything I put the ASUS on-line DLM reduces my speed and increases Interleaving depth. Every time I put my ZyXel or BT gear on-line things start returning to normal.
i know your point make sense, i will try to report it ... in mean time worth to try the vector g 993.5 ... i have test it with a draytek 2760 as well and that one has less errors and so the DLM does not kick ... i know many disagree with vector enable with vdsl does not make sense ... but give a go with vector enable ... nothing to lose
-
Vectoring isn't supported by BT FTTC, nether is SRA.
-
Vectoring isn't supported by BT FTTC, nether is SRA.
That just means that it shouldn't help. However the equipment is clearly buggy, and any configuration change may have unintended consequences unrelated to what it's meant to do - the unintended consequences may help.
-
vectoring is not supported even with my adsl line but as said for a reason is more stable with less errors ... i have test & a draytek 2760 with my adsl line & the ac68u both enable with vector & are much less errors at both so it does not look is very buggy
-
Hi All,
First post. I'm also suffering with the DSL-AC68U, great on paper but a bit problematic atm. I'm on plusnet. Similar situation to that described - dropping links every 5 minutes.
I've just upgraded to the 1.0.1.9 firmware and the line has remained stable for 2 hours which is great. Going to leave it on for a day before changing any other settings. However i'm now getting 10-11 Mbits per a second down on a 40/15 subscription (I used to get 39/9 on my previous BT infinity 2 sub). Prior to upgrading the firmware I was getting 38Mbs down.
A couple of questions are:
1. CRC errors - are these the bottom two figures in the DSL log page? if so mine seem high (see attached) and may explain the low download speed i'm now getting.
2. The ASUS website has a FAQ on setting you optimum MTU. Based on the ping test it suggests mine should be 1484 not 1492 as set on my WAN settings. When I change this and click apply it stays as 1492 every time. Is this set automatically by the ISP/ link. If so should I be worried about changing it?
3. Is anyone else on plus net if so what are the generally accepted optimum settings at this point in time (I know there are still issues generally). I see suggestions for reducing CRC on BT Infinity, If no one is on plusnet, I may try some of the BT settings suggested recently and see how these work on the basis that its 'mostly' the same infrastructure.
4. The SNR quoted is around 6dB. Is this figure the 'SNR' or infact the 'SNR margin'. In my understanding 'SNR' is higher the better and 'SNR margin' should preferably be low (as long as your link is stable). Because if my actual SNR is at '6 dB' then I think I have a big issue...
Cheers,
Richard.
-
Hi All,
First post. I'm also suffering with the DSL-AC68U, great on paper but a bit problematic atm. I'm on plusnet. Similar situation to that described - dropping links every 5 minutes.
I've just upgraded to the 1.0.1.9 firmware and the line has remained stable for 2 hours which is great. Going to leave it on for a day before changing any other settings. However i'm now getting 10-11 Mbits per a second down on a 40/15 subscription (I used to get 39/9 on my previous BT infinity 2 sub). Prior to upgrading the firmware I was getting 38Mbs down.
A couple of questions are:
1. CRC errors - are these the bottom two figures in the DSL log page? if so mine seem high (see attached) and may explain the low download speed i'm now getting.
2. The ASUS website has a FAQ on setting you optimum MTU. Based on the ping test it suggests mine should be 1484 not 1492 as set on my WAN settings. When I change this and click apply it stays as 1492 every time. Is this set automatically by the ISP/ link. If so should I be worried about changing it?
3. Is anyone else on plus net if so what are the generally accepted optimum settings at this point in time (I know there are still issues generally). I see suggestions for reducing CRC on BT Infinity, If no one is on plusnet, I may try some of the BT settings suggested recently and see how these work on the basis that its 'mostly' the same infrastructure.
4. The SNR quoted is around 6dB. Is this figure the 'SNR' or infact the 'SNR margin'. In my understanding 'SNR' is higher the better and 'SNR margin' should preferably be low (as long as your link is stable). Because if my actual SNR is at '6 dB' then I think I have a big issue...
Cheers,
Richard.
Someone with similar issues to me!
1) Yes, extremely high CRC errors for around 2 hours uptime. I've also found that my DSL-AC68U struggles on fastpath with an SNRM of around 6dB, so I've been forced to use TC Console to override the downstream DSLAM parameters and currently set an INP of 3 and a delay of 8ms (interleaved). Since then DLM has also decided to put it on anyway, but I'm overriding it regardless.
2) I can't confirm that, I use the default however.
3) I can't answer that as I'm on Zen Internet.
4) SNRM - the higher the better, yes. 6 dB is the target SNRM however I personally feel it should be at least 9 dB on fastpath and 6 dB on interleaved instead (depending on sync rate banding applied).
-
Although the above pic settings works best for me suddenly after a day started to lower the snr down to 19-20 (26db by default due to my profile capped speed) and snr up from 18 db lower to 11
errors from 0 gone up to 9
the max down rates was varying anything from 11-13 mbps
At the moment for my line still works great (high snr profile) but my guess if i was with a lower snr target like you guys i would had issues
-
if you want to watch the snr & connection speed then the routerstats lite is working (but not upstream)
go to the routerstats setup page and set
router tab user defined
url http://192.168.1.1/Main_AdslStatus_Content.asp
log in your user name & pass
define stats press the get page and find the snr down & speed
Highlight the SNR Down as the screenshot to unique box & <td> to adjacent box ... ( use the green arrow to add at the right)
scroll down & do the same with Data Rate Down
example with the snr target .. should work for all
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1167.photobucket.com%2Falbums%2Fq631%2Fbabis3g%2Frouterstats_zpsb55f41e1.png&hash=c7d1d2933e5d98155cf960f2caedab80752b20ab) (http://s1167.photobucket.com/user/babis3g/media/routerstats_zpsb55f41e1.png.html)
-
Nice.
Well, since 3am this morning I'm now on the following settings and my ES/CRC is lower than it was by now (6 hours uptime at time of posting~), but it's still early days.
- Target SNRM 9.0 dB
- INP 3, Delay 8ms
- Max/min downstream sync rate 80Mbps/64Kbps
- Bitswapping disabled (RX & TX)
- Disabled DS3 due to high bitswapping history when observing from HG612
- DSL Settings: Changed RX AGC from 'Stable' to 'Disabled'
Points 1 and 4 seemed to make a difference, but it could just be a coincidence. I need to run it for more time to know for sure.
>wan vdsl2 show mgcnt;tcapi get Info_Adsl lineState;tcapi show Info_Adsl
near-end path0 fec: 40124946(132558252)
near-end path0 crc: 49(2403)
near-end fec sec: 23615(71263)
near-end err sec: 21(1164)
near-end ses sec: 0(31)
near-end los sec: 0(0)
near-end ua sec: 0(246)
far-end path0 fec: 4195(57808)
far-end path0 crc: 0(1116)
far-end fec sec: 254(3000)
far-end err sec: 0(968)
far-end ses sec: 0(0)
far-end los sec: 0(189)
far-end ua sec: 0(10915)
up
outDiscards=1
inDiscards=731
outBytes=1221675152
inBytes=2114564884
outPkts=5004115
inPkts=6654708
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.8 dB
AttenDown=10.3 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=51547 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=40124941
FECUp=4195
CRCDown=49
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 7:02, 54 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.2 dbm
PowerUp=4.1 dbm
AttainUp=26477
AttainDown=70288
ShowtimeStart=18
TotalStart=94
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=3001
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
-
What firmware are people here using? I'm using 2139 with dsl modem firmware version 1.0.1.9. I was from a link sent to me by support on the 12/11/2014 at:
https://www.asuswebstorage.com/navigate/s/75FF2D0BB7494B5BAB7235698A63DE58Y (https://www.asuswebstorage.com/navigate/s/75FF2D0BB7494B5BAB7235698A63DE58Y)
it appears to be slightly newer that the firmware you guys are using (2050?).
On another note. With my 'stability adjustment' set to 11dB it forces the SNR Margin up to around 11dB and most of my CRC down errors disappear. However it pretty much caps my line speed at around 30 Mb/s down. setting to 9dB gets me the highest download speed at around 32-33 Mb/s. But I get around 20 CRC's per a minute which translates to occasion glitches/ jitter in transmission which can be annoying. Any lower than 9dB and the CRC's trash the performance.
With this control disabled, SNR down margin is at around 5.5dB I connect at over 40Mb/s, but I get around 1000 crc's a minute which destroys download speed and leaves me with around a 10MB/s download speed... I can only assume the defaults the ASUS modem connects with are overly optimistic. Its annoying as with my old BT modem and HH3 combo I would get 38Mb/s down. I did get occasional glitches with that combo, but I never unlocked the firmware and I never bothered checking what these were being caused by, or my SNR margin etc.
For the moment I'm going to leave this control on at around 11dB and see how it performs. It's 10Mb/s less than I would like, but still, it's quick enough for the moment.
-
Touch wood I maybe on to a winner!!
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs25.postimg.org%2Fqt10qzh7j%2FUntitled_1.jpg&hash=303ab6d0e9a86405ba8d3c54034a3972df8190d7)
-
i have notice when all settings are disable is performing better but still needs work
however suddenly starts going funny so all mess up
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1167.photobucket.com%2Falbums%2Fq631%2Fbabis3g%2FNoiseMargin-2014Nov16-0925_zpsa7e5d57e.jpg&hash=7540974d04227391fed40932ec84d83b8b38ee5a) (http://s1167.photobucket.com/user/babis3g/media/NoiseMargin-2014Nov16-0925_zpsa7e5d57e.jpg.html)
-
What firmware are people here using? I'm using 2139 with dsl modem firmware version 1.0.1.9. I was from a link sent to me by support on the 12/11/2014 at:
https://www.asuswebstorage.com/navigate/s/75FF2D0BB7494B5BAB7235698A63DE58Y (https://www.asuswebstorage.com/navigate/s/75FF2D0BB7494B5BAB7235698A63DE58Y)
it appears to be slightly newer that the firmware you guys are using (2050?).
On another note. With my 'stability adjustment' set to 11dB it forces the SNR Margin up to around 11dB and most of my CRC down errors disappear. However it pretty much caps my line speed at around 30 Mb/s down. setting to 9dB gets me the highest download speed at around 32-33 Mb/s. But I get around 20 CRC's per a minute which translates to occasion glitches/ jitter in transmission which can be annoying. Any lower than 9dB and the CRC's trash the performance.
With this control disabled, SNR down margin is at around 5.5dB I connect at over 40Mb/s, but I get around 1000 crc's a minute which destroys download speed and leaves me with around a 10MB/s download speed... I can only assume the defaults the ASUS modem connects with are overly optimistic. Its annoying as with my old BT modem and HH3 combo I would get 38Mb/s down. I did get occasional glitches with that combo, but I never unlocked the firmware and I never bothered checking what these were being caused by, or my SNR margin etc.
For the moment I'm going to leave this control on at around 11dB and see how it performs. It's 10Mb/s less than I would like, but still, it's quick enough for the moment.
On 2139 here. Is your connection interleaved or fastpath? I've noticed a similar trend since increasing my downstream SNRM. I wonder if the modem chipset/firmware isn't suitably designed to handle a lower SNRM.
-
Touch wood I maybe on to a winner!!
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs25.postimg.org%2Fqt10qzh7j%2FUntitled_1.jpg&hash=303ab6d0e9a86405ba8d3c54034a3972df8190d7)
Apologies for double post, forgot to include...
What are your settings again? The most recent you posted or different?
-
Slightly different...
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs25.postimg.org%2F9236hr5y7%2FUntitled_2.jpg&hash=2b3b6be7b08c780165329603db4973c78ff422de)
-
OK i'm being brave and giving this latest firmware a run.
One thing I have noticed is that the DSL log states im on fastpath, yet via telnet my interleave depth is at 423 and I have FEC counting up. Clearly im not on fastpath!
Ive set the target S/N to 7db (which gives similar speed to the ECI modem) and currently I have 2 CRC errors after 42mins. I suspect the CRC will increase when the S/N drops close to 6db later this evening.
-
I have my doubts that the Asus reports Interleaving/Fastpath correctly.
I did 2 comparisons last week using the Asus and ZyXel.
On the Asus it reported my interleaving depth at 856 yet on the ZyXel it was 443.
I also think the 'Max Data/Attainable Rate' calculation on the Asus is wrong.
On 4 different devices my attainable rate is usually 64-68mbps, on the Asus it is around 86mbps.
-
max attainable is wrong because it looks like it is using the wrong method to calculate line attention. Asus reports my line attenuation as 19.4dB whereas the HH5 and the ECI state around 25dB. I suspect the Asus is just measuring the S/N on the pilot tone rather than the average of each band.
-
I raised this with Asus last week but so far they haven't answered my question.
My theory is that its this that's causing line instability for so many.
My question to Asus...
Going back to something I mentioned to you earlier this week about my 'Max Attainable Rate' being anything up to 20mbps higher on the Asus than on any other device I own. Just a theory, I'm wondering if there's a bug in the firmware that is responsible for calculating maximum attainable rate in G993.2 VDSL2 mode.
A few AC68U owners I have been in contact with all seem to have a higher rate than with other devices. Could this be responsible for the line instability issues people are experiencing? Something doesn't seem quite right.
Is there a chance this could be looked at?
I'm just waiting on PC World customer support to give me the nod on returning this device. I have the ZyXel I purchased on the cheap a couple of weeks ago and that will be sufficient for me I think for a while. I bought the Asus having purchased primarily Asus devices in the past (laptop, tablets, motherboards etc) and expected better. I may yet opt to swap the device for the RT Wifi/Router version and run in-conjunction with the ZyXel to give me dual band wifi.
-
Well as predicted as s/n approaches 6db crc error rate is increasing. Back to eci with Asus just as a router.
Sent from my LG-D855 using Tapatalk
-
off topic
i had screenshot & guide for using the router stats lite with the ac68u
Now i have make it work with the normal router stats
just use the <td> send it at right tabs... i have set the user 1 & 2 for the errors as well
Note the errors (600 down & 1.200 up) is becuse we have really bad rain here
Really great tool & works good
If any one know the telnet to make it show & the snr spectrum in the telnet will be great
Note all works good ... upstream/downstream snr, speed up/down, errors up/down (via user defined 1 & 2 ) just in the screenshot i make mistake & can not be bother to upload new one, sorry
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1167.photobucket.com%2Falbums%2Fq631%2Fbabis3g%2Fruterstats_zpsff0f14c1.png&hash=0401da201d2927815fa71b084f52bb7639735fdd) (http://s1167.photobucket.com/user/babis3g/media/ruterstats_zpsff0f14c1.png.html)
-
If I don't stay on INP 3 with an 8ms delay then the router most certainly reports far more errors, enough to cause at least two random disconnections each day. I will disable bitswapping again later tonight as I currently have it enabled again. Target SNRM is at 12dB at the moment and DS3 tones are disabled (I will re-enable them later this evening and experiment with disabling all tones where ADSL crosstalk exists, just to see if it helps my situation at all though I doubt it).
At the moment it looks like I need to maintain an SNRM of at least 10dB and an INP of 3 with a delay of 8ms in order to maintain a mostly error free (excluding FEC count) downstream.
-
Sooner or later I think your going to have to admit defeat and either get rid of it or run it as a router only unless Asus can pull off a miracle soon. I'm tired of being an unexpected and unwanted beta tester, I lost faith in it last week but wanted to give them the benefit of the doubt with the latest firmware. If I get DLM'D again tonight despite record low CRC errors then thats it I give up and it will go back as faulty.
-
Sooner or later I think your going to have to admit defeat and either get rid of it or run it as a router only unless Asus can pull off a miracle soon. I'm tired of being an unexpected and unwanted beta tester, I lost faith in it last week but wanted to give them the benefit of the doubt with the latest firmware. If I get DLM'D again tonight despite record low CRC errors then thats it I give up and it will go back as faulty.
Well, sadly I bought it used grade B so I have no option of returning it for a refund from broadbandbuyer. So worst case I guess it'll have to sit in a cupboard collecting dust.
-
It's inherently faulty due to faulty firmware/bad design which you weren't to know about at time of purchase. You should be able to sort something out I would imagine even if it means swapping for a similar priced device from another manufacturer.
-
Guys,
Just had feedback from Asus stating that they are convinced the latest firmware that we are all using 3.0.0.4.376_2139 should resolve our issues, but it was advised to reset and use defaults.
Clearly this is not the case for me, and I have replied back to Asus. If you have problems, please make sure you are reporting them back to Asus. The more feedback and information they get, the quicker we may get working firmware!
-
Some aspects have been resolved but its still far from fixed.
1. I get significantly more FEC errors on this than my ZyXel
2. I get significantly more CRC errors on this than my ZyXel
3. Max Data Rate is incorrect
4. Stats randomly stop working, experienced this twice
5. Intereaving depth is reporting wrong it would seem
-
I have now disabled all ADSL tones (0-512) by setting the minimum DS tone to 520. I doubt this will make any difference to the instability/high FEC count but the way I see it is that there's no ADSL based noise/crosstalk on my connection then. It will be interesting to see if any difference is made to the FEC seconds.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2Fn7nxwAp.png&hash=8859a6d870f035ebbb1c7441849001c212f8bc60)
So far 34 minutes~ uptime:
near-end path0 fec: 1395(289171830)
near-end path0 crc: 0(2603)
near-end fec sec: 18(150482)
near-end err sec: 0(1241)
near-end ses sec: 0(66)
near-end los sec: 0(0)
near-end ua sec: 0(488)
far-end path0 fec: 257(84823)
far-end path0 crc: 0(1118)
far-end fec sec: 7(3373)
far-end err sec: 0(968)
far-end ses sec: 0(0)
far-end los sec: 0(203)
far-end ua sec: 0(11049)
Ignore the numbers in brackets, they are historical.
EDIT #1
59 minutes~:
near-end path0 fec: 2773(289173208)
near-end path0 crc: 0(2603)
near-end fec sec: 35(150499)
near-end err sec: 0(1241)
near-end ses sec: 0(66)
near-end los sec: 0(0)
near-end ua sec: 0(488)
far-end path0 fec: 413(84979)
far-end path0 crc: 0(1118)
far-end fec sec: 12(3378)
far-end err sec: 0(968)
far-end ses sec: 0(0)
far-end los sec: 0(203)
far-end ua sec: 0(11049)
EDIT #2
Nearly 2 hours of uptime:
near-end path0 fec: 5582
near-end path0 crc: 0
near-end fec sec: 68
near-end err sec: 0
near-end ses sec: 0
near-end los sec: 0
near-end ua sec: 0
far-end path0 fec: 1075
far-end path0 crc: 0
far-end fec sec: 25
far-end err sec: 0
far-end ses sec: 0
far-end los sec: 0
far-end ua sec: 0
EDIT #3
4 hours 20 minutes uptime:
near-end path0 fec: 20701
near-end path0 crc: 8
near-end fec sec: 168
near-end err sec: 4
near-end ses sec: 0
near-end los sec: 0
near-end ua sec: 0
far-end path0 fec: 2608
far-end path0 crc: 0
far-end fec sec: 51
far-end err sec: 0
far-end ses sec: 0
far-end los sec: 0
far-end ua sec: 0
-
guys whilst its nice clearly this device has a lot of toys, especially interesting that interleaving and enabled tones can be controlled, ultimately the lack of ability to view ES and the instability would stop me using it, all the reports of improvements are only on low uptime and then later is a post saying it didnt last. :(
The billion 8800nl allows disabling of tones, both manually in telnet with full control or a dumbed down GUI switch which just disables U0, when I disabled U0 tho it didnt appear to work.
I am guessing your issues are down to the non standard chipset used. Chipset compat can play a huge role in dsl stability.
-
Unfortunately this didn't last it seems, but was worth the effort anyway.
I re-synced last night to see what would happen with an INP of 0 and fastpath delay (1ms), errors poured in (ES/SES) and I barely managed to maintain a sync of 10 minutes before losing connection at a target SNRM of 9 dB. The current connection is back at INP 3 with a delay of 8ms which keeps the ES/SES at bay and maintains sync, but unfortunately FEC is rising like before again, so I may as well just enable all tones and maximise the sync speed as much as possible under the INP 3 and delay of 8ms. At least with this modem I can actually avoid the speed banding if I'm prepared to put up with enabling error correction at a fairly low level.
Suffice to say, I still believe I had better stability with older firmware. So I might try going back to an older version later on and see what the FEC does.
-
With the updated firmware, and Target S/N set to 7dB, I had 5 re-syncs last night. Hopefully all this has been captured in the modem log that was sent to Asus this morning as requested.
Could you please submit a Feedback form with “Enable DSL Line Diagnostic” option set as “Yes” and “Diagnostic debug log capture duration” set as 12 hours for our analysis(USB disk/drive needs to be plugged in). Thanks.
This morning, interleave has been increased and my Sync Down reduced by 4MB
I've been advised that they are looking at the Path mode Stats error - i.e that it reports Fastpath when i'm clearly on interleave.
W.r.t. the other issues such as incorrect attenuation estimates and max attainable - this is the response.
Following issues that you raised, please note that these devices based on different chipsets, thus algorithm differs. We currently co-work with chipset vendor and will look into it.
Appreciate that the algorithm differs but the end result should be the same.....
-
They seem to be rather quite lately, I've heard nothing back on the points I raised last week.
1. FEC errors higher than other equipment
2. Attainable rate reporting incorrectly
I was hit by DLM on Sunday morning, I suspect due to the router recording almost 100 million FEC errors.
I'm now back to using the ECI modem so once again 1 step forward, 2 back.
-
guys whilst its nice clearly this device has a lot of toys, especially interesting that interleaving and enabled tones can be controlled, ultimately the lack of ability to view ES and the instability would stop me using it, all the reports of improvements are only on low uptime and then later is a post saying it didnt last. :(
The billion 8800nl allows disabling of tones, both manually in telnet with full control or a dumbed down GUI switch which just disables U0, when I disabled U0 tho it didnt appear to work.
I am guessing your issues are down to the non standard chipset used. Chipset compat can play a huge role in dsl stability.
Just ordered a 8800nl from eBuyer for delivery tomorrow.
-
I've gone back to the HG612 temporarily. Bought myself an online UPS which will basically supply clean electricity to connected devices. While I wasn't expecting it to help with the current situation, on the HG612 I'm apparently still getting a large amount of FEC on the downstream although presumably not as bad as the ASUS. Also observing some specific tone ranges which are getting more bitswaps than the majority of tones (noise?, can these be causing the FEC - at least on the HG612 anyway). Unfortunately the HG612 doesn't have a working method of selecting tones to use/disregard manually, so for the moment I'm just going to observe the statistics.
-
the broadcom telnet command isn't works? depending the broadcom prefix which is changing for some modem makes
(note this is based with adsl, it should work similar for vdsl) have not used the hg612 for years so i am not sure, don't beat me :)
xdslctl connection –-tones 0 32 0xFEFFFF7F 32 224 0xFEFFFFFFFFFFFF7F
selects tones from 1 to 31 for upstream and from 33 to 95 for downstream
-
I have been watching this thread and watching Simon's other threads elsewhere.
Simon, am I to assume you are giving up on the Asus? I went out and got one a couple of weeks ago and mine is as unstable as yours. :)
Mine has now become a WAP as my Draytek 2860n does not have 5Ghz.
Hopefully, one day, Asus will get it sorted and at least I will have a good spare VDSL router!
Good luck with the Billion, I had a 7800, one of the best routers I have ever owned.
-
the broadcom telnet command isn't works? depending the broadcom prefix which is changing for some modem makes
(note this is based with adsl, it should work similar for vdsl) have not used the hg612 for years so i am not sure, don't beat me :)
xdslctl connection –-tones 0 32 0xFEFFFF7F 32 224 0xFEFFFFFFFFFFFF7F
selects tones from 1 to 31 for upstream and from 33 to 95 for downstream
xdslcmd connection [--up] [--down] [--loopback] [--reverb]
[--medley] [--noretrain] [--L3] [--diagmode] [--L0]
[--tones <r1-r2,r3-r4,...>] [--normal] [--freezeReverb] [--freezeMedley]
So I tried xdslcmd connection --up --tones 0-95,32-859,880-1195,1216-1959,1984-2250. This was accepted but didn't change the tones, perhaps this only works on ADSL connections.
-
I have been watching this thread and watching Simon's other threads elsewhere.
Simon, am I to assume you are giving up on the Asus? I went out and got one a couple of weeks ago and mine is as unstable as yours. :)
Mine has now become a WAP as my Draytek 2860n does not have 5Ghz.
Hopefully, one day, Asus will get it sorted and at least I will have a good spare VDSL router!
Good luck with the Billion, I had a 7800, one of the best routers I have ever owned.
Rather than waiting for a resolution, it would help if you started sending logs to Asus. Obviously it is entirely up to you, but unless Asus get feedback, nothing will get resolved.
-
Asus seem to have stopped responding to me. I sent several emails last week and a router diagnostic log, heard nothing.
-
Asus seem to have stopped responding to me. I sent several emails last week and a router diagnostic log, heard nothing.
That's strange and disappointing. I've received correspondence over the last few days and they are currently analyzing my 12 hour log file during which the connection dropped several times.
Check your PM
-
So my Billion 8800nl has been on-line for roughly 5hrs now and here are my error stats so far [below].
The ASUS has been recording approx. 2.5 million FEC errors in a 15min period, yet the Billion reports similar results to both my ZyXel and HG612
The ASUS is going back to PC World having finally received the OK from Customer Services.
[Billion Stats]
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs25.postimg.org%2Ffnund10bj%2Fbillion.jpg&hash=dd3e07941f69910d4356787c493b5b7e38482160)
-
Looks similar to my Draytek, apart from the fact that I am syncing 8Mbps faster than I was with the OR modem.
Please note the Draytek foobar, it states on this page sync rate in kbps, where it's actually KBps. On another page it gives it as just bps, so you need to multiply this figure by 1.024 to get the same speed. I have told them it should be kBps not kbps, however its minor. This was after 10 hours and 15 minutes, I switched the router off by accident this morning! I find it slightly annoying that the figures on the right are from the DLM, and appear never go back to zero unless the DLM is reset. It's over two weeks since the DLM was reset and most of the error count is down to the short periods I had the Asus online. I always get the DS UAS as27 or 28 seconds too, that appears to be the negotiation time.
Just dug my receipt out, going to do the same as you.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs29.postimg.org%2Foyw66kug7%2FCapture.png&hash=826ddfb6334808f27d2b6836197e0db8a0cf8e20)
-
After 10hrs uptime my FEC errors on the BiPac 8800nl are minimal compared to the ASUS.
Since Link time = 10 hours 32 min 58 sec
FEC: 236772 3310
CRC: 4 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
Thanks to geneva78 over at the OcUK forum for sharing, there's new firmware from ASUS for further testing. I'll be trying it this afternoon.
DSL-AC68U_3.0.0.4_376_2143-test.trx
https://www.asuswebstorage.com/navigate/s/B4D64C8A6D6F4C4BBF2DEDB56ADACE984
-
Update 2:
I'm now testing this by forcing fastpath on the downstream. I've kept the sync rate at 49Mbps maximum for the moment, just INP is 0 and delay is 1ms (fastpath). SNRM is approximately 16dB with an attainable downstream rate of 95392.
---
Update 1:
Test concluded. FEC count is now rising every second again. Test failed?
---
Am now on the new firmware, an interesting observation so far is the SNR and bitloading graphs.
Previous firmware:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FGSkeVX0.png&hash=fe238ea857d5fe048ac3d0c0ae673d020b4af81b)
Newest test firmware (2143):
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FMVlka5g.png&hash=e022f47b4db505148b26257644798d8eaeb7fd7d)
As you should see, the newest test firmware produces smoother graphs and makes use of tones nearer the end of the 17MHz, where the older version doesn't. Bear in mind for the above graphs I have UPBO disabled (yes I know it causes some crosstalk, yes I'll be disabling it, but at this point I'm trying anything to see if I can get reduce the FEC's to a count similar to that of the HG612).
Early days yet, all depends on if the FEC goes into the tens or hundreds of millions after 24-48 hours of uptime.
near-end path0 fec: 2255(2255)
snear-end path0 crc: 0(0)
near-end fec sec: 35(35)
=near-end err sec: 0(0)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(0)
far-end path0 fec: 0(129580)
far-end path0 crc: 0(1120)
far-end fec sec: 0(3925)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(233)
far-end ua sec: 0(12793)
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=12.2 dB
AttenDown=10.5 dB
SNRMarginUp=12.2 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=2255
FECUp=0
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=11 min, 52 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.7 dbm
PowerUp=8.8 dbm
AttainUp=32919
AttainDown=110312
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
-
Just got a full refund no quibble after 6 weeks , they are being returned thick n fast the guy said at PC World
-
Well, conclusion from my testing is that this test firmware hasn't helped. The underlying problem still exists. In order to keep a stable connection I must remain on interleaving. If I want to go on fastpath I must maintain at least an SNRM of 15dB or higher on the downstream in order to maintain a stable connection with some error seconds. All problems are via the downstream, the upstream is fine whether it's fastpath or not.
The only reasons I'm sticking to this device is because it allows me to override the speed banding, meaning I'm now able to sync at 75Mbps~ with interleaving rather than DLM's speed banding of 49Mbps with interleaving. If it wasn't for that then I would be complaining to broadbandbuyer stating that this device is badly designed (not fit for purpose) and that I would like a refund applied as a credit on the account (as I bought it used, grade B). I'm hoping eventually ASUS will hit on the problem and fix it, but assuming they are making changes in each version, they are still continuing on releasing various beta/test firmwares it seems.
-
with my adsl connection the spectrum frequencies are wider (better) & more clear with the _2143_test
-
Just got a full refund no quibble after 6 weeks , they are being returned thick n fast the guy said at PC World
Sadly mine has gone to keep yours company.
-
Well, conclusion from my testing is that this test firmware hasn't helped. The underlying problem still exists. In order to keep a stable connection I must remain on interleaving. If I want to go on fastpath I must maintain at least an SNRM of 15dB or higher on the downstream in order to maintain a stable connection with some error seconds. All problems are via the downstream, the upstream is fine whether it's fastpath or not.
The only reasons I'm sticking to this device is because it allows me to override the speed banding, meaning I'm now able to sync at 75Mbps~ with interleaving rather than DLM's speed banding of 49Mbps with interleaving. If it wasn't for that then I would be complaining to broadbandbuyer stating that this device is badly designed (not fit for purpose) and that I would like a refund applied as a credit on the account (as I bought it used, grade B). I'm hoping eventually ASUS will hit on the problem and fix it, but assuming they are making changes in each version, they are still continuing on releasing various beta/test firmwares it seems.
if you don't mind because you testing different options (as i don't have vdsl) ... can you try the following with the new beta, at least for few minutes to see if errors are increasing
Set manually vdsl2
annex B
all disable
and enable vector g 993.5
once the modem will attempt to re-synchronize, will be good to give a manual reboot from the back button once the 100% process done
-
Just got a full refund no quibble after 6 weeks , they are being returned thick n fast the guy said at PC World
Sadly mine has gone to keep yours company.
I was kind of sorry to let it go but I'm buggered if I'm paying £160 for a half functional device.
Had ASUS been a bit more reassuring over fixing it and forthcoming about issues then I might have kept it.
I still haven't received any reply to my emails sent on the 8/10th November.
The way I see it is they owe this group and others a big thanks for all their feedback/testing as well as a big apology.
-
Well, conclusion from my testing is that this test firmware hasn't helped. The underlying problem still exists. In order to keep a stable connection I must remain on interleaving. If I want to go on fastpath I must maintain at least an SNRM of 15dB or higher on the downstream in order to maintain a stable connection with some error seconds. All problems are via the downstream, the upstream is fine whether it's fastpath or not.
The only reasons I'm sticking to this device is because it allows me to override the speed banding, meaning I'm now able to sync at 75Mbps~ with interleaving rather than DLM's speed banding of 49Mbps with interleaving. If it wasn't for that then I would be complaining to broadbandbuyer stating that this device is badly designed (not fit for purpose) and that I would like a refund applied as a credit on the account (as I bought it used, grade B). I'm hoping eventually ASUS will hit on the problem and fix it, but assuming they are making changes in each version, they are still continuing on releasing various beta/test firmwares it seems.
if you don't mind because you testing different options (as i don't have vdsl) ... can you try the following with the new beta, at least for few minutes to see if errors are increasing
Set manually vdsl2
annex B
all disable
and enable vector g 993.5
once the modem will attempt to re-synchronize, will be good to give a manual reboot from the back button once the 100% process done
Already tried similar settings with 'annex A', setting 'annex B' doesn't work on UK VDSL2 as it's 'annex A' here. Sadly it produces the same level of errors.
I'm still playing around with mine, at the moment I'm trying various things such as changes to 'agc_vref' beyond the range on the GUI.
EDIT 1:
I've reduced agc_vref to 0. I'll post results later today and keep everyone updated. When I set agc_vref to some higher number than usual, I get much more errors, so I figured I'd try 0 (which I imagine either stops boosting it or disables it. Rx AGC gain on the GUI when set to disabled appears to just make the agc_vref 440 (which is still gaining as I see it?). Maybe this is causing all of our errors on VDSL2?
EDIT 2:
Test concluded. After 4 hours the FEC has started exponentially rising :(. I will try this out on fastpath later this evening with the same agc_vref, but I doubt it's going to help long term.
-
Ixel something is up if a line of your spec needs interleaving. Especially if it struggles at 9db snrm as well.
-
Ixel something is up if a line of your spec needs interleaving. Especially if it struggles at 9db snrm as well.
Well, some of the problem is clearly this device, but I do think there is something wrong with the line again - however I'm not prepared to risk paying a callout fee so I'll just make the best of what I can. Nothing really obvious has shown up in the Hlog or QLN graphs when on the HG612 unfortunately. I'll persist with this device as it's the most customisable option out there at the moment.
Later tonight I will try putting the DSL-AC68U back on fastpath with the current agc_vref setting (0 instead of 440) to see what happens, as having it on interleaved isn't a fair and harsh test for it. The HG612 has held on at 49Mbps on fastpath in the past. I've had 74Mbps on the ECI /r with fastpath as well (although unable to get that currently as DLM banded me).
-
Here are the results from last night until now, with an agc_vref setting of 300 300 300 300.
near-end path0 crc: 8715(758)
near-end fec sec: 275(21315)
near-end err sec: 268(347)
near-end ses sec: 22(36)
near-end los sec: 0(0)
near-end ua sec: 32(289)
far-end path0 fec: 4601(155675)
far-end path0 crc: 0(1120)
far-end fec sec: 48(4224)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(276)
far-end ua sec: 0(13649)
outPkts=7828964
inPkts=10296575
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.9 dB
AttenDown=10.3 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=72204 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=79164
FECUp=4601
CRCDown=8715
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 7:30, 15 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=13.0 dbm
PowerUp=4.8 dbm
AttainUp=25872
AttainDown=86380
ShowtimeStart=19
TotalStart=5296
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
Had a burst of errors during the uptime somewhere, other than that it was mostly trickling of CRC's (around a rate of 1 every 2-3 minutes, which is about normal for my line at this speed :x).
The above was fastpath (INP 0, delay 1ms) with a target SNRM of 9.0 dB.
I've now reduced the target SNRM to 7.0 dB, the agc_vref setting to 250 250 200 250, and have increased delay to 3ms while keeping INP at 0. Will post results later today.
On the previous connection I would've lost sync usually long before the 7 hour uptime.
-
Just updating this thread to mention a new firmware update has been released by ASUS, both officially and otherwise.
New firmware are listed on their website's support page, but particularly at the moment I'm using the unofficial beta release that geneva78 shared today over at the OCUK forum.
DSL-AC68U_3.0.0.4_376_2144-ga120ce8_DSL_1.0.1.9_1124.trx
https://www.asuswebstorage.com/navigate/s/ED60F694BDFC4F6FA4548FFC522FD5494
So far it's proving to work superb, no CRC's at all since uptime. Usually even with interleaving I get some ES/CRC by now. UPBO is disabled as I forgot to set it to auto before reconnecting the DSL cable, so my attainable upload is higher than usual at the moment. I've not done a factory reset either, might not be needed.
>tcapi get Info_Adsl lineState;tcapi show Info_Adsl;wan vdsl2 show mgcnt
up
near-end path0 fec: 15888(15888)
near-end path0 crc: 0(0)
near-end fec sec: 98(98)
near-end err sec: 0(0)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(0)
far-end path0 fec: 163(207517)
far-end path0 crc: 0(1160)
far-end fec sec: 3(4715)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(328)
far-end ua sec: 0(14579)
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=11.7 dB
AttenDown=10.4 dB
SNRMarginUp=12.4 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=15888
FECUp=163
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 1:29, 40 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.9 dbm
PowerUp=8.4 dbm
AttainUp=33399
AttainDown=107260
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
If by 6pm the FEC count and CRC is still extremely lower than usual then I will override the downstream DSLAM parameters (fastpath with up to 80Mbps sync rate) and test that. So far things are looking very good though, ASUS might have solved this at long last. Two other members on the OCUK forum also say no CRC's yet.
-
Hi ixel, thanks for the update ... can you create with the new beta a TBB monitor? is not issue just for my knowledge, Thanks
-
Hi ixel, thanks for the update ... can you create with the new beta a TBB monitor? is not issue just for my knowledge, Thanks
TBB monitor?
EDIT: I assume you mean the following.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2F49f33c13bb7c097fe92d1ca1a66f6922.png&hash=c7498c26e36b7343fa7d19f04548c070ebd774e4) (http://www.thinkbroadband.com/ping/share/49f33c13bb7c097fe92d1ca1a66f6922.html)
EDIT 2: It doesn't appear to be graphing my IP, even though firewall allows pings.
EDIT 3: Fixed.
-
yes thanks but at firewall you need enable responding ping from wan to work (should not ask for reboot just enable it)
here is mine (adsl) but if later on will not display any longer, is because i have dynamic ip so i will need to set a new one
Note the high green latency is because i am pinging from Greece :blush: ( i am down here till xmas, perhaps longer) & here the small dslam is full so now coming peak time will be spikes but is normal for my connection
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2F6e5e2aa203bd6d5d6d34fabd5c25c314.png&hash=f2ec620163c88ceb7d309c2c4f70cda108488f46) (http://www.thinkbroadband.com/ping/share/6e5e2aa203bd6d5d6d34fabd5c25c314.html)
Done a reboot and now the monitor' s frequent red spikes are much less (well at the moment), a new one created because i have dynamic ip
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2Fc5211bdf2ea94da58e1e577f8ff74972-25-11-2014.png&hash=c968a5028dd47ee581b4b8047a36b4917bcca0c5) (http://www.thinkbroadband.com/ping/share/c5211bdf2ea94da58e1e577f8ff74972-25-11-2014.html)
-
at network map of the asus copy the external ip & paste it at the monitor , also note it has 5 minutes delay so should appear monitoring soon
if you ip is dynamic then it will stop monitoring & you will have to create a new one
i can see is appearing working now :)
-
at network map of the asus copy the external ip & paste it at the monitor , also note it has 5 minutes delay so should appear monitoring soon
if you ip is dynamic then it will stop monitoring & you will have to create a new one
i see is coming :)
Fixed it. It was the firewall on the router which was misconfigured, perhaps due to the firmware update changing the settings somehow.
My network has a block of 8 public static IP's, so slight different configuration than the usual static or dynamic IP that is allocated to a connection.
-
thanks for posting :) , its working good, the monitor is clear .. you can remove it from the forum if you wish because we can see & your internet usage bandwidth :D unless you don't mind
-
The latest beta firmware from the ASUS web storage is proving to be excellent so far (other than the FEC count), I will be interupting the connection in the next hour or so to switch to fastpath on 80M sync. Not a single CRC error in over 10 hours! On the HG612 I get some ES/CRC under the same connection conditions.
>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show Info_Adsl
up
near-end path0 fec: 37262819(37262143)
near-end path0 crc: 0(0)
near-end fec sec: 20405(20405)
near-end err sec: 0(0)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(0)
far-end path0 fec: 2407(209761)
far-end path0 crc: 0(1160)
far-end fec sec: 33(4745)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(328)
far-end ua sec: 0(14579)
outDiscards=484
inDiscards=46
outBytes=702223663
inBytes=393361223
outPkts=3077299
inPkts=4094218
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=12.0 dB
AttenDown=10.4 dB
SNRMarginUp=12.5 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=37261351
FECUp=2407
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=10:11, 40 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.9 dbm
PowerUp=8.4 dbm
AttainUp=33488
AttainDown=111028
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
-
:) i can see from the monitor fastpath is already on and seems from the first 30 min is going well?
-
:) i can see from the monitor fastpath is already on and seems from the first 30 min is going well?
Yes. I've switched it to fastpath (not full speed yet though, will do that in the next hour, so still 49M out of 80M sync downstream).
>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show Info_Adsl
up
near-end path0 fec: 0(52455869)
near-end path0 crc: 16(16)
near-end fec sec: 0(26771)
near-end err sec: 14(14)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(31)
far-end path0 fec: 1090(211333)
far-end path0 crc: 0(1160)
far-end fec sec: 8(4761)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(333)
far-end ua sec: 0(14607)
outDiscards=278
inDiscards=82
outBytes=899890480
inBytes=1791472672
outPkts=3891256
inPkts=5244281
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=15.0 dB
AttenDown=10.4 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=0
FECUp=1090
CRCDown=16
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=51 min, 56 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.7 dbm
PowerUp=4.8 dbm
AttainUp=25872
AttainDown=91512
ShowtimeStart=18
TotalStart=37
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
Similar results to the HG612 so far.
EDIT 1:
Went to 80Mbps sync rate on fastpath and the results were plenty of CRC errors. Either the router doesn't handle a 6dB SNRM on fastpath well (for downstream) or my line would just perform that way now due to crosstalk or some other interference - sadly can't verify this as the HG612 will be speed banded to 49Mbps sync rate.
I'm now testing 80Mbps sync rate with 8ms delay and 0 INP.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F3935589735.png&hash=3d6320d11c07b743571244a2f76b212aa2a27a85)
Despite high FEC's so far, absolutely no CRC's.
80Mbps, INP 0, Delay 8ms, DSL-AC68U_3.0.0.4_376_2144-ga120ce8_DSL_1.0.1.9_1124.trx:
>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show Info_Adsl
up
near-end path0 fec: 97044(52552913)
near-end path0 crc: 0(78)
near-end fec sec: 164(26935)
near-end err sec: 0(44)
near-end ses sec: 0(7)
near-end los sec: 0(0)
near-end ua sec: 0(108)
far-end path0 fec: 0(212902)
far-end path0 crc: 0(1160)
far-end fec sec: 0(4774)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(342)
far-end ua sec: 0(14664)
outDiscards=293
inDiscards=1126
outBytes=1117761026
inBytes=3471247675
outPkts=5994115
inPkts=9249751
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.3 dB
AttenDown=10.4 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=79969 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=97044
FECUp=0
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=14 min, 31 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.9 dbm
PowerUp=4.7 dbm
AttainUp=25713
AttainDown=103156
ShowtimeStart=19
TotalStart=74
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=357
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
-
ixel you will get crc errors on fast path, it simply will happen.
How many was you getting per hour? as you posted only 16 error which is nothing. I wouldnt be deliberately putting my line on interleaving just because of some crc errors. I would only do it if the actual service was been affected.
Also if you really think your line cannot handle 6db fast path then better to go 9db fast path instead of interleaving in my view.
-
ixel you will get crc errors on fast path, it simply will happen.
How many was you getting per hour? as you posted only 16 error which is nothing. I wouldnt be deliberately putting my line on interleaving just because of some crc errors. I would only do it if the actual service was been affected.
Also if you really think your line cannot handle 6db fast path then better to go 9db fast path instead of interleaving in my view.
Yeah I understand that. I'll give 9 dB fastpath a try.
6 dB (80Mbps) fastpath for 12 min 40 sec gave me the following:
near-end path0 fec: 0(52455869)
near-end path0 crc: 7872(63)
near-end fec sec: 0(26771)
near-end err sec: 36(39)
near-end ses sec: 7(7)
near-end los sec: 0(0)
near-end ua sec: 15(77)
EDIT 1: When I had the 16 errors, I also left the speed banding at 49Mbps which gave me an SNRM of 15.0 dB.
EDIT 2: The following are statistics on 9 dB fastpath for almost 15 minutes uptime so far.
near-end path0 fec: 520(52766504)
near-end path0 crc: 80(379)
near-end fec sec: 56(27746)
near-end err sec: 45(124)
near-end ses sec: 1(9)
near-end los sec: 0(0)
near-end ua sec: 0(166)
EDIT 3: The following are statistics on 9 dB fastpath for 1h 35m~ uptime. Unfortunately while the CRC's are low and not effecting reliability or performance, the error seconds is high and if it continues at the current trend it will most likely exceed the MTBE for DLM I imagine.
near-end path0 fec: 4156(52770140)
near-end path0 crc: 401(700)
near-end fec sec: 626(28316)
near-end err sec: 269(348)
near-end ses sec: 1(9)
near-end los sec: 0(0)
near-end ua sec: 0(166)
far-end path0 fec: 929(217866)
far-end path0 crc: 0(1160)
far-end fec sec: 17(4842)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(348)
far-end ua sec: 0(14717)
outDiscards=305
inDiscards=1489
outBytes=1641448920
inBytes=879083683
outPkts=7529907
inPkts=10804049
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.9 dB
AttenDown=10.4 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=72876 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=4156
FECUp=929
CRCDown=401
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 1:35, 35 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.9 dbm
PowerUp=4.7 dbm
AttainUp=26050
AttainDown=87188
ShowtimeStart=19
TotalStart=112
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
-
to give you a comparison here is mine so far today.
Latest 1 day time = 19 hours 10 min 9 sec
FEC: 0 53
CRC: 1293 5
ES: 114 5
SES: 3 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
I think as long as the errors trickle in its fine. Its a problem when you start getting consistent high amounts, I occasionally get what I think is SHINE an ES where is like 500 or so CRC in one go, but that will be just 1 second and probably not a big deal.
Here my stats for yesterday which is higher.
Previous 1 day time = 24 hours 0 sec
FEC: 0 80
CRC: 3974 8
ES: 233 8
SES: 4 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
I been using the central heating which I think is affecting my error rates, but even with that been the case, my service works fine.
-
Can anyone please help! I just can't my DSL-AC68U to work with BT Broadband (it's not Fibre/Infinity). I've got what I believe are the correct setting but it just won't connect :(
I guess my 1st question is should it work! I have also downloaded and patched up the latest firmware (DSL-AC68U_3.0.0.4_376_2072-gf4a1e74_DSL_1.0.1.7.trx).
Please, please help.
Thanks!
-
Can anyone please help! I just can't my DSL-AC68U to work with BT Broadband (it's not Fibre/Infinity). I've got what I believe are the correct setting but it just won't connect :(
I guess my 1st question is should it work! I have also downloaded and patched up the latest firmware (DSL-AC68U_3.0.0.4_376_2072-gf4a1e74_DSL_1.0.1.7.trx).
Please, please help.
Thanks!
Yes it will work.
If I were you I would download firmware 2155 (2072 is definitely not the latest) then do a full reset to restore the settings to default (long press on reset button). Follow the wizard to configure your Internet connection. Use bthomehub@btbroadband.com for the user name and BT for the password and it should work.
-
Thanks for the advice but unfortunately it still doesn't work. When I run the Wizard after the Firmware update it just keeps flashing up a message along the lines of 'Please ensure the DSL line is connected' which it is! The DSL line on the front occasionally flashes but that's as far as it gets, I have to click the Home button and continue manually.
I've tried all sorts of settings in the manual config with no luck. I've tried different filters and cables (including what came with BT HomeHub 3 which work fine) and still nothing, as soon as I connect the BT HomeHub, all works fine.
Do you think it could just be a faulty unit :no:
Cheers.
-
Thanks for the advice but unfortunately it still doesn't work. When I run the Wizard after the Firmware update it just keeps flashing up a message along the lines of 'Please ensure the DSL line is connected' which it is! The DSL line on the front occasionally flashes but that's as far as it gets, I have to click the Home button and continue manually.
I've tried all sorts of settings in the manual config with no luck. I've tried different filters and cables (including what came with BT HomeHub 3 which work fine) and still nothing, as soon as I connect the BT HomeHub, all works fine.
Do you think it could just be a faulty unit :no:
Cheers.
It's possible that you have a faulty unit. Try to exchange it.
-
I agree, it sounds like a faulty unit to me, I don't recall getting the same problems on mine.
Well, I haven't posted much about mine in a while, but over at OcUK there's been a lot of discussion on-going. After much perserverence babis3g and I may be now onto something causing the CRC errors. Time will tell, but looking promising at the moment. Every 12-24 hours I'm increasing the downstream sync rate as well as toggling between fastpath and an extremely light level of interleaving on the downstream (1ms 0INP and 3ms 0INP respectively). For the purpose of the tests I'm no longer looking at the FEC value, as I don't think/believe the Openreach DLM does anyway (it's such an unreliable value to consider in my opinion). I'm just considering CRC errors, error seconds, severe error seconds and any loss of sync.
Babis3g came up with the idea that the spectrum monitor might be causing the instability, so after I also noticed it running via telnet as 'spectrum' process, we've both killed it and so far results look good.
For a couple of hours during the early hours of the morning I tried 49Mbps on fastpath and the results were no spiking of CRC errors, just a standard trickle much like the HG612. Prior to that I had tested a 3ms delay with 0 INP (very light interleaving) at 49Mbps for quite a few hours and that yielded only a few CRC errors/error seconds (except for the FEC going wild, but I'm ignoring that).
Now I'm testing 54Mbps with 3ms delay at 0 INP. FEC out of control as expected, but after a few hours of uptime so far the CRC's are almost non-existent on the downstream despite the very light level of interleaving I've currently applied at the moment (almost fastpath). In the past I don't recall being able to apply such a low level of interleaving to this sync rate/SNRM.
DSL Settings
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FnfSSATU.png&hash=367fc2d14b68f4a9da944b17c2d9075b6bc96355)
Firmware Version 2155
DS bearer channel 0 configuration
Min_net_data_rate = 128 kbit/s
Max_net_data_rate = 54000 kbit/s
Max_interleaving_delay = 3 ms
INP_min = 0 symbols
near-end path0 fec: 6140400(19875159)
near-end path0 crc: 6(82)
near-end fec sec: 10313(18138)
near-end err sec: 4(67)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(193)
far-end path0 fec: 471(477935)
far-end path0 crc: 0(1929)
far-end fec sec: 9(8188)
far-end err sec: 0(1447)
far-end ses sec: 0(0)
far-end los sec: 0(676)
far-end ua sec: 0(29479)
outDiscards=67
inDiscards=75
outBytes=876715439
inBytes=2412468665
outPkts=13642178
inPkts=15170414
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.8 dB
AttenDown=10.2 dB
SNRMarginUp=9.3 dB
AttenUp=0.1 dB
DataRateDown=53999 kbps
DataRateUp=20000 kbps
WanListMode=0
FECDown=6140400
FECUp=471
CRCDown=6
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 3:02, 19 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.1 dbm
PowerUp=6.4 dbm
AttainUp=28033
AttainDown=103020
ShowtimeStart=18
TotalStart=131
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=573
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
-
Thanks for the advice but unfortunately it still doesn't work. When I run the Wizard after the Firmware update it just keeps flashing up a message along the lines of 'Please ensure the DSL line is connected' which it is! The DSL line on the front occasionally flashes but that's as far as it gets, I have to click the Home button and continue manually.
I've tried all sorts of settings in the manual config with no luck. I've tried different filters and cables (including what came with BT HomeHub 3 which work fine) and still nothing, as soon as I connect the BT HomeHub, all works fine.
Do you think it could just be a faulty unit :no:
Cheers.
It's possible that you have a faulty unit. Try to exchange it.
Cheers guys, that's what I thought! Got from Amazon so easy return policy, sending back so we'll see what happens. Just a quick question whilst I think of it, is this a good replacement for the BT HomeHub 4? I'm having real problems with Firewall and port forwarding and was hoping this unit would help resolve those issues?!
Thanks.
-
Thanks for the advice but unfortunately it still doesn't work. When I run the Wizard after the Firmware update it just keeps flashing up a message along the lines of 'Please ensure the DSL line is connected' which it is! The DSL line on the front occasionally flashes but that's as far as it gets, I have to click the Home button and continue manually.
I've tried all sorts of settings in the manual config with no luck. I've tried different filters and cables (including what came with BT HomeHub 3 which work fine) and still nothing, as soon as I connect the BT HomeHub, all works fine.
Do you think it could just be a faulty unit :no:
Cheers.
It's possible that you have a faulty unit. Try to exchange it.
Cheers guys, that's what I thought! Got from Amazon so easy return policy, sending back so we'll see what happens. Just a quick question whilst I think of it, is this a good replacement for the BT HomeHub 4? I'm having real problems with Firewall and port forwarding and was hoping this unit would help resolve those issues?!
Thanks.
It's a very good replacement.
-
Another update, almost 15 hours in on 54Mbps downstream, 0 INP and 3ms delay:
near-end path0 fec: 77443373(91177901)
near-end path0 crc: 34(110)
near-end fec sec: 50905(58730)
near-end err sec: 18(81)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(193)
far-end path0 fec: 2533(479997)
far-end path0 crc: 0(1929)
far-end fec sec: 60(8239)
far-end err sec: 0(1447)
far-end ses sec: 0(0)
far-end los sec: 0(676)
far-end ua sec: 0(29479)
outDiscards=591
inDiscards=200
outBytes=24557350
inBytes=3069998826
outPkts=24802074
inPkts=28249012
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=9.3 dB
AttenDown=10.2 dB
SNRMarginUp=9.3 dB
AttenUp=0.1 dB
DataRateDown=53999 kbps
DataRateUp=20000 kbps
WanListMode=0
FECDown=77443373
FECUp=2533
CRCDown=34
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=14:43, 27 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.1 dbm
PowerUp=6.4 dbm
AttainUp=28026
AttainDown=106212
ShowtimeStart=18
TotalStart=131
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=573
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
Bitloading for DS2:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FzPjbSRi.png&hash=f66673b3046307fea23e75f5a8ff3974cd956d0f)
Slight bit of interference on DS2, but the error seconds and CRC errors remain low. When I nudge the speed up to 60Mbps I will also reduce the delay to 2ms to see what possible difference it has. I know 3ms virtually prevents the trickle of small CRC errors that I usually experience every 3 to 15 minutes (even on the HG612 I encountered that on fastpath). FEC is stupidly high but I'm ignoring that. Perhaps Openreach should've provisioned fastpath as a 3ms delay instead (at least on the downstream)? It does seem to make a massive difference to the minor trickling CRC errors without causing a noticeable latency increase when gaming.
It's looking more likely that spectrum monitoring is somehow causing the instability issues.
-
All hell would break loose if 3ms was the min latency, remember your line behaviour is unusual, pretty much 99% of lines syncing at 70mbit+ are fine on fast path.
We dont know if this behaviour is due to your choice of modem or a line issue tho.
Why havent you tried enabling FEC yet on fastpath? You seem to really want to use interleaving.
Latency affects all sorts of things not just gaming. RTT, web site browsing, DNS lookups and more.
-
All hell would break loose if 3ms was the min latency, remember your line behaviour is unusual, pretty much 99% of lines syncing at 70mbit+ are fine on fast path.
We dont know if this behaviour is due to your choice of modem or a line issue tho.
Why havent you tried enabling FEC yet on fastpath? You seem to really want to use interleaving.
I guess, isn't the 'delay' being greater than 1ms enabling interleaving/FEC though - the higher the delay value is then the greater the depth? I had my downstream set on 3ms delay for the downstream with 0 INP yesterday, hardly any errors. I'm currently synced at 80Mbps now with 2ms delay, but might nudge it back up to 3ms or even 4ms to reduce the trickle of CRC errors I get here. As you say, it could be an incompatibility with ECI DSLAM (Infineon) and the modem's chipset or it could just be my line. I'd prefer to keep the delay as low as possible as I notice the effects when downstream or upstream is at least a delay of 8ms or higher (from a gamer's perspective, especially as a sniper).
What I will be doing after today, if the problem identified with the ASUS is now temporarily fixed by killing the spectrum process, is setting a delay/INP high enough on the downstream to keep the MTBE good enough to hopefully encourage DLM to do positive changes. If it will and once it has then I'll re-apply my own delay and INP (if DLM should not quite get to what I'd prefer). Hopefully that won't take more than 2-3 weeks, but it depends on how high the caution counter is I guess. Hopefully DLM doesn't consider FEC in its decisions.
near-end path0 fec: 39471996(135791523)
near-end path0 crc: 302(404)
near-end fec sec: 12154(75196)
near-end err sec: 89(175)
near-end ses sec: 1(1)
near-end los sec: 0(0)
near-end ua sec: 0(289)
far-end path0 fec: 3920(489415)
far-end path0 crc: 0(1944)
far-end fec sec: 56(8306)
far-end err sec: 0(1447)
far-end ses sec: 0(0)
far-end los sec: 0(685)
far-end ua sec: 0(29567)
outDiscards=1312
inDiscards=616
outBytes=3044332059
inBytes=1110518930
outPkts=30223056
inPkts=31633832
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=9.6 dB
AttenDown=10.3 dB
SNRMarginUp=7.1 dB
AttenUp=0.1 dB
DataRateDown=79972 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=39471750
FECUp=3920
CRCDown=302
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 9:06, 17 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=5.0 dbm
AttainUp=25579
AttainDown=112500
ShowtimeStart=19
TotalStart=187
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=88
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
-
FEC can be enabled with a 1ms delay, it just isnt as effective as is with higher delays, the default openreach config has FEC enabled on upstream fast path.
-
FEC can be enabled with a 1ms delay, it just isnt as effective as is with higher delays, the default openreach config has FEC enabled on upstream fast path.
I see, that's interesting. I don't think there's a setting on the ASUS's wan commands to do that (enable FEC with 1ms), only to modify the delay (where 1ms says it's fastpath, and >= 2ms is interleaved). For my connection so far I've found a delay of either 3ms or 4ms to work best at reducing the slow trickle of CRC errors to very few, I'm happy with that (certainly better than 8ms at INP 3 or higher :)).
-
£180 for the DSL-AC68U that's to expensive for me :o
I would not mind getting rid of HG612 & HH3 for an all in one but it would need to be closer to £100 before I upgrade/downgrade :-[
-
£180 for the DSL-AC68U that's to expensive for me :o
I would not mind getting rid of HG612 & HH3 for an all in one but it would need to be closer to £100 before I upgrade/downgrade :-[
Yeah, for some people it's beyond what they are willing to spend. I was close to giving up with this and getting a Fritzbox 7490 (more expensive, but have heard good things about it). However, now that the ASUS appears to be stable since killing spectrum, I'm glad I didn't.
-
Yeah, for some people it's beyond what they are willing to spend. I was close to giving up with this and getting a Fritzbox 7490 (more expensive, but have heard good things about it). However, now that the ASUS appears to be stable since killing spectrum, I'm glad I didn't.
I'm not an expert on modem/routers if what I have works i'll be happy it's just you need to persuade me that the DSL-AC68U will perform better for long line for example SNRm will be higher than the HG612 and so on, quite happy to adjust the modem config to specific settings that work well.
-
£180 for the DSL-AC68U that's to expensive for me :o
I would not mind getting rid of HG612 & HH3 for an all in one but it would need to be closer to £100 before I upgrade/downgrade :-[
8800nl
and yes its actually stable (and cheap).
I use the 8800nl in bridge mode but I would expect it to match the hh3 for spec as a router, in fact I think it exceeds the hh3.
check my uptime on Mydslwebstats. Same chipset as hg612 so you know what you getting, just its a higher revision.
-
Hello everyone , i'm having a problem with Remote desktop Connection because i cannot open port 3389 . I have opened a port for Utorrent and it works . I deactivated NAT acceleration as suggested in other forums but still nothing . I can connect to my other pc via Remote desktop from home but i cannot connect from my work using a different network . Any suggestions ?
-
Have you used something like canyouseeme.org to check that the port is actually open?
-
Yes , canyouseeme.org , www.yougetsignal.com/tools/open-ports/ , show the port is not open although i have opened it in port/forwarding section . The other port for Utorrent is open .I have the latest firmware . Is there any custom firmware ?
-
Does your ISP block that port? Try using 3390 or another port and check it.
-
I was using my ISP's modem ( Speedport w 724v ) and had no problem , although it's not as good as Asus . I added port 3390 but it shows as closed on www.canyouseeme.org .
-
Never mind , thank you for the replies , i found that my ISP was blocking the port . It was in a subcategory under a subcategory under a subcategory . :baby: Thank you again .
-
Through all my stability testing, with spectrum disabled/removed this device has been stable on my VDSL2 connection on near fastpath conditions and an SNRM between 6dB to 9dB throughout various syncs I've done. Therefore I'm concluding that it was the spectrum monitoring which was very likely causing many people stability issues with the modem. ASUS will most likely tweak the spectrum monitoring so that it doesn't demand so much from the modem chipset I imagine. At least the device now appears to be stable, so those who still own one will be very pleased as I am too.
-
Thanks for the advise, I have a new unit which is now working. Was just unlucky with the previous being faulty!
However, my internet speed is approximately half of what I got through my BT HomeHub. Does anyone have any DSL configs that would address this?
Thanks.
Thanks for the advice but unfortunately it still doesn't work. When I run the Wizard after the Firmware update it just keeps flashing up a message along the lines of 'Please ensure the DSL line is connected' which it is! The DSL line on the front occasionally flashes but that's as far as it gets, I have to click the Home button and continue manually.
I've tried all sorts of settings in the manual config with no luck. I've tried different filters and cables (including what came with BT HomeHub 3 which work fine) and still nothing, as soon as I connect the BT HomeHub, all works fine.
Do you think it could just be a faulty unit :no:
Cheers.
It's possible that you have a faulty unit. Try to exchange it.
-
Could DLM have intervened? That's my first guess. Did you have a much higher speed moments before unplugging the previous connected device?
Post the stats if you can.
-
Could DLM have intervened? That's my first guess. Did you have a much higher speed moments before unplugging the previous connected device?
Post the stats if you can.
I don't believe so, my download with the HomeHub was a pretty reliable and constant 5Mbps (I know, slow :(), now I get around 2.6Mbps (source is speedtest.net via LAN). If I connect the HomeHub back in I get the normal 5Mbps immediately.
Thanks.
-
Could DLM have intervened? That's my first guess. Did you have a much higher speed moments before unplugging the previous connected device?
Post the stats if you can.
I don't believe so, my download with the HomeHub was a pretty reliable and constant 5Mbps (I know, slow :(), now I get around 2.6Mbps (source is speedtest.net via LAN). If I connect the HomeHub back in I get the normal 5Mbps immediately.
Thanks.
Oh I see, I assume this is ADSL (I was thinking you had FTTC/VDSL2)? Still, if you can then please post a screenshot of the stats page.
-
Could DLM have intervened? That's my first guess. Did you have a much higher speed moments before unplugging the previous connected device?
Post the stats if you can.
I don't believe so, my download with the HomeHub was a pretty reliable and constant 5Mbps (I know, slow :(), now I get around 2.6Mbps (source is speedtest.net via LAN). If I connect the HomeHub back in I get the normal 5Mbps immediately.
Thanks.
Oh I see, I assume this is ADSL (I was thinking you had FTTC/VDSL2)? Still, if you can then please post a screenshot of the stats page.
Thanks, I'll get this uploaded, but what stats exactly? Do you mean my WAN setting, DSL settings or something else? Please let me know as I really appreciate any assistance on this, thanks.
-
Thanks, I'll get this uploaded, but what stats exactly? Do you mean my WAN setting, DSL settings or something else? Please let me know as I really appreciate any assistance on this, thanks.
Assuming the LAN IP is still default, this should get you to the DSL statistics: http://192.168.1.1/Main_AdslStatus_Content.asp
-
Thanks, I'll get this uploaded, but what stats exactly? Do you mean my WAN setting, DSL settings or something else? Please let me know as I really appreciate any assistance on this, thanks.
Assuming the LAN IP is still default, this should get you to the DSL statistics: http://192.168.1.1/Main_AdslStatus_Content.asp
Great thanks, attached.
-
That's a lot of CRC errors in such a short time. You might be being effected by the 'spectrum' process on this device, killing that process via telnet is the solution at the moment.
Enable telnet access via the admin settings page, then use something such as PuTTY and connect via telnet to your router - the telnet login will be the same as your web UI login. When you're in then run the following command:
killall -9 spectrum
This will need to be done if you reboot the device, at least until ASUS have fixed the spectrum monitoring process to not cause the stability problems on the modem.
As for your speed, try going to the 'Adminstration > DSL Settings' page, disable 'Dynamic Line Adjustment (ADSL)' and set the 'Stability Adjustment (ADSL)' to '-X dB' (where X is something like minus 3 for example, try reducing it until your actual downstream SNRM is around 6 dB).
-
Hi all , i just got this router and have it running on sky fibre, is there anything i should or could change in settings to improve performance.
Heres my DSL log: http://puu.sh/ef8DD/b272fad304.png
Heres my DSL settings: http://puu.sh/ef8JX/50029d43ab.png
-
I got mine a couple of days ago, replaces a basically non-functional BTHOmeHub5 which would not stop rebooting.
These setting work well, nice and stable.
Here's my setup and log, FWIW:
R.
-
A new beta firmware has just been released today, specifically targetted for those having stability issues on VDSL2. There's a new option called 'ESNP', enhanced sudden noise protection. Full details plus download link are here (http://forums.overclockers.co.uk/showpost.php?p=27828975&postcount=1676) (by the ASUS rep).
-
Hi
Can someone please help?
I've just had BT Infinity installed and I now can't get this router to connect to the internet. It worked fine on my old ADSL line.
I've done a factory reset and when the router starts up the DSL connects and the blue light comes on. So i logon to the router but the internet still shows it as disconnected. I go into the quick internet setup and set the password, the router then tries to auto detect my internet connection but fails, so i chose UK and BT Infinity (NO VLAN ID), the only other BT Infinity options are BT Infinity 2 & BT Infinity Business. I then enter a username, BTHOMEHUB@BTBROADBAND.COM and a password of BT. I then go through the wireless settings screen and click next. The internet still show as disconnected, but the DSL Settings on the Admin page show 39 down 7 up and connected.
What am I doing wrong? Please help its driving me mad!
By the way my BT supplied HH5 works fine on the line so I know the internet is working.
Thanks
-
VLAN 101
-
Hi
Thanks for that its got me up and running. However i'm getting lots of CRC down errors, is there anything else I need to change?
Thanks
-
Ensure that
- bitswapping
- seamless rate adoption (SRA)
- G.Inp
is enabled, both DS & US. Then allow the circuit to "settle" for 24 hours.
-
Hi
Thanks for that its got me up and running. However i'm getting lots of CRC down errors, is there anything else I need to change?
Thanks
You might need to use the ESNP beta firmware, this fixed stability issues (e.g. large spikes of CRC errors, or loss of syncs). See http://forums.overclockers.co.uk/showpost.php?p=27828975&postcount=1676
-
Ok so I logged onto my router this morning and saw there was a new firmware released which included the ESNP setting so I assume this is the official version of the beta some of you have been running, is there anything I need to change or do I just leave it with the default settings?
On another note I spotted my PathMode has change from FastPath to Interleaved, is this good or bad? If its bad is there anyway I can get it back to FastPath? I assume it is bad as my download speed seems to have dropped by about 4mbs.
Thanks
-
Ok so I logged onto my router this morning and saw there was a new firmware released which included the ESNP setting so I assume this is the official version of the beta some of you have been running, is there anything I need to change or do I just leave it with the default settings?
On another note I spotted my PathMode has change from FastPath to Interleaved, is this good or bad? If its bad is there anyway I can get it back to FastPath? I assume it is bad as my download speed seems to have dropped by about 4mbs.
Thanks
You have probably had too many disconnects so DLM will have moved you from fastpath to interleaved in an attempt to stabilise your connection. Your ping rate will also have increased.
Load the new firmware, do a hard reset afterwards and set the whole thing up from scratch. Use the wizard and let it automatically detect your line. Sometimes is doesn't detect the line at the first attempt so try a few times.
If you can get it set up properly and stable then fastpath will probably return in a few weeks.
-
Thanks for the advice. I did as you said and everything seems really stable now, no CRC errors at all currently. Now just need it to go back to FastPath!
Only thing that didn't work was the auto detect, I tried about 20 times but in the end I had to set it manually. As such are there any settings I need to change or should I just leave everything with the defaults? I saw something mentioned about changing the VDSL profile from 30a to 17a, does this need to be done?
Thanks
-
The profile currently is use is 17a.
-
Does it improve anything by using 17a? Mine seems stable enough using 30a so what's the benefit?
Thanks
-
Does it improve anything by using 17a? Mine seems stable enough using 30a so what's the benefit?
Thanks
No benefit, it just means it will accept 30a should it ever become available (if you leave it on 30a), otherwise it will choose 17a automatically if 30a isn't available (which currently it isn't).
If you see stability issues or worrying amounts of CRC errors then change ESNP setting to 'stable'. Other than that it should be fine.
-
There is no profile 30a within the UK. You may have set the device's configuration to that profile but it appears that the device has some inbuilt intelligence and has ignored your directive by selecting the only profile that exists, 17a.
It's late and I can't put my paws on the information to provide you with a link, so I'll just suggest that you look at the Profiles section of the Wikipedia Very-high-bit-rate digital subscriber line 2 (http://en.wikipedia.org/wiki/Very-high-bit-rate_digital_subscriber_line_2) page and Beattie's SIN498 (http://www.btplc.com/sinet/SINs/pdf/498v6p0_C.pdf).
[Edited to add: I see Ixel has already posted but I'll leave the above, as it stands.]
-
I'm looking for some help with my DSL-AC68U and BT Infinity 2. I bought this router to replace an aging RT-N56U and Draytek Vigor 120 in advance of getting Infinity. Infinity 2 was installed in January and my connection has been stable since, until the most recent firmware update last week.
I'm upgraded to 3.0.0.4.378_5007 last week and my connection has switched to Interleaved and the down sync has gone from 80Mbps to 62Mbps. Although we've been having some evening slow down issues, I think they're unrelated to the sync drop.
There are a lot of settings in the DSL Setting page, most of which I know nothing about. Does anyone have a complete list of stable but fast DSL settings for BT Infinity 2 please?
DSL Log
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1252.photobucket.com%2Falbums%2Fhh575%2Fspace--coyote%2FDSL%2520Log_zpsaexaws9m.jpg&hash=d428767c779030362ccda70a45250eeeb535acaa) (http://s1252.photobucket.com/user/space--coyote/media/DSL%20Log_zpsaexaws9m.jpg.html)
DSL Settings
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1252.photobucket.com%2Falbums%2Fhh575%2Fspace--coyote%2FDSL%2520Setting_zpswcja90d8.jpg&hash=6f21ebd830bb050d62902eef0cd7de76e2c914f5) (http://s1252.photobucket.com/user/space--coyote/media/DSL%20Setting_zpswcja90d8.jpg.html)
-
It sounds like you need to set ESNP to 'stable'. This solved the stability problems on VDSL2 for me (which caused DLM to use interleaving), especially when I briefly overrode DLM (and the DSLAM) by setting fastpath on the modem's operating system. DLM is slowly restoring my connection's speed and getting closer to fastpath.
G.INP should also be enabled.
After a few weeks DLM should restore your connection's speed gradually and eventually return you to fastpath.
-
Thanks Ixel.
I've set those. I'll sit back and see where we end up.
-
See http://community.plus.net/forum/index.php/topic,138730
Looks like that firmware version is buggy!
-
Hmm, is working fine here. Might be an isolated incident with a handful of connections.
-
I think the issue is the connection detection. Hopefully tweaking the DSL settings will sort it.
-
***
TLDR; I have the DSL-AC68U and it is not detecting a DSL link.
***
Hi All,
My HH5 recently died and I got a replacement from BT but decided to get a new router anyway and got the DSL-AC68U.
However the router is not detecting that a DSL cable / link is connected.
I have tried multiple different settings including username, WAN mode, DSL mode everything I could find online but I am simply not getting a DSL link.
I have tested the router at a friends house, although the circumstances are different as they're using a different provider and are not on a Fibre Optic connection - they still got a DSL link almost right away.
At this point I'm kind of stuck as to what could be causing this behaviour and would appreciate any advice. Also if anyone else has this same router with BT Infinity 1, I'd like to know how it has been physically set up? I.e.
Wall Socket > Standard Microfilter (Phone line and DSL sockets) > DSL Cable > Router
I ask because the router also comes with a separate microfilter that is 3 DSL sockets, 1 on one side labelled "LINE" and two on the other labelled "PHONE" and "DSL".
Thank you,
-
I had exactly the same question only a couple of weeks ago.
If you look back to page 21 of this thread you will see my question. Take a look and it should be fairly straightforward to set up but basically you sound like you are missing VLAN101 in your config.
Any probs report back here :)
-
Those connection tweaks are looking like they've done the job. Modem reconnected overnight and now I'm back on Fastpath and a down sync of 73999.
Hopefully over the next few days/week It'll be back to max.
Thanks for the help guys.
EDIT: Hmmm, my IP profile has been zapped down to 60.67 Mbps. Hopefully that will start training upwards again too.
-
the ip profile doesnt train, its auto updated on every ppp connect.
-
I had exactly the same question only a couple of weeks ago.
If you look back to page 21 of this thread you will see my question. Take a look and it should be fairly straightforward to set up but basically you sound like you are missing VLAN101 in your config.
Any probs report back here :)
Thanks Carcuscrae, but unfortunately that doesn't seemed to have helped. I am simply not detecting a DSL link no matter what I do. Here are my settings:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs15.postimg.org%2Flnbgw7vaf%2FWAN_Setting.jpg&hash=66532fc581a462afce149995689970980a8f443f) (http://postimg.org/image/lnbgw7vaf/)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs9.postimg.org%2F8ove2m5uz%2FDSL_Setting.jpg&hash=65b417809644949f5adaaa4214ffed75c4b6c1c4) (http://postimg.org/image/8ove2m5uz/)
Getting this error when trying to browse to any page:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs24.postimg.org%2Fhn367qbgh%2FDSL_Error.jpg&hash=1d9da2bf5bdb80774837299f25364624e931d8b4) (http://postimg.org/image/hn367qbgh/)
Does anything look out of place?
-
Have you tried setting annex mode to A/I/J/L/M? I'm pretty sure B doesn't work there. It's actually A which does. Mine's on A/I/J/L/M. It's confused as there's two annexes, I can't recall how it works but ASUS didn't specify that clearly. Someone here I'm sure will remind everyone of what I'm talking about hopefully.
-
The only differences I can see between my settings and yours are ....
1. As Ixel says set Annex to A/I/J/L/M and i'm using auto-sync
2. I have a password of BT
If it still doesn't work after that then i'm not sure what to say. I assume your DSL works fine with the replacement BT HH5?
-
Is anyone experiencing problems with download speeds when using this router ?
I get this on the Ac68U (https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F4359388581.png&hash=15600e8f92b7c28893b3a93235d103ec4e4e1b7f) (http://www.speedtest.net/my-result/4359388581)
and this on the HH5 (https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F4359346536.png&hash=6cb15c36a1716ba83a4c2ef360b0410ca04502a3) (http://www.speedtest.net/my-result/4359346536)
I've tried multiple settings and seem to be syncing fine, just getting slow throughput for some reason...
(https://cdn.pbrd.co/images/sktPk3k.png)
Ideas ?
-
I'd only observe that 697 CRC errors seems a lot for 4-1/2 minutes of connection (though I don't know if that's enough to seriously affect throughput), does the HH5 show CRC errors for comparison?
It would be best to test each to the same server for consistency.
-
Also make sure ESNP is set to Stable on the DSL Settings.
-
I had esnp already on, what i had to to to get it stable was increase the stability adjustment to 10db to keep the crc errors down :
(https://cdn.pbrd.co/images/xf8hwaX.png)
ive been shunted to interleaved though...
-
New firmware out now! ESNP isn't switchable now. It is permanently on apparently.
-
New firmware out now! ESNP isn't switchable now. It is permanently on apparently.
I think that's only if you leave DSL dynamic line adjustment enabled, where the router will automatically adjust certain settings depending on stability.
-
I see, my apologies for incorrect info.
-
Does anyone know the command to show your ES on this device?
-
Whats the WiFi like on this router? looking at it right now seems a good router its future proof thats for sure. With the Wireless clients now using AC Wifi i.e Intels 7260-AC i think i need to upgrade the router now.
Anyone using this on ADSL2/2+ is it stable?
-
WiFi is excellent, ADSL2 rock solid now.
Sent from my Nexus 7 using Tapatalk
-
Nice next question to ask is about QoS is it good for gaming, currently having issues with 1300ms bufferbloat on current TPLink W8980 (W9980 Firmwared) router.
Been looking at PC World and they are currently out of stock only CCLOnline has them instock like
-
Over on Overclockers thread, There appears to be people still having issues with it on ADSL and VDSL. The latest firmware has QoS fixes in it I believe. Not sure how good it is though, I've never used it.
-
Nice next question to ask is about QoS is it good for gaming, currently having issues with 1300ms bufferbloat on current TPLink W8980 (W9980 Firmwared) router.
Been looking at PC World and they are currently out of stock only CCLOnline has them instock like
eBuyer has it in stock at £129.
Can't comment on QoS, never use it.
-
Thanks for your replies
-
Nice next question to ask is about QoS is it good for gaming, currently having issues with 1300ms bufferbloat on current TPLink W8980 (W9980 Firmwared) router.
Been looking at PC World and they are currently out of stock only CCLOnline has them instock like
it should do wonders for gaming.
The asusWRT QoS only helps on upload bloat tho, but luckily thats the main cause of bufferbloat Bufferbloat on the downstream is much less severe.
Some additional comments.
When I first tested asuswrt QoS it worked fine on upstream, but however all my latter testing in the past 2 weeks it wasnt reducing bufferbloat and I pinned it down to excessive sfq queueing.
Now I am on sky which does not use the horrible pppoe, the issue is gone by magic. However I am still baffled as it did initially work fine for me on pppoe so try it and then run a bufferbloat tester like dslreports speedtester.
I have now made a shaper bash script, utilises tools already on asuswrt but using manual configuration I did based on documentation I read and I had upstream and downstream shaping working on pppoe fine (also is fine on sky). If needed I Can share this script. Bear in mind tho when removing bloat on the downstream your connection will become much more "polite", so in situations such as isp congestion you will likely see much lower performance, and the line wont ramp up to full speed as aggressively.
Also I have been working closely with the developer of this fork of asuswrt, and he has been working on the built in downstream shaping functions.
-
Thanks for the reply mate. So its sounding like over all its a great router. Will have to see if PCWorld will stock it, Hate buying online lol even buying games for me is a trip to the brick and mortar store. If not then i will order online.
-
edited reply, check attachment.
that was from some testing about 3 weeks ago when using netflix.
-
be aware so you dont buy the wrong thing, custom firmwares dont work on the dsl models.
for stability and compatability reasons I would use a broadcom modem anyway.
Pair a hg612 or 8800nl (in bridge mode) with a rt-ac68u and you should be happy.
-
I agree with Chrysalis on this one. The modem in the DSL-AC68U is a bit hit or miss. It looks like it performs well on short lines but for many it has been a bit of a headache.
-
Right i now own and am running a DSL AC68U, does anyone know if any of the monitoring software works on this router? If so which one. Thanks in advance.
-
Apparently RouterStats can be configured to work with it:
http://forums.whirlpool.net.au/archive/2353509
It also looks like the most recent firmware for it may have broken that facility:
http://forums.overclockers.co.uk/showthread.php?t=18606945&page=84
-
Thanks for the reply was hoping to be able to use on that would upload the data to mdw like.
Current stats for the line (Will do a reboot in the morning though tomorrow).
DSL Firmware Version 1.0.2.7
DSL Driver Version FwVer:5.5.1.129_A_A60901 HwVer:T14.F7_0.2
DSL Link Status: up
DSL Uptime: 0 days 0 hours 14 minute(s) 23 seconds
DSL modulation: ITU G.992.5(ADSL2PLUS)
ANNEX Mode: ANNEX A
SNR Down: 6.0 dB
SNR Up: 7.0 dB
Line Attenuation Down: 52.9 dB
Line Attenuation Up: 31.4 dB
Path Mode: FastPath
Data Rate Down: 7991 kbps
Data Rate Up: 854 kbps
MAX Rate Down: 8960
MAX Rate Up: 932
POWER Down: 20.3 dbm
POWER Up: 12.3 dbm
CRC Down: 7
CRC Up: 0
Its performing better then the TPlink thats for sure. On the latest firmware though.
-
I have one in the cupboard I've been considering trying out again recently, as Asus seem to have made many attempts at improving the xDSL modem's firmware.
However, as it's not a Broadcom chipset I don't believe HG612 stats application can retrieve the details, hence no upload to MDWS :(
This is my main reason for not bringing it back out to play.
Ran it as a router only with a HG612 and it was great. But prefer the all in one VDSL modem for neatness :/
-
However, as it's not a Broadcom chipset I don't believe HG612 stats application can retrieve the details, hence no upload to MDWS :(
Thought they had the Broadcom chip in them.
-
The Asus DSL-AC68U has a mediatek modem. Rest of gubbings is broadcom.
Real shame they didn't make it 100% Broadcom...
http://forums.whirlpool.net.au/archive/2415716
-
I believe that was a bit of cross communication there. Jizzerman was stating that HG612 stats (program) will not work with the asus as it is not a broadcom unit. The HG612 is though.
-
So after a Reboot 23 hours ago here are my following stats.
DSL Firmware Version 1.0.2.7
DSL Driver Version FwVer:5.5.1.129_A_A60901 HwVer:T14.F7_0.2
DSL Link Status: up
DSL Uptime : 0 days 23 hours 45 minute(s) 50 seconds
DSL modulation : ITU G.992.5(ADSL2PLUS)
ANNEX Mode : ANNEX A
SNR Down: 4.4 dB (Was at 8.0db set by myself but in evening it snr drops big time even down to 2. something)
SNR Up: 8.0 dB
Line Attenuation Down : 52.9 dB
Line Attenuation Up : 31.4 dB
Path Mode : FastPath
Data Rate Down : 7121 kbps
Data Rate Up : 836 kbps
MAX Rate Down : 8148
MAX Rate Up : 912
POWER Down : 20.3 dbm
POWER Up : 12.3 dbm
CRC Down : 697
CRC Up : 66
Setting: DSL line settings up with Stability Adjustment (ADSL) set to -2db and Rx AGC GAIN Adjustment (ADSL) High Performance.
So its a good router just for the abillity to change the SNR up and Down. Even the CRC's are lower then normal.
All i can say is I am loving this router!!
-
Good, it gets far more criticism than it deserves.
Sent from my Nexus 7 using Tapatalk
-
That seems to be true but that might be down to the VDSL side of things due to the DSL firmware. I can't fault this product myself infact i deem it to be value for money considering you have a load of options to control how the connection runs in terms of High Performance or Stability profiles, coupled with SNR down and up settings its a worthy product in my eyes so far.
Even the QoS is better. Mr Youtube playing catch up and me playing online is no longer a rubberbanding nightmare. Even higher WiFi performance is great.
The only downside so far is the fact that there isn't a way to use DSL Stats software yet since the last updated firmware.
-
I love this router too, but have a strange thing going on.
Since the recent firmware update (6553) when I log into my UI all I can see when I click the Wireless tab is the 5GHz wifi, the 2.4GHz is missing. I posted on the ASUS forums and a fellow user (non-ASUS staff) suggested updating with a beta firmware, which I am reluctant to do.
The wifi is fine but I had adjusted the channels prior to the firmware update.
Any suggestions?
Rick.
-
Can you post a screen capture to show what you mean?
Sent from my Nexus 7 using Tapatalk
-
Can you post a screen capture to show what you mean?
Sent from my Nexus 7 using Tapatalk
Sure - as you can see I can only select the 5GHz in this screenshot.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs7.postimg.org%2Fkgq446w2z%2FScreen_Shot_2015_07_20_at_12_08_05.png&hash=7146a29bbbba5dfeb87a4fa5a56ff0022dd022ab)
-
Did you factory reset the device after the firmware upgrade as that seems to be required now adays and a new config being made as well.
-
I just rebooted the router manually (turned it off then on, on the actual router) - this thread on the ASUS forum explains my problem a bit better than how I described it https://vip.asus.com/forum/view.aspx?id=20150713171222452&board_id=11&model=DSL-AC68U&page=1&SLanguage=en-us (https://vip.asus.com/forum/view.aspx?id=20150713171222452&board_id=11&model=DSL-AC68U&page=1&SLanguage=en-us)
-
What he said.
If you don't do a full reset after a firmware upgrade you can get all sorts of strange glitches.
Sent from my Nexus 7 using Tapatalk
-
Sorry if I am being thick (am so not technically minded) - can you walk me through a reset? And will this lose all my current settings I have applied to the router?
-
BTW a reset is not turning it off and on again. You need to press the reset button for 15 seconds until it completely clears your previous configuration.
Sent from my Nexus 7 using Tapatalk
-
Head to the Administration tab then click Restore/Save/Upload setting then hit the restore button. That will factory reset the device. Then re configure the router again.
-
I have saved all my settings when I was on the previous firmware - can I restore them (those settings) from the file made or would that screw things up?
-
Its best to start again but you can try and use your old settings and if it glitches out factory reset the router again and manually set it up again.
-
OK - I will give it a go!
-
Goodluck
-
The only real issue I have with this device now is the lower sync rate of around 6Mb. If I change a few settings here or there I can get the majority of it back minus 1-2Mb without causing too many errors. It has remained stable which is the main thing and has been up for 9 days now.
-
If and when G.INP is rolled out to ECI DSLAM's, I think a majority of my issues will disappear - as I imagine the case will be with most others still pending on G.INP rollout and using this device.
On the bright side however, I managed to get from 67M to 74M this morning as DLM has given me back some of my max sync rate. Whether it's linked to me having a very high SNRM target at the moment (was 18dB) or whether it's just coincidence that it finally gave me back some speed - I can't be sure at the moment. Just seems coincidental that I set a high SNRM target for all of yesterday and then this morning it raises my max downstream sync rate, as if it believes I have plenty of spare capacity and so my line can handle it perhaps?
I've been on fastpath for weeks now too.
-
Just a heads up to all.
New ASUS DSL AC68U Firmware 3.0.0.4.378_6986 has been released as mine has just updated.
Changelog
ASUS DSL-AC68U Firmware version 3.0.0.4.378_6986 (This product supports both Annex A and Annex B)
- Release Note -
New features:
- Added SSH Daemon support(Advanced Settings > Administration > System).
- OpenVPN Client now can support up to 5 profiles.
DSL:
- DSL firmware updated - v1.0.2.9.
- DSL driver updated - v5.5.1.131.
- Fixed possible ADSL/ADSL2/2+ SNRM will be constant in certain condition issue, which leads to interruption.
- Fixed possible synced with lower upstream data rate issue with certain DSLAM.
- Separate Path Mode into downstream/ upstream(DSL Log).
- Fixed possible DSL Uptime display issue.
- Fixed typo in DSL Setting. Should be Dynamic Line Adjustment (DLA), not (DSL).
- VDSL WAN (PTM) QIS manual setting list updated.
Add Iceland ISP, Siminn Telecom.
Add Thailand ISP, True Online (PPPoE).
Update Thailand ISP, True Online (Bridge).
Bug fixes:
- Fixed WiFi scheduler related issues.
- Fixed Parental Control > Time Scheduling related issues.
- Fixed possible DLNA failed to scan whole USB disk contents issue.
- Fixed Adaptive QoS UI issues.
- Fixed miniupnpd related issues.
- Fixed IPv6 related issues.
- Fixed Bandwidth Monitor related issue.
- Fixed the issue in OpenVPN server -> content modification of keys & certification.
3G/LTE dongle related fixes:
- Support more CDMA2000 dongles.
Modifications:
- Fine tune Feedback feature.
- Openvpn: generate 1024 bits DH parameters instead, takes longer time for openvpn server. Weak keys will be vulnerable to a man-in-the-middle attack known as Logjam, which could result in an attacker decrypting the VPN connection.
- AiProtection: Update signature into 1.054.
- Add more SMTP servers support for alert mail.
MD5: 66bd4a0829d18224c09232167a37ddcb
-
Hi
I've just switched from BT Infinity to Sky Fibre and set this router up with my new Sky connection. However, after finding it quite stable with BT, i'm getting lots of CRC errors on Sky. Are there any settings that are different from BT to get this more stable on Sky?
I should add i've only had Sky connected today so could this be why?
Thanks
-
Yes I think they are different in terms of setup. Best bet could be to reset the router back to factory and start again just to make sure.
Sent from my MotoG3 using Tapatalk
-
Can anyone advise what settings to use though?
Its only been running for 2 hours on Sky Fibre and already has 16025 CRC down errors!! Only had about 300 in nearly a month on BT.
Thanks
-
https://www.google.co.uk/url?sa=t&source=web&rct=j&url=http://www.skyuser.co.uk/forum/sky-broadband-fibre-help/56812-heres-how-asus-dsl-ac68u-working-sky-fibre.html&ved=0CCgQFjABahUKEwjJuMvNjbHHAhWIF9sKHaeLCUo&usg=AFQjCNEtKewOYa3U4zXS1ajx55fjLjTPZQ&sig2=UmmNp8WErxWyLZ_LFtnHDw
Sent from my MotoG3 using Tapatalk
-
Its only been running for 2 hours on Sky Fibre and already has 16025 CRC down errors!! Only had about 300 in nearly a month on BT.
That is going to get DLM making changes to the line ASAP...
-
Could you have been interleaved on BT but since switching to Sky, A possible line reset so running an open profile at present?
-
Could you have been interleaved on BT but since switching to Sky, A possible line reset so running an open profile at present?
Yes my line was interleaved on BT and Sky is now showing as Fastpath. Is this what you mean and if so what does it mean if I have an open profile?
-
When you was on interleave it was correcting the errors hence a lower count, Fast path there I no error correction if it's like Adam hence the higher error rate. Open profile I think might meant as fast as the line can go. With the amount of errors your getting DLM will kick in and put you on interleave more then likely S the line should in theory be stable again.
-
I would just leave it be for 24-48 hours and see if it decides to stabilise. Don't try rebooting to make it stable, It should sort itself out although may apply interleaving.
The higher interleaving level applied the higher FEC's you will see but lower CRC's in theory.
-
a router wont affect CRC errors, a modem might tho.
-
Hi
I've just posted this over on the SkyUser forums as someone had the same issue there. Has anyone seen this before and have any advice to resolve it please?
Re: Here's how:- Asus DSL-ac68u working with Sky fibre
Quote Originally Posted by ruddyrum View Post
My Asus DSL AC68U has been working fine for months after initially spending a while setting it up... Woke up this morning and now my DSL connection is disconnected.
Updated to latest firmware, ran initial DSL setup wizard and entered the MAC address. DSL log shows that connection is up, but I ann not connected to the Internet. Further analysis of my log shows that I'm not getting an IP from sky??? Any ideas?
Hi
I've just had exactly the same problems as ruddyrum. All was working fine then this morning I wake up no internet connection. DSL line is showing as up but internet connection is down with a message in the log of 'ISP's DHCP did not function properly'.
So i've plug the Sky router back in and all works perfectly so there is nothing wrong with the broadband on the line. Nothing has changed on the DSL-AC68U but for some reason now it can't get an IP from Sky's DHCP.
What I have tried is to static ip the DSL-AC68U using the IP details the SKY router picks up when connecting. This gets the DSL-AC68U showing an internet connection but when you try to browse a page it gets a DNS errror.
Can anyone help please, or RuddyRum if you can tell me if/how you solved your issue, that would be great as its frustrating to say the least.
Thanks
-
It sounds like something Sky have done.
The only time I've had that situation with BT Infinity i.e. no IP, was due to a BT fault in the area.
Though in your case you say the Sky router/modem is picking up the IP address fine? That means either 1. your device is broke, or 2. Sky have changed something in the way they give out IP's.
I wonder if anyone else on the network who use the ASUS DSL-AC68U device as had the same problems. I wonder if the guy who replied to you has your device as well.
So far in the fibre world this seems to be the most annoying aspect. ISP's trying to lock down their network, and generally being either secretative, or dumb when it comes to their staff.
I hope you get this problem sorted. I know how distressing it can be to lose an Internet connection that as always been there.
-
Have you cloned the Mac from the SkyRouter and placed it onto the ASUS DSL-AC68U in the WAN Section?
-
I hadn't previously when it was working. I tried that this morning when it stopped but it didn't seem to make any difference, should I have left it longer?
Thanks
-
my rt-ac68u is still working fine on sky and I didnt clone the mac. Regardless the post is concerning.
I wonder if its related to changes they making in preperation for ipv6.
--edit-- I wonder if been on a static ip saved me? as sky manually configure static ip's meaning changes to their automatic configuration wouldnt take affect.
-
Remember his is using the DSL modem portion whereas you are using the RT one.
I remember seeing this full reboot procedure. A total copy paste from another forum but worth a try.
1)With the Asus switched on, press and hold the reset button for 30 seconds.
2)Without releasing the reset button, unplug the Asus (pull the power cable from the back) and carry on holding reset for another 30 seconds
3)Plug the Asus back in STILL holding the reset button a final 30 seconds
4)Release the reset button.
Its best if you do the above steps BEFORE AND AFTER any upgrading if you have any issues with firmwares.
If the Asus enters recovery mode then press the reset button again with it powered on then release the reset button. Power the device off and back on.
Following the above is not normally needed but that will ensure ALL prior settings are erased and anything in the Asus RAM or any modem for that matter is completely cleared.
-
found your post, the other guy was not recently, so both occurrences were not today, so I think you have a local issue of some sort.
I would expect both the dsl and RT model to use similar code for authentication.
However with that said merlin improved the dhcp authentication so it works well with sky and the dsl models dont have merlin firmware (I use a fork of merlin's firmware), so I think thats probably the reason.
-
I've had to use the Sky router for the dsl and use the DSL-AC68U for all the other features in the end. No idea why the 68U can no longer get an IP from Sky as their router picks up immediately?
-
sell the dsl and get the rt instead, install merlin on it and it be fine, use a hg612 as a modem.
The sky router doesnt support bridge mode so your setup is like using double nat which is messy.
-
Just be aware the latest firmware for the AC and DSL versions of this router the wireless has been reduced from 200mW to 80mW output power. There is no workaround for the DSL version, but the AC version can be configured via command line or by installing third party firmware by hggomes.
-
Just be aware the latest firmware for the AC and DSL versions of this router the wireless has been reduced from 200mW to 80mW output power. There is no workaround for the DSL version, but the AC version can be configured via command line or by installing third party firmware by hggomes.
The hggomes firmware is not available and there is some 'doubt' about it from what I can read.
I would use the RMerlin Original which can be found here http://www.snbforums.com/forums/asuswrt-merlin.42/ (http://www.snbforums.com/forums/asuswrt-merlin.42/) Full Sources are available to examine if so minded.
The hggomes firmware was a fork of the RMerlin Original, which did not have the Source available ...... which led to it being not available.
You can read all the 'static' about this on the same site.
Generally, due diligence is in order to decide if the Software/firmware you are installing is trustworthy.
Just because it is popular or appears to give you what you want does not obviate the need to be as sure as you can that you are not compromising your security.
This is not a snipe at hggomes or RMerlin but an attempt to raise general awareness of the potential risks.
I do actually use the RMerlin Firmware but still considered the risks first.
I was satisfied but you should NOT take my word for it.
-
I thought the RT AC68U was Different to the DSL AC68U in both Hardware and CFE?
-
I thought the RT AC68U was Different to the DSL AC68U in both Hardware and CFE?
Correct, If you look at what the RMerlin firmware supports it does not list any DSL models as they are different.
The comment was about 3rd party firmware for AC versions, which I replied to.
The supported versions are: (From Website)
Official support:
RT-N66U
RT-AC66U
RT-AC56U
RT-AC68U/RT-AC68P
RT-AC87U
RT-AC3200
-
I thought the RT AC68U was Different to the DSL AC68U in both Hardware and CFE?
Apologies. Mean between the RT and DSL models.
-
if you want a firmware that is maintained (For security) and doesnt have the wifi nerf asus added, then is a fork of merlin's firmware here.
http://www.snbforums.com/threads/fork-update-for-374-43-available-v13e1.18914/
Its source code is there for everyone and is many users including myself, in my opinion that is a trustworthy version. Me and merlin have both had input into the fork. (the not yet released beta has some pretty sweet changes as well) :)
Note the fork uses openssl 1.0.2 whilst the official asus firmware is still using a EOL openssl branch.
-
@Chrysalis
Thanks for that ...... Interesting. ;D
I haven't updated the Original RMerlin s/w as I did not want to upset the DLM 'Gods' & it had been working and stable.
Might be useful to get the wi-fi working to UK regs NOT US. :D :D
I will consult the runes and 'chicken gizzards' to see when I can dare to do an update of the Asus Router ;D
-
aardvark this is not available for the dsl model, you need an rt model.
Also an advantage of speerate modem is you can flash the router to your content with no risk on DLM :)
This is why I prefer seperate devices.
-
aardvark this is not available for the dsl model, you need an rt model.
Also an advantage of speerate modem is you can flash the router to your content with no risk on DLM :)
This is why I prefer seperate devices.
Sorry, I have a router that supports the firmware. (rt-ac56u)
It is just everytime I do an update something happens to force a restart of the Zyxel modem :)
Including power failures, hangs, pulling the wrong cable/plug :blush: etc
Just being ultra careful :D
-
Can the DSL-AC68U be configured to use a HH5 to provide an internet connection?
Want to do some side by side WiFi speed testing.
HH5 currently connected to Infinity, within first 10 days so don't want to start connecting and disconnecting it.
Have been able to set up Asus RT kit to do this in the past but I can't seem to find a way to do it with this DSL router.
Tried just about every setting I can find but I'm either being thick or just missing something obvious.
A walk through would be useful (or a link to one). BTW Not being lazy, I have searched this and many other forums, not found anything.
Thanks in advance.
-
Worked it out.
Forgot that the Asus and the HH5 need to be on different subnets.
So it was missing something obvious (rather than me being thick).
-
So how did you do it as i am just about to try something the same just a TG582N and my ASUS DSL-AC68U. Thanks in advance
-
OK bear in mind I'm not exactly a technical networking expert, I've just got it to work and there may be much better ways of achieving the same. Once the line has settled I'm going to mothball the HH5 as an emergency back up.
The HH5 is set up with the IP range 192.168.2.xxx, the HH5 itself is assigned 192.168.2.254 apart from that it's configured out of the box from BT. So for this example you need to make sure your modem IP is set the same.
The DSL-AC68U is connected to the HH5 using a standard LAN cable plugged into a normal gigabit ethernet port on the HH5 (not the WAN port) that is then plugged into LAN Port 1 on the Asus.
Config for DSL-AC68U:
LAN > LANIP: IP Address: 192.168.1.1, Subnet Mask: 255.255.255.0
LAN > DHCP Server: Enable the DHCP Server: Yes, Domain Name: Blank (as in nothing) IP Pool Starting Address: 192.168.1.2, IP Pool Ending Address: 192.168.1.254, Lease time: 86400, Default Gateway: Blank, DNS Server: 192.168.2.254, WINS Server: Blank.
WAN> DUAL WAN: Enable Dual WAN: ON, Primary WAN: Ethernet WAN LAN Port 1 (important it's the same port that you plugged the cable into on the Asus), rest of settings not important.
WAN> Internet Connection: WAN Type: Ethernet WAN, WAN Connection Type: Static IP, Enable WAN: Yes, Enable NAT: Yes, Enable UPnP: Yes, WAN IP Setting: IP Address: 192.168.2.253, Subnet Mask: 255.255.255.0, Default Gateway: 192.168.2.254 (i.e. the IP of the HH5), WAN DNS Setting: DNS Server 1: 192.168.2.254, DNS Server 2: Blank, Account Settings: Authentication: None, Special Requirement from ISP: Host Name: Blank, MAC Address: Blank, Extend the TTL Value: No
Obviously you need to apply the settings after each screen, once it's all done go to Network Map and the Primary WAN should say connected. You can test the Internet Connectivity on the router itself using the Network Tools menu. Hopefully you can now connect a client to the Asus and get an internet connection.
Now need to duck and wait for all the comments about not doing it like that etc.
-
No, you don't want to do it like that. Just change the operation mode on the ASUS to access point mode.
-
No, you don't want to do it like that. Just change the operation mode on the ASUS to access point mode.
Would have gladly done that if I could find a setting to allow that to happen.
-
As well as a link on the top of every page on the web GUI, you can find it in Advanced Settings/Administration/Operation mode
-
As well as a link on the top of every page on the web GUI, you can find it in Advanced Settings/Administration/Operation mode
This is the DSL-AC68U not the RT-AC68U
Do you really think I would have missed that?
-
Oops, my bad :-[
Sorry ;)
-
Thanks bud now i have the TG582N as modem with the DSL-AC68U as Access point for now.
-
Oops, my bad :-[
Sorry ;)
No worries, I was expecting someone to say something, so you didn't disappoint. ;-)
-
Thanks bud now i have the TG582N as modem with the DSL-AC68U as Access point for now.
Good, glad it worked. :-)
-
What are the recommended stable settings for BT Inifinity?
Judging by the lack of recent posts I assume that everyone has managed to get the DSL-AC68U running well.
Would be good to know the settings you are currently using.
Hoping to get this set up in one go rather then experimenting and triggering a switch from Fastpath or even worse a slower sync speed.
Thanks.
-
Not me. The latest unofficial beta firmware didn't help one bit, if anything it seems worse. Racked up over 11,000 CRC errors in two big spikes within 15 minutes of uptime. Draytek Vigor 2860Vac lucky to get 1 ES or a few CRC errors within 15 minutes of uptime.
-
Not me. The latest unofficial beta firmware didn't help one bit, if anything it seems worse. Racked up over 11,000 CRC errors in two big spikes within 15 minutes of uptime. Draytek Vigor 2860Vac lucky to get 1 ES or a few CRC errors within 15 minutes of uptime.
Could you share your settings so that I can at least rule them out?
BTW how is the wireless performance of the Draytek?
Thanks
-
Not me. The latest unofficial beta firmware didn't help one bit, if anything it seems worse. Racked up over 11,000 CRC errors in two big spikes within 15 minutes of uptime. Draytek Vigor 2860Vac lucky to get 1 ES or a few CRC errors within 15 minutes of uptime.
Could you share your settings so that I can at least rule them out?
BTW how is the wireless performance of the Draytek?
Thanks
I've tried a variety of settings without much luck. I always have ESNP set to 'stable' as it's supposed to help against this. The Draytek's wireless performance is excellent, infact on the ASUS routers I've had an issue with one laptop in the house periodically losing connection (most likely the wifi adapter doesn't work right somehow with the wireless chipset in the ASUS routers I have (or perhaps the firmware that operates the wireless chipset). On the Draytek I've never had this specific laptop drop out once.
There's only one thing I've had with my Draytek, which I've worked around:
- UPnP being enabled seems to periodically crash it, perhaps this is related to me using a routed IP block where most people wouldn't, the current solution is for me to not use UPnP at all though this unfortunately messes up GTA Online when I play a heist and if there's a quick restart it times out (I could probably use an IP in the routed block and not need UPnP however - something I'm going to try soon)
-
Thanks.
My side by side wireless performance tests comparing the BT HH5b with the Asus have been eye opening. The wireless performance of the HH5 is utterly awful. I'm very keen to move over to the Asus as soon as possible but not at the cost of a stable connection.
-
There will be a lack of new posts due to people abandoning the device. Several including myself tried for months to get a stable connection but just couldn't. The latest firmware I tried was stable enough but generated a lot of errors. That along with constantly wondering when it was going to drop out didn't leave much confidence in the unit so it was removed. There are plenty better devices on the market now.
-
There will be a lack of new posts due to people abandoning the device. Several including myself tried for months to get a stable connection but just couldn't. The latest firmware I tried was stable enough but generated a lot of errors. That along with constantly wondering when it was going to drop out didn't leave much confidence in the unit so it was removed. There are plenty better devices on the market now.
Interesting, so which of the many devices have you gone with?
-
For a while I reverted to the Huawei modem and used the DSL-AC68U as a router only. I then tried the Netgear D6400 which was very stable only lacking in wireless performance. I have since bought a Netgear D7000 which has been brilliant. I think I have about a months uptime since my latest firmware update which is giving about 10 times LESS errors than the DSL-AC68U had over 10 days.
I'm waiting for the new Billion to come out now and may get that once prices drop a little.
-
There is a new Beta Firmware update for the ASUS DSL-AC68U.
Changes are:
Updated GUI on DSL Log and New QOS Settings
New xDSL Firmware with profiles 8 and 12 for vdsl
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1167.photobucket.com%2Falbums%2Fq631%2Fbabis3g%2Fnew%2520dsl%2520stats%2520page_zps8twix55x.png&hash=1e3a3e1766be0cf18839870ad97c3f36bb255e32)
https://www.asuswebstorage.com/navigate/s/251B9CFB9FC041498B96CCA9FD918BDD4
Thanks to babis3g for posting it on the ASUS Forums.
-
There is a new Beta Firmware update for the ASUS DSL-AC68U.
Changes are:
Updated GUI on DSL Log and New QOS Settings
New xDSL Firmware with profiles 8 and 12 for vdsl
https://www.asuswebstorage.com/navigate/s/251B9CFB9FC041498B96CCA9FD918BDD4
Thanks to babis3g for posting it on the ASUS Forums.
I tried this today. While it's nice to see the UI updated, it still lacks important details such as ES and SES. Unfortunately it's still as unstable as previous firmware versions too (16,000+ downstream CRC errors within 7 hours overnight).
-
After reading quite a few positives and negatives about dsl-ac68u I decided to give it a go, as i needed a modem/router that has stronger wifi and better performance than HH5 when streaming video from a usb hdd.
Initially i bought the DSL-N66u but i had to send it back.
I'm on BT infinity 38/10 and with HH5 i had a very stable connection with the HH5 with SNR of about 22 down and 20 up
When i connected the ac68u i had the same sync speeds however the ping has gone from 10ms to 27ms because i was on interleaved. As soon as i enabled g.inp the mode went to fastpath for both up and down and the ping has gone down to 8-9ms.
The connection has been stable for at least 8-9 days now with about 450 crc errors up and 1 down.
On DSL-N66u even when i had g.inp activated it would still go in interleaved mode and wireless coverage was not better than the HH5.
The only issue i see is that with the HH5 i would get around 37mbs on speed tests while with the ac68u i will get around 35-36mbs. Both are syncing at the same speed so not so sure what is the difference as it is tested with lan and same desktop.
overall though happy with the dsl stability, wireless range and usb hdd as media server.
-
Version 3.0.0.4.378_9166
ASUS DSL-AC68U Firmware version 3.0.0.4.378_9166 (This product supports both Annex A and Annex B)
New features:
- Bandwidth Limiter in Adaptive QoS > QoS. Allow administrator to easily limit specific client's upload/ download bandwidth.
- Now Quick Internet Setup supports ADSL WAN (ATM) VLAN ID setup, specifically for Germany/ Thailand ISP.
- Quick Internet Setup now supports IPTV setting, specifically for UK/ Turkey/ Russia ISP.
- Independent MAC filter for main wireless network and guest network. Administrator can set white list for main wireless network to only allow trusted client connect to main wireless network and share network to guests with guest network.
- Modify the network map client status. When click the client icon, administrator can bind IP, change host name, change icon, block Internet access or set time scheduling.
- Time scheduling, Web & App filter, Wireless MAC filter client drop down menu now can show offline devices.
- Add 3G/4G USB modem APN auto detection feature. In most cases, firmware can automatically find the ISP profile and establish link when 3G/4G dongle inserted to router.
- Add Android phone in USB modem/ USB Tethering > Select USB device.
- Add Smart Sync Dropbox, ftp, samba client support.
- Show current WiFi control channel while value is Auto.
- [AiCloud] Show image EXIF info on image player.
- [AiCloud] Auto rotate image on image player.
- [AiCloud] Files can be moved and copied.
- [AiCloud] Images can be uploaded to Picasa or Twitter.
- [AiCloud] Share link can be posted on Twitter, Plurk, Weibo and QQ in AiCloud.
- [AiCloud] Add import certification.
DSL:
- DSL firmware updated - v1.0.3.2.
- DSL driver updated - v5.5.1.135.
- Fixed ADSL2/2+ stability issue with certain DSLAM.
- Fixed G.dmt Bitswap abnormal issue with certain DSLAM.
- Fixed possible ADSL2/2+ Bitswap gets triggered incorrectly/ frequently issue.
- Fixed possible Bitswap bug caused SNRM to drop gradually and leads to interruption.
- Now when VDSL Annex type is Region B(Europe) but US0 type is Annex A, DSL Log would display as Annex A instead of Annex B(for this case, Annex Mode should be configured as Annex A/I/J/L/M or Annex A).
- [DSL Log] Add TCM(Trellis Coded Modulation), downstream and upstream interleave depth information.
- [DSL Log] Show G.inp upstream/downstream info.
- [DSL Log] Fine tune dsl log page.
- [DSL Log] Show VDSL current profile in DSL Log and feedback form.
- [DSL Setting] Enable G.Vector(G.993.5) by default.
- [DSL Setting] Add 12a multi mode and 8a multi mode for VDSL.
- [DSL Setting] Remove Rx AGC Gain Adjustment(ADSL/ VDSL) DLA auto configuration.
- [QIS] QIS auto detection list updated.
- ADSL WAN (ATM) QIS manual setting list updated, includes more settings for Argentina, Armenia, Australia, Azerbaijan, Belgium, Brazil, Brunei Darussal, Cambodia, Canada, Colombia, Dominican Republic, Colombia, Egypt, France, Germany, Greece, Hungary, Iceland, India, Indonesia, Iran, Ireland, Italy, Kazakhstan, Luxembourg, Malaysia, Mexico, Netherlands, New Zealand, Norway, Palestinian Authority, Peru, Poland, Portugal, Saudi Arabia, Singapore, Spain, Sweden, Thailand, Tunisia, United Kingdom, Ukraine, USA, Venezuela, Vietnam.
- VDSL WAN (PTM) QIS manual setting list updated, includes more settings for Argentina, Brazil, Canada, Finland, France, Germany, Poland, Qatar, Spain, United Kingdom, Vietnam.
Security fixes:
- Update OpenSSL library to 1.0.2d.
- Update Trend Micro security engine.
- Fixed CVE-2015-6949 buffer overflow issue.
- Fixed Web server Accept-Language buffer overflow issue.
- Fixed Web server URL handler buffer overflow issue.
- Enhanced router login password and wireless password(WPA2) strength check method against brute-force attack.
- Prevent administrator to set too easy to guess login and wireless password in order to avoid brute-force attack.
Modifications:
- [AiCloud] Use https url while playing music in AiCloud.
- [AiCloud] Change to use html5 player on Firefox instead of flash player.
- Adjust Adaptive QoS UI, now easier to set top priority for gaming, media streaming or web surfing.
- Enhance animated effect for progress bar of CPU/RAM and Bandwidth Monitor.
- Extend the OpenVPN key & certification field length to 4096 bits key.
- Add 3G/4G log option in Feedback.
- Media Server, minidlna updated.
3G/LTE:
- Support Huawei E3372, E303u-1, E3531s-6 dongles.
Bug fixes:
- Fixed VDAL WAN (PTM) Automatic IP connection type with no VLAN ID setting, WiFi both bands low throughput issue. Workaround solution adopted, configure with VLAN ID 0(reset to default a must).
- Fixed cloud sync issues between router and ASUS webstorage.
- Fixed share link related issue to Android devices.
- Fixed browser compatibility issues.
- Fixed GUI related issues.
- Fixed parental control-> time scheduling related issue.
- Fixed adaptive QoS device priority label dragging issue.
- Fixed UI issue when selected French.
- Fixed OpenVPN connection status display error.
- Fixed OpenVPN server account setting issue.
- Fixed the settings of Disk Health Scanner cannot be saved.
- Fixed traffic monitor data error.
-
Version 3.0.0.4.378_9168
Description ASUS DSL-AC68U Firmware version 3.0.0.4.378_9168 (This product supports both Annex A and Annex B)
Release Note
-Remove mDNSNetMonitor related debug logs.
-Fixed 802.1Q enabled with VLAN ID 0 setting cannot take effect issue, 802.1Q setting reverted back to disabled
This version primarily fixes a 802.1Q related issue that previously needed a manual config change on 9166
-
It's a pity this device is unusable still for most VDSL2 connections without interleaving or G.INP (or a rather high SNRM) on the downstream.
-
Does this modem/router only play nice if you have a short line?
-
Does this modem/router only play nice if you have a short line?
As VDSL lines all tend to be short due to the nature of the solution I assume you are talking about ADSL lines.
The main criticism of this device is the number of CRC errors it registers. In the real world I've never found that be an issue which impacted line speed or stability.
In the early days of it's release this device got a bad reputation and despite Asus working hard to fix those problems it's a reputation that has stuck.
I've used this device for over a year, mainly on ADSL and now on VDSL. It does not deserve its reputation.
Unlike many other manufacturers Asus continue to improve and bug fix the firmware, it is a much better device than it was a year ago.
It's not perfect, it still has it's quirks but it also has it's major plus points, WiFi performance being being top of that list. It has a lot of modem options to fine tune/tweak your connection. If you are looking to maximise throughput on a long line they may be useful.
People will tell you that there are better devices out there, yet when you look at those devices you will see as much moaning about their problems as there was about this one.
It's almost impossible to say whether this device will work well with your line. I can only suggest that if you decide to buy one you get it from somewhere that takes returns. Try it out, give it a chance.
-
Yea I bought a Billion 8800nl (for VDSL) from amazon made sure I could return it just to test out a broadcom chipset on my line then if all goes well I would probably get a Netgear D7000 (Now the same price as a R7000 on amazon). I would have stayed away from the Asus DSL 68u but I kept checking the firmware for it and noticed they keeps fixing lots of bugs and adding things which is nice to know. I got high hopes for the D7000 if its anything like the R7000, I remember that used to have firmware buggy as hell and now its probably the best AC1900 router around, i think it had a slight edge over the RT 68U
-
Old topic I know but this router is interesting. Is it true DLM banding can be removed? Can SN margin be adjusted lower than what DLM sets?
-
Sorry this is a bit off topic, but has anyone been able to remove the banding on a line using a Billion router?
-
This thread is for the Asus not Billion.
Banding can not be removed on the billion but I believe it can be done on the AC68U. However I would stay clear of this device as its unstable and what put me on a banded profile in the first place.
Seriously - you need to get over the fact that you are banded.
-
I've removed some unnecessary comments after this.
-
For info; I thought last Friday I would reconnect this device as a modem/router instead of just a router connected to my HG612. I was hoping that the new firmware would work for me but alas yesterday morning Fastpath had gone. So back to the HG612 and the ASUS as router only and this morning Fastpath is back.
In addition the HG612 is now reporting that G.INP is enabled (I'm on an ECI cab) whereas last week it wasn't.
-
2 newer updates from ASUS
It's good to see they still care about this product and are trying to make it the best they can
-
Tried the latest update the Friday before last and after only 3 days I'd lost FastPath yet again. Switching back to the HG612 and FastPath (as well as G.INP (ECI Cab)) was back 24 hours later. Must admit I like the ASUS as a router only though but as a Modem (for me at least) it sucks...!!!
-
I think that is the general consensus for the majority of users.
One guy on overclockers (could well be on here too) has stated there will be another model coming out with a broadcom chipset which could be quite interesting.
-
I was notified by the AC68U last week that a new firmware was available so still having a little faith in this unit I decided to upgrade and try once again using it as a modem/router rather than just router. So far I'm syncing slightly higher than with the HG612 and I'm still on FastPath whereas historically I'd lose it after a couple of days. Anyway below are my current stats. Errors seem ok but can someone in the know cast an eye over them and give me some feedback please? Hope I've not jinxed myself now lol...
cat /tmp/adsl/info_adsl.txt
xDSLmode=VDSL
outDiscards=57563
inDiscards=813
outBytes=3749580258
inBytes=2653688882
outPkts=35550249
inPkts=79208886
CurrentProfiles=17a
UPBOKLE=10.4
TRELLISds=1
TRELLISus=1
ACTSNRMODEds=1
ACTSNRMODEus=1
ACTUALCE=640
SNRMpbds=5.7,5.6,5.7,N/A,N/A
SNRMpbus=6.0,5.8,6.0,0.0,0.0
LATNDown=10.5,28.7,44.7,N/A,N/A
LATNUp=0.1,21.0,32.4,0.0,0.0
SATNDown=18.3,29.3,46.3,N/A,N/A
SATNUp=0.1,20.8,32.4,0.0,0.0
fwVer= FwVer:5.5.2.3_A_A60901 HwVer:T14.F7_0.2
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.0 dB
AttenDown=10.5 dB
SNRMarginUp=6.0 dB
AttenUp=0.1 dB
DataRateDown=58524 kbps
PathModeDown=FastPath
DataRateUp=16535 kbps
PathModeUp=FastPath
WanListMode=1
FECDown=14022
FECUp=1531
CRCDown=2255
CRCUp=276
HECDown=0
HECUp=0
ADSLUpTime=3 days, 19:45, 22 secs
ADSLActiveTime=0 min, 21 secs
PowerDown=13.3 dbm
PowerUp=6.4 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
FarEndVendorID=Infineon(Lantiq)
AttainUp=16312 kbps
AttainDown=73208 kbps
ShowtimeStart=21
TotalStart=21
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
TCM=On
InterleaveDepthDown=1
InterleaveDepthUp=1
INPDown=1.1 symbols
INPUp=0.8 symbols
AdslStandard=VDSL2
AdslType=ANNEX_A
mtenStandard=G.dmt.bisplus (Annex L)
-
New firmware came out yesterday and fixes ECI cabinet issues :)
-
Yes see my stats above. Been using since the 9th and going strong at 8 days 8 hours uptime. And yes I'm on an ECI cab.
-
Hello,
Is there any way to increase Interleave Depth on this router? I'm pretty far from the exchange about 1KM :-\ and on 50/5 proflie is my Interleave depth set to 455. Few weeks back I was connected to old port where was ID set to 1300, and it worked much more stable. Same question for INP settings.
Our main ISP recently announced that it will apply the vectoring "as brand new technology", but we must wait several months (years) for its full deployment.
Thank You
-
can anyone who still uses this modem please complete the feedback form within the settings asking for them to add es/ses to the connection stats. if there's enough demand they say they'll add it to the next firmware release. most likely only to the telnet stats and not gui but better than nothing at all.
-
New firmware:
ASUS DSL-AC68U Firmware version 3.0.0.4.380_3281 (This product supports both Annex A and Annex B)
Security improvement:
- Fixed Samba Badlock CVE-2016-2110 (Man in the middle attacks possible with NTLMSSP).
- Fixed Samba Badlock CVE-2016-2111 (NETLOGON Spoofing Vulnerability).
- ASUS firmware did not enable Samba LDAP, and not affected by CVE-2016-2112 (LDAP client and server don't enforce integrity) issue.
- The Samba version in ASUS firmware was not affected by CVE-2016-2118 (SAMR and LSA man in the middle attacks possible) .
- The Samba version in ASUS firmware was not affected by CVE-2015-5370 (Multiple errors in DCE-RPC code).
- Fixed command injection issue. Thanks for Chris' contribution.
- Fixed XSS issue. Thanks for Chris' contribution.
New feature:
- URL Filter now supports HTTPS sites blocking.
DSL:
- DSL firmware updated: v1.0.3.6.
- Fixed multicast packets delay issue.
- QIS enhancement:
* Redirect to manual setting while sync up with Annex B.
* Extend waiting time from 60 seconds to 90 seconds before switching Annex mode.
* Fixed DSL status issue in Annex B mode which cause longer Annex mode switching time.
- ADSL WAN (ATM) QIS manual setting list updated.
Modify Turkey ISP TTNET to Turk Telekom.
Add United Kingdom ISP, Kcom.
Add New Zealand ISP, TrustPower.
Add South Africa ISP, Crystal Web.
Add Italy ISP, TIM.
Add Iran ISP, Tcmnet.
Add Poland ISP, Orange.
Add Algeria ISP, Jawab.
Add Faroe Islands ISP, Foroya Tele.
Add Uganda ISP, PoolDeep.
- VDSL WAN (PTM) QIS manual setting list updated.
Add New Zealand ISP, 2 Degrees Broadband.
Add Poland ISP, Orange (VLAN ID 35).
Add Faroe Islands ISP, Foroya Tele.
Bug fixes and Enhancements:
- Fixed Media Server related issues.
- Update the path of Download Master FAQ link & Tool.
- Modified the name string "WCDMA (UMTS)" to "WCDMA (UMTS) / LTE".
- Add 'Cancel' link for certain notification cases.
- Add IPv6 support of radius server IP address.
- Fixed the compatibility issue with EDGE browser in Internet Connection page.
- SSH: support ECDSA key.
- Fixed NTP related issue.
- minidlna: all full realvideo support.
- Enhance IPv6 UDP throughput.
- Fixed Fail-back issue with PPP.
- Fixed no error page in PPP authentication failed case.
MD5:23e602487efc4dade712ba351ebf82d0
-
I have just order one and will be here Tuesday, will report back on how it goes on my sky fibre unlimited pro line.
-
I have just order one and will be here Tuesday, will report back on how it goes on my sky fibre unlimited pro line.
i own 1, and wouldnt dream of plugging the modem side back in. i'd highly recommend a broadcom based modem. asus are the only company i know to use this mediatek chipset and it's useless.
-
MediaTek chipsets are meant to be good on short lines arnt they? And I would also consider getting one of these just because they seem determined to fix it and are still pushing out good firmware updates.
-
They've been pushing out frequent updates since it was released and it still seems busted to me. there are many better modem/router on the market.
One of these also caused me to be banded permanently, only removed by changing providers. My line is about 500M long and has very few errors, and yet the DSL-AC68U still managed to cause DLM to take the harshest action it could.
My advice would be to avoid at all costs.
-
MediaTek chipsets are meant to be good on short lines arnt they?
I don't think that applies to VDSL2, it may have been said about TrendChip ADSL2+ chips, and TrendChip became the DSL part of MediaTek. And even on ADSL2+, I've seen reports of weird issues where certain Asus devices couldn't establish a connection, apparently because the target SNRM was 3 dB.
-
MediaTek chipsets are meant to be good on short lines arnt they? And I would also consider getting one of these just because they seem determined to fix it and are still pushing out good firmware updates.
they keep pushing out firmware update to fix the router side of things. The dsl driver version doesn't change as often. if you contact Asus support about line problems, instead of fixing their useless equipment their default response is to have the noise margin to override the DSLAM. My 1st suggestion from Asus was to set it to 8dB, when that didn't work they recommended I set it to 10dB. The entire VDSL system in the U.K. is configured to work with a 6dB noise margin, and this junk can't do it. It isn't good on short lines, it's just much worse on long lines.
It also has absolutely no ability to view detailed error stats. even the telnet output only gives CRC errors. without connecting a USB, enabling 24 hour monitoring, then viewing the files on the USB afterwards, there is absolutely no way to see ES/SES on the line. enabling this monitoring forces a resync, so I'd need to resync everyday and plug/unplug USB just to view errors.
Just pop on the Aus forum, visit this modems sub section and look for yourself. There's a 2 year long thread about it dropping the PPP session, that STILL isn't fixed.
I've never been so disappointed with a piece of hardware, especially 1 as expensive as this. The support has been absolutely non existent. I gave up on the modem a long time ago and it now operates as a router only. I'd have been better buying the RT-AC68U as at least I can stick the likes of Merlin on that.
-
This modem I think combined with fritzbox is responsible for the abandoned eci g.inp rollout. Make of it what you will.
-
Don't Zen supply the fritzbox as 'recommended for fibre'?
-
I be surprised if they do as they expensive units.
-
https://www.zen.co.uk/yourhome/routers/
-
Interesting about the FritzBox 3490, I thought ISPs had to supply MCT passed devices, but then sometimes the requirement was worded that ISPs needed to have a certified device, which doesn't quite mean the same thing. The FritzBox 3490 may have passed and the publicly available lists of approved devices are out of date.
-
Ok they sell it rather than give it out as a inclusive device, but yeah I see they recommend it.
-
So this is one of the devices "responsible for the abandoned eci g.inp rollout"? Can you explain further please?
-
Just looking around the internet and seeing people with fritzboxes saying they couldnt get online when g.inp enabled, plus the post on sky saying they couldnt get online with a dsl-ac68 also (that guy got online after disabling g.inp in the dsl-ac68 settings), this matches the explanation given by openreach stating the rollout had to be rolled back due to ppp sessions refusing to connect.
Yet even tho many more people will have devices like the openreach modems and homehubs, I couldnt find a single person using either a sky hub, homehub or hg612 not able to get online with g.inp.
-
Thanks. So Zen have been doing their bit to break the internet
-
well it may be that particular model is ok, there is different models, not all fritzboxes use the same chipset.
If I come across another post I will post the link, I already posted the link to the dslac68 guy in one thread on here.
-
Quite a few of the FritzBoxes use the Lantiq VRX200 chips, the same as the BT HH 5a and Openreach ECI modems, so it shouldn't be that difficult to sort out the firmware so they work fine. I think a FritzBox was submitted for MCT testing at one point. The FritzBox 7490 won an ISPA award (https://en.avm.de/news/awards/2016/fritzbox-7490-voted-best-hardware-by-providers/), it seems a bit odd if they gave the award to something they're not supposed to supply for FTTC.
the explanation given by openreach stating the rollout had to be rolled back due to ppp sessions refusing to connect.
Did Openreach even tell us that about the ECI G.INP rollout? I found nothing besides them saying there was an increase in the rate of fault reports, I didn't find any details of the specific issue(s).
-
They didnt tell us no, but they told CPs.
-
I have just order one and will be here Tuesday, will report back on how it goes on my sky fibre unlimited pro line.
Constant disconnects and lower speeds with this product, waste of money.
-
Constant disconnects and lower speeds with this product, waste of money.
:( Thank you for reporting back with your findings.
-
Took it back to Curry's and got a full refund no quibbles, even though I have had it just over a month.
-
So that's an eventual good result after a bad experience! :)
-
Anyone know if the disable upstream power back off (upbo) feature on this router actual works.
Since my ECI cabinet had it's firmware changed from 0xb206 to 0xd086 my upstream sync has rarely been above 0.5Mbps, I'm getting that desperate now I'm considering trying a Asus router.
For info:
xdslctl info --pbParams
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 604 Kbps, Downstream rate = 30258 Kbps
Bearer: 0, Upstream rate = 519 Kbps, Downstream rate = 25379 Kbps
Discovery Phase (Initial) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (33,857) (1218,1959) (2795,4083)
Medley Phase (Final) Band Plan
US: (6,31) (882,995)
DS: (41,857) (1218,1535)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 604 kbps 30258 kbps
Actual Aggregate Tx Power: 3.6 dBm 11.9 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 12.4 62.3 61.7 N/A N/A 25.2 77.2 90.3
Signal Attenuation(dB): 12.2 59.4 N/A N/A N/A 32.6 79.2 N/A
SNR Margin(dB): 7.7 5.9 N/A N/A N/A 5.9 6.1 N/A
TX Power(dBm): 0.9 0.2 N/A N/A N/A 11.3 3.2 N/A
-
Have you tried a modem containing a Lantiq chipset recently, e.g. an ECI modem running OpenWRT? Or even a BT HomeHub 5A / Plusnet Hub One?
-
Yes, tried a HH5A -- no change in upstream but downstream dropped from 25Mbps to 16Mbps.
I have got a ECI modem running openWTR, not tried it since this problem started but I'll give it a go next week. Do you know if it has a cli command to adjust upstream power?
So far BT support have been useless, I've even made a formal complaint which is going nowhere. I'm now waiting for the 8 weeks before I can progress it to OFCOM (or whoever it is these days).
-
I don't think anything else has any commands to adjust upstream power, I did look into a lot of low level commands that involve typing in a bunch of numbers (http://forum.kitz.co.uk/index.php/topic,18511.0.html). I have just spotted a Lantiq thing that should make it theoretically possible to enable/disable AELEM, if anyone can work out the exact numbers to plug in.
-
Anyone know if the disable upstream power back off (upbo) feature on this router actual works.:
it made absolutely no difference to my upstream sync. 6.8mb off/default/on.
-
Anyone know if the disable upstream power back off (upbo) feature on this router actual works.
You should always ensure that upbo is enabled - any other setting can interfere with your FTTC connection and those of your neighbours.
-
So that's an eventual good result after a bad experience! :)
Yeah it was a result.
And I managed to pick up a Netgear D7800 nighthawk off eBay to replace the Asus. I'm on an ECI cabinet and the Netgear has a lantiq dsl chipset to match the cabinet.
-
. . . I managed to pick up a Netgear D7800 nighthawk off eBay to replace the Asus. I'm on an ECI cabinet and the Netgear has a lantiq dsl chipset to match the cabinet.
Perhaps you might like to document your experience with the D7800, in due course?
-
@ejs
A google search indicates the Lantiq chipset may well have settings to adjust the upbo, but I've found nothing to indicate the actual cli commands.
Time to get the ECI modem from the back of the cupboard and start playing ;)
@gt94sss2
AFAIK upbo is intended for use on short loops to reduce crosstalk from them interfering with the signal coming from more distant subscribers. I'm on the end of 1 Km of mixed copper and aluminium, I doubt a strong upbo settings is intended for this type of line.
I've notice in "My BT" that BT have now marked this fault as complete! >:(
Still getting the same 0.5Mbps upstream sync on my VDSL connection. How on earth do you contact anyone at BT support with the slightest knowledge of how VDSL works or who has any interest in trying to help paying customers.
-
This tends to be the kind of thing for which I find nothing useful from Google. The only obvious UPBO related command is g997upbosg / G997_UsPowerBackOffStatusGet - any "status get" commands are information retrieval, read-only commands.
-
Anyone know how to bypass the router part of the DSL-AC68u and make it work with an ECI modem?
I have the modem and the Asus here, when I tried running WAN through Ethernet it didn't work at all.
Also do I need to login to the ECI somehow to enter the connection details or do I do that through the router? DSL light comes on etc but being just a router it never asks for user/pass etc.
-
the modem is just a modem. You can't login in to the eci modem unless you unlock it hardware wise which is not straight forward. If you are on vdsl service the eci modem should just work as a modem with no extra settings. You would need to connect a router to port 1 and configure the wan port for your ISP. I am not sure if the DSL version can be made to work in router only mode. Ideally you could just use a RT-AC68U if you were able to swap it and connect that to the ECI modem.
Who is your ISP as you will need to set the wan port with the right settings. I am sure someone will comment if the DSL version can be made to run in router only mode.
-
You can easily set the DSL version to run as router only and have a seperate modem. Off the top of my head, I cannot remember as it has been so long since I last used it.
-
I used to use my DSL-AC68U with an HG612 when I realised how rubbish the internal modem is, so it definitely can be done.
-
Off the top of my head, it's under the dual wan settings. don't enable dual wan, change from dsl to Ethernet port of your choice, connect that Ethernet port to lan port 1 of the ECI.
-
Got it working, had to enable dual wan, set ethernet 1 as primary and USB as secondary. Fully working now, speeds are less than old house was but 32/6 which isnt too bad I suppose? DNS is super fast though, I click a link and it loads instantly!!
Not sure how great my ping will be in Rocket League via Steam anymore, used to be about 8, servers on speedtest.net are around 30 ping!
ping bbc.co.uk in xTerm gives average of 112ms :/
-
dual wan doesn't need enabled, and shouldn't be. It's for using dual wan.
I'm using it right now, dual wan off, Ethernet wan selected, lan port 1, connected to a ZyXEL 8924 in bridge mode.
-
Anyone know how to bypass the router part of the DSL-AC68u and make it work with an ECI modem?
For completeness, I will just say that your query should have been --
Anyone know how to bypass the modem part of the DSL-AC68u and make it work with an ECI modem?
-
Having serious issues with this router now. It periodically (read, every 3 mins or so) stops sending data to all wifi clients, but still shows them as connected.
Also for a device with 3 ariels on its performance is poor on both 5ghz and 2.4ghz. Loses 1 out of 5 bars just 3 feet away (through a plaster wall / door).
I just set up a tp link extender (with great difficulty and cant be sure now even that its working) and it still does it.
You will get no connection or "connecting to google.co.uk" and then it times out, but the router still keeps 2 or 3 bars of connection with the client. I thought this an ubuntu issue (there are threads out there for ubuntu) but it does it with my Kindle too which is android based.
If a family member tilts her ipad to reading level, she loses connection, only works with ipad flat.
Exasperated.
-
Just for the lolz
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F5719053991.png&hash=c7377eccbbe5320c2ea19419649366ba9253ce3c)
Is the BEST I can get, but dl speed is normally ~14mb/s
-
Make sure you're on the latest firmware. With this particular modem/router every time I've updated the firmware it's caused bugs, requiring me to restore default settings then setting it up again. Looking at the Asus forums many users also have this problem. So 1st advice would be make sure you're on the latest firmware, then restore default settings, then tweak your own settings. The modem is absolutely useless, but it's wireless is absolutely fantastic for me. I get full reception upstairs through about 4 walls on both 2.4ghz and 5ghz, on multiple devices running various OS's.
-
The latest asus firmware for any router older than the ac8x models is a bad idea in my opinion, asus started to cripple wifi power levels to comply with american regulators, and as a result all of their new firmwares have not so good wifi stability/performance as their older firmwares, this is one of the reasons john forked of asuswrt-merlin and why I use his firmware.
With that aside one has to remember wifi is a convenience technology, if you want performance use ethernet.
-
The latest FW was the first thing I did!
Extender seems to have helped but notice the signal drops back to 2 bars as if the extender isnt there anymore. Also it is still cutting out as if it is down but shows it is up.
-
The latest asus firmware for any router older than the ac8x models is a bad idea in my opinion, asus started to cripple wifi power levels to comply with american regulators, and as a result all of their new firmwares have not so good wifi stability/performance as their older firmwares, this is one of the reasons john forked of asuswrt-merlin and why I use his firmware.
With that aside one has to remember wifi is a convenience technology, if you want performance use ethernet.
Even better, use Hugo Gomes' Merlin fork fw. It unlocks all wifi channels (so great if you've purchased a router from USA) and allows you to change wifi power levels...obviously you should follow local wifi power regulations ;D I'm using it on my AC5300 and even on the default wifi power levels, i find the wifi coverage far better than stock Asus fw and even Merlin fw. PM me for more info :)
-
Using johns fork and setting the region to null does the same thing.
Ironically the Americans have the least restrictive 5G so its other regions trying to switch to USA not the other way round.
-
I wonder if I can use that firmware on my DSL-AC68u?
I read DSL ones are not supported but a guy on the forum claimed it works just like if it is an RT model as long as you are using another modem as a modem. Which I am.
Wireless is Okish now, I am finally typing this on my 5ghz gaming pc, won't be wired for another week so I am using a TP-Link extender to connect to the wifi network and an ethernet cable from that to the PC.
In a weeks time an ex BT guy is coming to move the master socket, re-wire the house if needed, disconnect all the wired connections (because we use a single wired phone base station and cordless phones) and I am hoping he knows someone who can sort out the noisy line to the box because our upload speed SUCKS.
Here is latest speedtest, via wifi, quite impressed at the download speed considering its wifi and we have 3 repeaters and the modem is on the ground floor at the other end of the house...but the upload sucks!
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F5728069395.png&hash=891d83e3f5ba887c292ffe866ec12d67b81d5728)
-
I wonder if I can use that firmware on my DSL-AC68u?
I read DSL ones are not supported but a guy on the forum claimed it works just like if it is an RT model as long as you are using another modem as a modem. Which I am.
Personally I wouldn't risk putting third party RT-xxxx firmware on a DSL-xxxx router, you risk bricking your router. What you could do is sell your DSL-AC68U to some sucker/fool on ebay and either invest the funds in a RT-AC68U or you could wait a month or so and invest in the new Asus BRT-AC828/M2, Asus' first Qualcomm based Wave 2 Mu-Mimo 4 stream router. This should blow all other routers out of the water ;D
http://ifworlddesignguide.com/entry/199723-brt-ac828m2
https://wikidevi.com/wiki/ASUS_BRT-AC828/M2
-
The DSL variants don't work with 3rd party firmware, even if you don't plan on using the modem.
-
As said before only official asus firmwares will work on the DSL model, we did advise you to exchange it for a RT model.
-
Finally wired!
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F5746511198.png&hash=8e100583fde27c2f2bb2fae5f34d706c9f164f6d)
So roughly half the speed of my old house :/
This asus router is terribad. If you run a speedtest 1 feet from it, you get 32mbps download.
If you run a speedtest 10 feet from it, in the same room, you lose 1 bar of signal and get 21mbps download.
The ex bt engineer was amazed, in a bad way, has never seen this before. He said it is either electrical disturbance (there is nothing though so doubtful) or the actual Asus.
-
Probably the Asus after their power limiting firmware upgrade. I tested my dsl-ac68u back to back with my netgear d7000 and the difference was quite large. In fact I could constantly get double the speed on the netgear when the distance increased.
Have you tried a wifi analyser app to see if you can change any channels to help?
-
Nope. What I do have is a Netgear WNR2200 which is about 6 years old to use instead, good idea?
Is there any way of flashing the old firmware without the EU restricted problems?
-
It's more likely you're on a very congested channel. The power level changes on the Wi-Fi are very small, not going to cause a huge drop in throughput from a few extra metres away.
The modem on the DSL-AC68U is useless, hopeless, rubbish. The Wi-Fi is absolutely fantastic, the range is faultless. I'm currently connected at 750Mbps on 5Ghz, a quick switch to 2.4Ghz connects at around 250Mbps. This is as far away in the property from the router I can be. The router being next to the master socket at front of property downstairs, I'm at the rear of the property upstairs. I connect at full speed anywhere downstairs. Throughput to my phone is 15MB/s (over 100Mbps), probably the max my handset allows.
The Wi-Fi components inside the DSL-AC68U are the same as in the RT-AC68U. Others recommended you swap the DSL for the RT for good reason, it performs great.
The ex bt engineer was amazed, in a bad way, has never seen this before. He said it is either electrical disturbance (there is nothing though so doubtful) or the actual Asus.
I would throw a guess that he's not been an engineer for a while, i.e pre mass use of consumer wireless. The vast majority of "my broadband is too slow" complaints are due to running tests in a wireless state. To instantly blame the router is naive as any decent 1 will perform poor if heavily congested.
If you're getting such bad Wi-Fi speeds then you really need to run something like "Wi-Fi Analyser" on android/ios, it's a completely free app. You need to find yourself the quietest free channel, and manually select that on the Asus. Channels 1, 6, or 11 are best on 2.4Ghz. Using say channel 4 because 1, 6 & 11 is busy and there's nothing in between, is slower than sharing 1 of those channels.
http://www.extremetech.com/computing/179344-how-to-boost-your-wifi-speed-by-choosing-the-right-channel
-
It appears that 2.4ghz is bad, 5ghz seems great?
I will do as you suggest later on. Will this app run on an iPad?
He said I think, BT engineer for 11 years, self employed for 6 years?
He was brilliant at what he did but he did say some of my questions (asked from replies here) went over his head. He also pointed out the distribution point for FTTC was less than 10m from the house.
-
Finally wired!
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F5746511198.png&hash=8e100583fde27c2f2bb2fae5f34d706c9f164f6d)
The internet drops out daily, according to the router this happens at the WAN connection. I don't think it is an Asus issue I think it is a cabinet issue.
Currently
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F5766412274.png&hash=f0ca7d06a34b910ae5de9d068bb88a162773c09d)
Losing speed daily :/
-
Why not get hold of a bt modem (e.g hg612 3b)and gather some stats via a pc real time and then put the 68u in router only mode. Line stats would really help by the looks of it..
If the modem is resyncing it may be lowering your ds sync. And lowering speeds?
-
That seems to be a common issue with the 68U. It shows as WAN disconnects and gives a resync. My speed kept dropping every day also. Switched to the HG612 and within a few days I was back up at full speed.
-
I am using an ECI modem with the 68u in router only mode.
I can't log from the ECI modem as it is locked and I don't know how to unlock it, nor do I currently have anyway of doing so, no serial port etc on the PC which is 30m away from it.
-
Unfortunately there is no easy way to log using the ECI or Asus unit. Better off ditching the ECI and getting a Huawei HG612. Easily flashed then use DSLStats to monitor. I'm currently using DSL Stats with my Netgear D7000. Perfect!
-
I am using an ECI modem with the 68u in router only mode.
I can't log from the ECI modem as it is locked and I don't know how to unlock it, nor do I currently have anyway of doing so, no serial port etc on the PC which is 30m away from it.
You don't need a serial port, basically you have to get the case open, drill the board in 3 places to take some header pins, use a serial usb adapter, flash the modem with the image that was created by one of the members. I have done 3 or 4 and it does allow you get the stats from the modem from lan port2 - does not work with the current stats program but you can at least get some real time stats directly. If you want to upload your stats etc then you need another modem :)
-
Hi guys, long time lurker but first time poster - please be gentle as I have been rogered by BT once today.
OK here's my dilemma, I am pretty sure the cab up the road from me is a Huawei cab.
Fiddled and fiddled with the DSL setting but not joy I'm afraid, now my homehub (steaming pile of sh**te) sync's at 55mg no problem.
I have tried many diff version of fw over the last month and am at my wits end for some reason the asus will only connection at 49mb.
I i run a server with dyn dns provided by asus which on the hole works quite well. Until the last few days where my connection has been dropping more often than a cheap hooar.
I have read through the thread and at the moment considering the hammer treatment or another decent router that will run dyndns
I am all for scrapping the router as most see to agree is absolute pish (aside from wireless)
I have been looking at the nighthawk and also the billion 8800nl..
your thought please gents...
-
The general opinion is that the DSL-A68U is a rotten modem but an excellent wireless router. The best solution technically is probably to get a separate modem operating in bridge mode, feeding the Asus for the wireless router functions.
-
I had the same problem with it syncing a lot less. I ended up running with a HG 612 with the cracked firmware from here hooked up to the DSL-AC68U. I then swapped the two box method and went with the D7000. Better wireless speeds, Better modem, All in one solution. Seems to be a solid device.
-
New firmware 3.0.0.4.380_4026
Security improvement:
- Fixed page redirect/ CSRF/ XSS security related issues.
- Remote DHCP information disclosure.
DSL:
- DSL firmware updated: v1.0.3.7.
- G.INP (G.998.4) now enabled by default.
- ADSL WAN (ATM) QIS manual setting list updated,
Add Australia ISP, Dodo (PPPoE).
Add Australia ISP, Dodo (PPPoA).
Add United Kingdom ISP, Origin Broadband.
Add Iran ISP, Hiweb.
Add Iran ISP, Mci.
Add Iran ISP, Mokhaberat.
Add India ISP, Reliance (PPPoE).
Add India ISP, Reliance (MER).
Add South Africa ISP, Vanilla.
Add South Africa ISP, Imaginet.
Add South Africa ISP option, Other ISP.
Add Italy ISP, EOLO.
Add Italy ISP, TIM (PPPoE).
Modify Italy ISP, TIN -> TIM (PPPoA).
Add Iran ISP, Bistnet.
Add Iran ISP, TCT.
Add Iran ISP, Shahrad.
Add Iran ISP, TCI.
- VDSL WAN (PTM) QIS manual setting list updated,
Add Australia ISP, Skymesh (NBN).
Add Australia ISP, HabourISP (NBN).
Add Australia ISP, iiNet (Automatic IP)(NBN).
Add Australia ISP, iiNet (PPPoE)(VLAN ID 10).
Add Australia ISP, NBN (PPPoE).
Add Australia ISP, NBN (Automatic IP).
Add South Africa ISP, Afrihost (VLAN ID 835).
Add South Africa ISP, Afrihost (no VLAN ID).
Add South Africa ISP, Telkom Internet - do Elite (VLAN ID 835).
Add South Africa ISP, Telkom Internet - do Elite (no VLAN ID).
Add South Africa ISP, Axxess (VLAN ID 835).
Add South Africa ISP, Axxess (no VLAN ID).
Add Australia ISP, Telstra (Static IP).
Add Australia ISP, Telstra (Automatic IP).
Add Finland ISP, Partel.
Add India ISP, Dataone.
Add Finland ISP, DNA.
Add Italy ISP, TIM.
Bug fixes and Enhancements:
- Fixed Wi-Fi 5GHz LED issue in beta firmware v9.0.0.4.380_3879.
- Fixed WPS to restore security related defaults. 5GHz auto channel select issue after WPS reset.
- Fixed the Model Name and Model Description in UPnP information.
- Fixed the issue of configuring QIS by wireless client.
- Updated the Plus' APN data of Poland.
- Fixed the redirection rule for getting back to web UI after changing httpd protocol.
- Add ASUS Member registration URL link in QIS finish page.
- Removed some websites which Ping fail in Network Analysis.
-
The general opinion is that the DSL-A68U is a rotten modem but an excellent wireless router. The best solution technically is probably to get a separate modem operating in bridge mode, feeding the Asus for the wireless router functions.
I have so many problems with this device, my ISP is Plusnet and I can go for weeks with a stable connection, then out of the blue, loses connection and have difficulty in re-connecting. I bought a cheap TP-link TD-W8960N to test my line, the connection is up and running within a few minutes but the device isn't powerful enough to connect all my network devices throughout my household.
Has anyone setup a bridge with the TP link as the modem and the Asus AC68, the router.
-
So re: the new update.
I had some issues with mine dropping wifi constantly on both 2.4ghz and 5ghz. The firmware update (it had not been updated since factory; 2016 for me) fixed this.
But now the router intermittently drops my ethernet lan connection instead.
I'm wondering if routers go wrong after 4 years maybe a capacitator leaking or something can cause this ie hardware fault? Should I buy an RT-AC68U to replace it?
Is there anything better out there by a different brand or a different Asus model? Not a fan of the modem inside the router it drops out constantly so I use an ECI currently.
-
So re: the new update.
I had some issues with mine dropping wifi constantly on both 2.4ghz and 5ghz. The firmware update (it had not been updated since factory; 2016 for me) fixed this.
But now the router intermittently drops my ethernet lan connection instead.
I'm wondering if routers go wrong after 4 years maybe a capacitator leaking or something can cause this ie hardware fault? Should I buy an RT-AC68U to replace it?
Is there anything better out there by a different brand or a different Asus model? Not a fan of the modem inside the router it drops out constantly so I use an ECI currently.
I'd say it somewhat depends on your DSLAM's chipset and line characteristics. For example, when I had VDSL2 I found that a Lantiq chipset worked best with the ECI DSLAM I was connected to. Some people have found a modem with a Broadcom chipset, on the other hand, works better for them. It's really what works best for certain lines. I could've used Broadcom too but I found I had less ES/CRC errors with a Lantiq chipset (e.g. DrayTek Vigor) and I could adjust the SNRM target offset for the downstream.
-
Well I use an ECI modem as it's an ECI dslam apparently. I don't get that many disconnects to the dlsam anymore rather disconnects between the router and the computers it is routing.
Since 2016 when I bought the AC68U I have been through 3 of them due to (what I think is) capacitor leakage...getting tired of that now.
I think I'm going to look into PFsense or something like that. I only use a few ports, web, Plex, a Deluge torrent port and sFTP. It can't be that hard... the advantage is I can use the pfsense or equivalent pc I'm using as a router, as a piHole also.
-
Well I use an ECI modem as it's an ECI dslam apparently. I don't get that many disconnects to the dlsam anymore rather disconnects between the router and the computers it is routing.
Since 2016 when I bought the AC68U I have been through 3 of them due to (what I think is) capacitor leakage...getting tired of that now.
I think I'm going to look into PFsense or something like that. I only use a few ports, web, Plex, a Deluge torrent port and sFTP. It can't be that hard... the advantage is I can use the pfsense or equivalent pc I'm using as a router, as a piHole also.
I misread your original post, I see you have the router only (RT-AC68U) and not the troublesome variant which had a Mediatek chipset for the modem (DSL-AC68U). Yeah pfSense is a good option.