Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: BEWARE of Cloud computing  (Read 3100 times)

waltergmw

  • Kitizen
  • ****
  • Posts: 2776
BEWARE of Cloud computing
« on: March 16, 2017, 10:49:33 AM »

Hello everybody,

Recently I’ve been helping one hapless Devon resident in a diabolical struggle with BT Retail and (indirectly) Openreach.
I’ve had three gut-wrenching chats with India who just send another valiant BT Openreach phone engineer who then reports no fault found.
Even after extreme pressure via the head office an Openreach broadband engineer told us (correctly according to Wholesale estimates) that the line was working normally.

After January’s attempts it took from 16 February until 9 March to get newcastle.technical.complaints@bt.com to show that the end users “Normally working" 16 Mbps VDSL download service was being frozen by saturating the lousy upstream through Cloud computing with GoogleDrive (or iCloud, DropBox etc. etc.).

Anyone who leaves, say, GoogleDrive to its own devices is asking for trouble and which then requires significant effort to unscramble.
I believe it's well worth investigating what throttling facilities are provided for all Cloud computing facilities if your VDSL Sync is below say 20 Mbps.

It seems that the grossly asymmetric 17a VDSL band plan, when only one upstream and downstream band are in use, is in urgent need of a user-adjustment mechanism.
In this case the stark evidence is that ONLY 151 upload bits were available whilst 5,078 were available for download.

The picture below shows, perhaps unusually, that their upload requirements exceed their download ones on EVERY day.
However I don't think it's unreasonable to assume many users will increase their upload data requirements in the future.

We also took some time to realise that the culprit laptop was being used on neighbours' VDSL services giving the same false (for them) evidence !

Many thanks to those here who helped me to explore the situation.

Kind regards,
Walter
Logged

lee111s

  • Reg Member
  • ***
  • Posts: 139
Re: BEWARE of Cloud computing
« Reply #1 on: March 16, 2017, 10:52:00 AM »

Can they simply set it to backup between the hours of midnight and 8am only?
Logged

tickmike

  • Kitizen
  • ****
  • Posts: 3640
  • Yes Another Penguin !. :)
Re: BEWARE of Cloud computing
« Reply #2 on: March 16, 2017, 11:07:15 AM »


I’ve had three gut-wrenching chats with India

