Okay, had no idea I could do that, but a quick search told me how! I was getting 32 or 33 ms - dunno if that's good or not, objectively speaking but it's very close to what speedtest.net gave me.
Anyone Using an Asus DSL-AC68U
- Thread starter Socrates470BC
- Start date
Okay, had no idea I could do that, but a quick search told me how! I was getting 32 or 33 ms - dunno if that's good or not, objectively speaking but it's very close to what speedtest.net gave me.
Assuming you're not on fastpath and your standard ping on fastpath would be 8-12ms) then I'd guess that you're on either a 16ms max downstream delay, or an 8ms max downstream delay with an 8ms max upstream delay (16/1 or 8/8). I'm currently 16/1 with INP 7/0 (downstream/upstream) and DLM isn't looking to budge it down unless I stop using the ASUS. I still wonder if FEC errors/FEC seconds are considered by DLM in whether it will make a positive change, as I'm getting a stupidly high amount with the ASUS.
Associate
- Joined
- 11 Jul 2011
- Posts
- 178
- Location
- Aberdeen
Is there a reason you're still using the ASUS, other than wanting a single box solution - you've got ECI and HG612 modems either of which will remove the interleaving relatively quickly and give you some stability at least.
Yes. I did run the Fritz!Box 7490 prior to it crashing randomly, presumably relating to my no NAT setup, but even with the weeks of running it DLM was very slow in taking positive action. I'm still trying to figure out the 'official' method of applying multiple public static IP's with a no NAT setup on the 7490 - hoping that will resolve the crashes. As for the ECI/HG612, I could go back to them but just don't like the idea of running three boxes instead of two (one for the modem, one for router public static IP with no NAT, and finally one for LAN IP allocation). I might resort to that soon though.
Because the guy has been doing some amazing work in trying to find a solution to why the modem has these issue. I'd say that is most comendable...
Associate
- Joined
- 27 Oct 2014
- Posts
- 28
Holding steady...
I've been back using the Asus on the latest firmware exactly 3 days after my line recovered from the previous DLM intervention.
Seems pretty stable so far - FEC errors are tiny now - around 300 in 3 days, instead of the millions it would be previously, although downstream CRCs are now much higher - around 21000 in 3 days. No line drops so far. Sync rate is pretty much identical to Openreach modem.
I guess we don't have easy access to an ES/SES count - does anybody have any opinion on how that kind of CRC count is likely to hit me with DLM (or not)?
I've been back using the Asus on the latest firmware exactly 3 days after my line recovered from the previous DLM intervention.
Seems pretty stable so far - FEC errors are tiny now - around 300 in 3 days, instead of the millions it would be previously, although downstream CRCs are now much higher - around 21000 in 3 days. No line drops so far. Sync rate is pretty much identical to Openreach modem.
I guess we don't have easy access to an ES/SES count - does anybody have any opinion on how that kind of CRC count is likely to hit me with DLM (or not)?
Associate
- Joined
- 11 Jul 2011
- Posts
- 178
- Location
- Aberdeen
Without having the ES/SES count you've no way of knowing - you could have 21,000 ES or you could have 500. All depends on how the CRCs were generated, and seems to be the ES/SES that are taken into account.
For example, when I was using a HG612 which was unlocked, I could see that I would have bursts from time to time of 500+ CRC but only generated a couple of ES/SES. But single CRC would produce a single ES.
I think the key is, if we can use those settings and then the modem starts working properly then it helps to isolate the problem. If you do that, and it starts working fine, but the speed drops considerably, then clearly we still need to keep working but hopefully it will get us closer to the ultimate solution.
Hi, thanks for checking this for us. I don't think we'd be able to collect the results that way - we need the submissions to come through the form. I appreciate that in some instances with DLM issues users won't want to keep it connected, so best solution in that instance is to send off the report and then disconnect.
I understand if you don't feel able to submit further reports, but I'll keep on with the ones we do have and see what I can find out.
Hi Virus, this is the first I've heard about this issue. Can you please give me some further information about what's happening or link me to a thread? I'm not sure I totally understand what the problem is from the info you've provided.
My present understanding is that the problem is linked to the line - so a lot of lines work without issue, whilst others the modem doesn't deal with well. Of course, that doesn't mean that the line is the problem, because if other modems can cope with it then so should ours, but it does mean that the problem doesn't manifest itself on every Infinity line. However, I'm not the most technically literate when it comes to modems so this could be wrong and is just my best understanding of the problem.
No the issues aren't resolved at all.
Associate
- Joined
- 29 Sep 2014
- Posts
- 64
But after the line reset won't the counters that make up the stats file have been reset to zero because of the line reset? I can see the logs being useful but not without some stats to match them to - is the submission sending data we don't have access to?
Associate
- Joined
- 29 Sep 2014
- Posts
- 64
Jim. Have made the submission using the feedback form on the device - back on the HH5 now - has 232 CRC errors in around 17 mins.
Associate
- Joined
- 27 Oct 2014
- Posts
- 28
OK For infinity?
It's a complete gamble with no obvious clues - Works well for some, but not for others.
I'd not recommend it at this point unless you're feeling lucky!
It's a complete gamble with no obvious clues - Works well for some, but not for others.
I'd not recommend it at this point unless you're feeling lucky!
Exciting news. I've been using this modem/router for about three or four weeks now. Initially, I was on fastpath, but had a ton of CRC errors and got put on interleaved almost immediately. The only things I've done have been to upgrade to the latest firmware as it's become available, and make these settings changes (suggested by bitsNbobs):
That was 14 days ago. Since then, I've been slowly regaining speed and now I'm back on fastpath!
As far as I'm know I'm the only person here on an FTTC connection who has got put on interleaved and then put back on fastpath?
Since now seems like the perfect time to watch for more stability problems, I'm going to be submitting 24 hour logs to ASUS routinely in the hope that I catch anything that crops up.
That was 14 days ago. Since then, I've been slowly regaining speed and now I'm back on fastpath!
As far as I'm know I'm the only person here on an FTTC connection who has got put on interleaved and then put back on fastpath?
Since now seems like the perfect time to watch for more stability problems, I'm going to be submitting 24 hour logs to ASUS routinely in the hope that I catch anything that crops up.
Last edited:
So you're saying that the suggestion of reducing MTU to 1452 seems to have cleared your problems? I find that interesting. Could something in the modem be struggling to handle packets with a higher MTU, sounds unlikely but I'll try anything at this point.
Not necessarily, but I figure the only variables here are my line, the firmware I'm on and the MTU tweak. My line I can't really account for, the firmware other people are still having problems with, so....?
Okay i have finally after months decided to retry it 
One thing i read that i just thought i would go more in depth with is the mtu this http://www.dslreports.com/faq/5793 is a good guide to finding out the perfect mtu for yourself (mine was 1452 which is quite funny) and i do wonder if that is somthing that is getting messed up with the router as the default is set to max 1492 so it seems it is not calculating it which could mean its creating error's that way. ( i have had no crc errors apprantly )
So far the biggest thing i have noticed is they still have not changed the dsl setting page to not show pointless information or disable automatically settings which would not be needed on adsl or vdsl.
One thing i read that i just thought i would go more in depth with is the mtu this http://www.dslreports.com/faq/5793 is a good guide to finding out the perfect mtu for yourself (mine was 1452 which is quite funny) and i do wonder if that is somthing that is getting messed up with the router as the default is set to max 1492 so it seems it is not calculating it which could mean its creating error's that way. ( i have had no crc errors apprantly
)So far the biggest thing i have noticed is they still have not changed the dsl setting page to not show pointless information or disable automatically settings which would not be needed on adsl or vdsl.
Last edited:
That would be great if that sorts out many of the issues and a simple change suggested by bitsandbobs. Looking forward to hearing the updates in due course.
I gather the standard setting of the MTU on the OR modem is 1452 also? (I seem to remember reading it but can't find it now)
I gather the standard setting of the MTU on the OR modem is 1452 also? (I seem to remember reading it but can't find it now)
For reference, using OR HG612 modem (and a DSL-N66U in Ethernet WAN mode [with settings MTU=1492, MSS=0])
http://www.speedguide.net/analyzer.php tells me:
MTU = 1492
MTU is optimized for PPoE DSL broadband. If not, consider raising MTU to 1500 for optimal throughput.
MSS = 1452
MSS is optimized for PPPoE DSL broadband. If not, consider raising your MTU value.