Print

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

[niemand]

Yes but when maintaining a large file download of constant data rate for duration of a few minutes or more, if interference were occurring, I’d expect to see a corresponding dip in SNRM, for roughly the duration of the download.   

It’s a while since I looked at DSL protocols but isn’t the SNRM that is shown by the router calculated by an algorithm comparing current BER with some reference BER (that reference being regarded as zero margin)?   If so, it’s hard to see how BER could increase without SNRM dropping.

I can't say I've seen comments here about how SNRM held up, though if it were only certain frequencies being impacted you're at the mercy of how it's being calculated.

You mentioned flow control earlier. A properly working TCP connection should not show abrupt drops in throughput once ramped up given modern TCP stacks.

The throughput should show a tiny sawtooth effect that is imperceptible. A big drop indicates congestion control kicking in - a different issue and one indicative of a possible fault.

Packet loss would trigger congestion control, not flow control.

[cbdeakin]

Since the frequencies used overlap, how exactly do VDSL2 and powerline frequencies co-exist without dropping connections entirely? Do they operate on different channels??

[j0hn]

All your neighbours with FTTC/VDSL2 are also using those exact same frequencies.
As are radio stations across the country.
They all simply create additional noise.

I used 2 different types of Homeplugs for about a year with a Youview box upstairs while running DSLStats at the same time.
They only ever had an effect when data was being transmitted.
They had no impact on SNRM.
They sent FEC numbers through the roof.
They caused no disconnections and no ES.

My brother had a set of TP-Link AV1000's and had a very different experience.
They frequently caused his line to drop sync, resulting in banding.
When in use they sent ES numbers through the roof.

I've seen so many cases of these being an issue with VDSL that I strongly recommend people either use wi-fi extenders or run proper Ethernet wiring around the home.

[sevenlayermuddle]

I can't say I've seen comments here about how SNRM held up, though if it were only certain frequencies being impacted you're at the mercy of how it's being calculated.

You mentioned flow control earlier. A properly working TCP connection should not show abrupt drops in throughput once ramped up given modern TCP stacks.

The throughput should show a tiny sawtooth effect that is imperceptible. A big drop indicates congestion control kicking in - a different issue and one indicative of a possible fault.

Packet loss would trigger congestion control, not flow control.

Congestion control is about avoiding flooding the network with data it won’t be able to handle, not necessarioy related to DSL error rates.

Flow control occurs when the receiver is unable to accept the data at the rate it is being presented.   If for example, the receiver simply unplugs a local ethernet cable, then the incoming data will be buffered up to a point but when the buffers are full, flow control will kick in to tell the sender to stop transmitting, and the connection will fall silent.

Error recovery is a different process to either of these, but can also cause a glitch.  That’s the scenario that would be attributable to home plug interference.

@cbdeakin, I think you said you are running this test over WiFi.   Have you tried to negotiate an agreeable time with other occupants to temporarily disconnect all home plugs, and run the same test in those circumstances?

[g3uiss]

For me simple answer. Never had a problem. However my VDSL frequencies are very limited due AL cable. Only get D1 and limited U2.

[jelv]

I've just done another 1GB download monitoring errors - and there was indeed a significant increase:

CRC per sample shot up from 0 to 1
FEC errors rocketed up to 8 per minute

N.B. DSLstats and the download both running on the same PC over the tplink 600Mbps homeplugs.

[cbdeakin]

According to this post on Reddit:

from r/HomeNetworking

https://www.reddit.com/r/HomeNetworking/comments/9wjm2v/vdsl_settings_on_devolo_powerline_adapters/

Devolo dLAN 1200 Powerline adapters have a few VDSL  coexistence modes, such as "VDSL Profile 17a", "VSDL Profile 35b" and "SISO mode".

I'm thinking that the 'VDSL Profile 17a' option would probably prevent a powerline adapter from using VDSL2 profile 17a spectrum (~0 - 17.6MHz), used in the UK.

Has anyone tried these settings, found in the Develo Cockpit software? Did it help with your VDSL throughput / performance?

Also, which Develo Powerline adapter models have these option available? Or are you aware of an alternative powerline adapter with a similar feature?

[niemand]

Flow control occurs when the receiver is unable to accept the data at the rate it is being presented.   If for example, the receiver simply unplugs a local ethernet cable, then the incoming data will be buffered up to a point but when the buffers are full, flow control will kick in to tell the sender to stop transmitting, and the connection will fall silent.

Nope. In TCP, which was the context, flow control is end to end. Issues with intermediate network nodes would trigger congestion control.

[sevenlayermuddle]

Nope. In TCP, which was the context, flow control is end to end. Issues with intermediate network nodes would trigger congestion control.

In a word, ‘nonsense’.

Edit, apols, not nonsense.  It was late.

[niemand]

In a word, ‘nonsense’.

You're confusing Ethernet flow control, pause frames under congestion conditions, with the layer 4 sliding window flow control of TCP, which has to be done between endpoints of the flow as they're the ones involved in window exchange.

Entirely different things, same name.

[sevenlayermuddle]

Apols, in the case of pulling an ethernet cable, it is congestion control that kicks in.   My  example of pulling an ethernet cable was the wrong example.   

[niemand]

Phew. Given I work with this stuff on a daily basis I was worried for a minute there. Handing my notice in out of shame over Christmas didn't appeal! 

[sevenlayermuddle]

Embarrassing thing is, I wrote protocol stacks for a living once upon a time.  I think mine worked alright at the time, honest.

[cbdeakin]

According to this post on Reddit:

from r/HomeNetworking

https://www.reddit.com/r/HomeNetworking/comments/9wjm2v/vdsl_settings_on_devolo_powerline_adapters/

Devolo dLAN 1200 Powerline adapters have a few VDSL  coexistence modes, such as "VDSL Profile 17a", "VSDL Profile 35b" and "SISO mode".

I'm thinking that the 'VDSL Profile 17a' option would probably prevent a powerline adapter from using VDSL2 profile 17a spectrum (~0 - 17.6MHz), used in the UK.

Has anyone tried these settings, found in the Develo Cockpit software? Did it help with your VDSL throughput / performance?

Also, which Develo Powerline adapter models have these option available? Or are you aware of an alternative powerline adapter with a similar feature?

Any thoughts about this? Is this likely to fix (avoid) interference caused by powerlines to VDSL?

[j0hn]

It might help.

Surely cheaper to hard wire with cat6 or use quality WiFi extenders than buying expensive Devolo Powerline adapters.