Print

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

[Ixel]

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).

[simoncraddock]

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.

[ardsar]

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.

[simoncraddock]

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

[Ixel]

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?

[simoncraddock]

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.

[Ixel]

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 - ASUS statistics


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...


After...

[Chrysalis]

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.

[Ixel]

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

[ardsar]

 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?

[Ixel]

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.

[Chrysalis]

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.

[Ixel]

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)

[simoncraddock]

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.

[Ixel]

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.