Print

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

[Oakserver]

Hi,

I've come across a phenomenom that I have not seen documented elsewhere. Its not really of any particular importance but I found it interesting.

I sync around 74/20 with SNR of 15 up and 8 down. I have a Draytek 2860.

I've noticed that I get CRC / ES Errors on the upstream with g.inp enabled on the upstream only of around 80 ES per day. Nothing too much to worry about.

DLM recently applied g.inp to the downstream (which occurred due to many retrains during a trial of a faulty Draytek firmware) and I found that I had no ES errors at all for around 10 days until DLM removed the g.inp again on the downstream.  At that point the upstream errors started occurring again.

So in summary, it seems that applying g.inp on both up and downstream can resolve persistent CRC errors that only occur on the upstream.

[ejs]

Are you sure you're getting things the right way around?

I don't think you usually get g.inp enabled for only the upstream.

[burakkucat]

I don't think you usually get g.inp enabled for only the upstream.

I would agree. As I find the Draytek statistics are somewhat difficult to fully comprehend, I suspect that the DS & US values have been inadvertantly interchanged.

[j0hn]

I agree that it appears the DrayTek is mixing things up here. What you describe sounds exactly as should happen.

G.INP is enabled by default on downstream only. It's always on, DLM never turns it off*.
You get a moderate amount of upstream ES. Something caused DLM to apply G.INP to the upstream for 10 days during which time upstream ES were gone. After the 10 days G.INP was removed from the upstream and the moderate amount of ES has returned.

This is exactly as DLM is designed to act. The DrayTek sound like it's mixing downstream/upstream.

Could you perhaps post your stats for us to see, or attach am image of the stats page.

It also sounds like your line may be banded/capped at 74Mb.

* A DLM reset is the only time downstream G.INP is removed. Switching to a modem that doesn't support G.INP would have the same outcome.

[Oakserver]

I agree that it appears the DrayTek is mixing things up here. What you describe sounds exactly as should happen.

G.INP is enabled by default on downstream only. It's always on, DLM never turns it off*.
You get a moderate amount of upstream ES. Something caused DLM to apply G.INP to the upstream for 10 days during which time upstream ES were gone. After the 10 days G.INP was removed from the upstream and the moderate amount of ES has returned.

This is exactly as DLM is designed to act. The DrayTek sound like it's mixing downstream/upstream.

Could you perhaps post your stats for us to see, or attach am image of the stats page.

It also sounds like your line may be banded/capped at 74Mb.

* A DLM reset is the only time downstream G.INP is removed. Switching to a modem that doesn't support G.INP would have the same outcome.

Perhaps I am misreading then. Here are my current stats with one sided G.INP (ReTx)

[ejs]

I suspect it's the Draytek misprinting them rather than you misreading them.

In the Lantiq DSL source code, the direction parameter for certain commands uses near end = 0 and far end = 1. For other commands, the direction parameter is upstream = 0 and downstream = 1. The LineFeatureStatusGet command, which is used to retrieve the status of Trellis, Bitswap, ReTx, uses upstream and downstream rather than near end and far end. Unfortunately this means that in some places 0 specifies downstream (near end), and in other places 0 specifies upstream. Trellis, Bitswap and ReTx should be listed under the Downstream and Upstream headings, not Near End and Far End.

The stats also look banded at 67Mb downstream.

[j0hn]

ejs has explained the reasoning behind it, the DrayTek is indeed mixing upstream/downstream for some of the stats. Retx is definitely on for the downstream. It's only enabled on upstream after a period of high errors.

I would be very wary about performing any unnecessary resyncs as it has caused the line to be banded/capped at 67Mb. It can take a long time with the line being stable for DLM to remove banding.

[Oakserver]

Something caused DLM to apply G.INP to the upstream for 10 days during which time upstream ES were gone.

Yes, I chose the wrong variant of the Draytek 2860 firmware when I upgraded causing the router to cycle through retaining many times. 

It caused my downstream sync speed to fall from 74 to 60 with g.inp enabled both up and down.

I'm now working my way back up to 75.

It took took 10 days for the speed to return from 60000 to 67000 and a further 6 or 7 days for g.inp to be removed from the upstream (which apparently the 2860 reports as downstream). Then the ES returned.

Still within green range though so hopefully my sync speed will return to 74 in another 10 days (with any luck!)

Thanks for your explanations.