You do not have to talk with India ! :), If you do get through to India ( if you are not sure ask them) just say you what to talk to someone in the UK, goodbye and re-dial and you should get through to a UK/GB agent.
I think one uk agent told me they are trying to do 90% of the calls but at busy times it still get patched through to India.  :(
Logged
I have a set of 6 fixed IP's From  Eclipse  isp.BT ADSL2(G992.3) line>HG612 as a Modem, Bridge, WAN Not Bound to LAN1 or 2 + Also have FTTP (G.984) No One isp Fixed IP >Dual WAN pfSense (Hardware Firewall and routing).> Two WAN's, Ethernet LAN, DMZ LAN, Zyxel GS1100-24 Switch.

Ronski

  • Helpful
  • Kitizen
  • *
  • Posts: 4300
Re: BEWARE of Cloud computing
« Reply #3 on: March 16, 2017, 01:28:58 PM »

I use Crashplan to back up to the cloud,  when I was on adsl it would swamp the upstream,  with the knock on effect that browsing ground to a halt simply because the browser couldn't reliably talk to the server the other end to tell it what pages etc were required.

I simply set a maximum upload limit on the Crashplan software, since moving to fttc I've had no problems even though I only have about 6 Mbps upload.
Logged
Formerly restrained by ECI and ali,  now surfing along at 390/36  ;D

niemand

  • Kitizen
  • ****
  • Posts: 1836
Re: BEWARE of Cloud computing
« Reply #4 on: March 16, 2017, 02:32:56 PM »

Upload speeds on long FTTC lines are wretched due to the band plan in use (B8-11 for the curious).

There's a small band right at the bottom for upload then sadly a a bunch of download before the next upload block. G.fast addresses this.

If you could clarify though, you mention 5,078 I presume bins in use for download. Where did that number come from? BT's FTTC doesn't have that many bins available even if you plug your modem straight into the cabinet.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: BEWARE of Cloud computing
« Reply #5 on: March 16, 2017, 03:49:01 PM »

What router were they using? It sounds like a bufferbloat problem with the router.
Logged

Bowdon

  • Content Team
  • Kitizen
  • *
  • Posts: 2395
Re: BEWARE of Cloud computing
« Reply #6 on: March 16, 2017, 04:09:36 PM »

Sadly with the marketing people pushing cloud storage more people are using the upload side of their connections than ever before.

Does the person need to backup to an internet based cloud, or can't it be backed up to a local storage device like a NAS or usb storage device?

If you do need to backup to an internet based cloud then I second what Ronski suggested in limiting the upload bandwidth for that program.
Logged
BT Full Fibre 500 - Smart Hub 2

waltergmw

  • Kitizen
  • ****
  • Posts: 2776
Re: BEWARE of Cloud computing
« Reply #7 on: March 26, 2017, 04:54:18 PM »

Gentlefolk,

Thank you all for your very valuable replies.
The first point I was trying to highlight is that for those unaware on poorly performing asymmetric services, the lock-up result of heavy upload usage with e.g. cloud computing facilities, is very baffling and believing all difficulties emanate with the network infrastructure was quite definitely wrong in this case.
Isolating the real cause takes super-human effort and dogged persistence particularly with BT Retail call centres.

This person is highly mobile from Yorkshire to London to Taunton so a cloud solution is the most convenient method and the end user is now aware of the pitfalls.

Once the problem was understood it was then easier to discover a solution but care is needed if you select another work-around which just hides but does not cure the problem.

I agree the band plan on difficult lines is seriously skewed towards download when having some user-configurable compromise would be a far better solution.

In this case it was an ECI Cabinet on a noisy line of around 2 km and where, annoyingly, the end user across the road obtains over 22 Mbps download sync speed.
Here are the pbParams and part of the line status from the unlocked Huawei HG612 modem where we expected and observed a very big "hole" in the download bit loading graph.

Max:          Upstream rate = 479 Kbps, Downstream rate = 19548 Kbps
Bearer: 0, Upstream rate = 495 Kbps, Downstream rate = 14999 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)
DS: (67,770)
         VDSL Port Details            Upstream             Downstream
 Attainable Net Data Rate:            479 kbps             19548 kbps
Actual Aggregate Tx Power:             5.2 dBm                5.2 dBm
=====================================================================================
       VDSL Band Status   U0       U1      U2      U3      U4      D1      D2      D3
  Line Attenuation(dB):  8.3     67.4    65.6     N/A     N/A    28.5     N/A     N/A
Signal Attenuation(dB):  8.2      N/A     N/A     N/A     N/A    37.3     N/A     N/A
        SNR Margin(dB):  5.2      N/A     N/A     N/A     N/A     7.4     N/A     N/A
         TX Power(dBm):  5.2      N/A     N/A     N/A     N/A    10.7     N/A     N/A

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:   0
Last initialization procedure status: 0
Max:       Upstream rate = 488 Kbps, Downstream rate = 19548 Kbps
Bearer: 0, Upstream rate = 495 Kbps, Downstream rate = 14999 Kbps

Link Power State:   L0
Mode:         VDSL2 Annex B
VDSL2 Profile:      Profile 17a
TPS-TC:         PTM Mode(0x0)
Trellis:      U:ON /D:ON
Line Status:      No Defect
Training Status:   Showtime
      Down      Up
SNR (dB):    7.4       5.6
Attn(dB):    28.5       0.0
Pwr(dBm):    5.2       5.2
         VDSL2 framing
         Bearer 0
MSGc:      42      33
B:      31      82
M:      1      1
T:      64      4
R:      10      16
S:      0.0677      5.3333
L:      4960      153
D:      481      7
I:      42      102
N:      42      102

Finally I am aware of persisting with voice calls but there is often some value in recording a chat part of which is shown below:-

Raja Bordoloi: Hello. I'm Raja Bordoloi.Thanks for that information, I'll check it and get back to you in a moment.
 Mr FRUSTRATED: Hello Raja Bordoloi
 Raja Bordoloi: Hello Mr FRUSTRATED
 Mr FRUSTRATED: I am Walter Willcox helping (remotely) Mr FRUSTRATED who can't get a reliable broadband connection
 Raja Bordoloi: I am sorry to hear about the issue you are facing with your broadband connection . I will try my best to help you today.
 Raja Bordoloi: Before that Can you just confirm a few bits of information so I can look into your account please?
• Are you the account holder?
• Your full name?
• Your telephone number?
• Your address and postcode?

 Mr FRUSTRATED: No I am NOT the account holder as I have just explained. My name is Walter G M Willcox acting with authority for Mr FRUSTRATED on 01xxxxxxxxx BT A/c No. GBxxxxxxxx at yyyy yyyy yyyy TA4 1AN.
 Raja Bordoloi: Thanks for that information.

Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: BEWARE of Cloud computing
« Reply #8 on: March 26, 2017, 05:11:15 PM »

It would not be possible to have some "some user-configurable compromise" to the band plan, because everyone on the cabinet has to upload and download on the same frequencies, to prevent problems with near-end crosstalk. The transmitted signals, at the end they are transmitted from, are vastly stronger than the received signals at that end. So if one line was using certain frequencies for upstream, but another was using them for downstream, there would be severe crosstalk problems.

Plus there's the need to maintain spectral compatibility with the ADSL2+ services, which is, again, having everyone upload and download on the same frequencies.
Logged

waltergmw

  • Kitizen
  • ****
  • Posts: 2776
Re: BEWARE of Cloud computing
« Reply #9 on: March 26, 2017, 05:38:32 PM »

So perhaps ejs we might ask that the BT Group adjusts the profile for everyone even if only by a small amount.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: BEWARE of Cloud computing
« Reply #10 on: March 26, 2017, 06:30:09 PM »

I suppose the other aspect of this problem, is that even if you did have say 2Mb upstream bandwidth, you would still experience the problem while saturating the upload - the only difference would be that the uploading would take less time, so the duration of the problem would be reduced.

Although, I'd still be interested in checking the information from "xdslcmd info --vendor" because we've seen one or two cases of poor upstream line rates with the rarely seen ECI cabinet firmware version of 0xd086.
Logged

waltergmw

  • Kitizen
  • ****
  • Posts: 2776
Re: BEWARE of Cloud computing
« Reply #11 on: March 26, 2017, 07:02:15 PM »

That will be difficult ejs for logistical reasons but I might be persuade an unfamiliar end user to perform another data dump.

I assume there are no other clues in e.g. stats or status ?
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: BEWARE of Cloud computing
« Reply #12 on: March 26, 2017, 07:52:03 PM »

I don't have any further suggestions, I guess the low upstream speed is mainly due to line length and quality.

I was comparing it with one of npr's stats, with the 0xd086 cabinet firmware, but npr must have a shorter line.
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 4093
Re: BEWARE of Cloud computing
« Reply #13 on: March 27, 2017, 12:04:25 AM »

I know the upstream is the real problem but the stats from that line show that DLM has banded the downstream sync to 15mb. It should sync nearer to 19mb.

Could you ask the user to run the command "xdslcmd info --vendor" and post the results here. As already mentioned we're aware of a specific ECI DSLAM firmware which has particularly poor upstream. The firmware in question is 0xd086. Most users are on 0xb206 which replaced the older 0xb204. I've absolutely no idea why some ECI cabinets use the 0xd086 firmware, but the examples we've seen with it tend to have incredibly low upstream.
Logged
Talktalk FTTP 550/75 - Speedtest - BQM

npr

  • Reg Member
  • ***
  • Posts: 265
Re: BEWARE of Cloud computing
« Reply #14 on: March 29, 2017, 06:22:58 PM »

, but npr must have a shorter line.
950 metres of mostly aluminium, I'm told by BT.
Also Openreach tell me that firmware is the best available for my ECI cabinet  :no:
« Last Edit: March 29, 2017, 06:38:35 PM by npr »
Logged
 

anything