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

Login with username, password and session length
Advanced search  

News:

Pages: 1 2 3 [4] 5

Author Topic: Fastest ever downstream performance  (Read 6877 times)

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5284
Re: Fastest ever downstream performance
« Reply #45 on: February 02, 2017, 09:32:42 PM »

Weaver at least its temporary on adsl :) on vdsl crosstalk can be permanent knock on affect of snrm. :p
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

ejs

  • Kitizen
  • ****
  • Posts: 1639
Re: Fastest ever downstream performance
« Reply #46 on: February 03, 2017, 01:37:18 PM »

And aesmith will be (very slightly) less vulnerable to this badness than I am, because I may have some 1-bit tones on day zero, whereas he, being G.992.1 iirc, will have a minimum of 2, so less close to zero.

I don't think that makes any difference. If an ADSL1 2-bit tone no longer has sufficient SNR, it gets bitswapped to zero, same as when an ADSL2 1-bit tone no longer has sufficient SNR.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 1639
Re: Fastest ever downstream performance
« Reply #47 on: February 03, 2017, 01:40:27 PM »

Weaver at least its temporary on adsl :) on vdsl crosstalk can be permanent knock on affect of snrm. :p

My ADSL2 line seems to be suffering from about 2dB SNRM worth of crosstalk, which has been pretty much permanent apart from a few blips consistent with a modem being rebooted.
Logged

aesmith

  • Reg Member
  • ***
  • Posts: 699
Re: Fastest ever downstream performance
« Reply #48 on: February 04, 2017, 08:57:12 AM »

Out of interest how do you know it's crosstalk, as opposed to external interference or other factors?
Logged

ejs

  • Kitizen
  • ****
  • Posts: 1639
Re: Fastest ever downstream performance
« Reply #49 on: February 04, 2017, 09:53:52 AM »

I don't really know, but it appears consistent with a noise source of constant strength that's on almost continuously, apart from a few upward spikes of SNRM which are consistent with a modem re-connecting or rebooting. Occasionally it's been off for half an hour or so. The SNR per tone graph doesn't show any new interference on any particular tones, just a general reduction of SNR across the whole range.

I might have spotted a previously unseen BTHub3 from scanning the wifi at the time, but this isn't terribly conclusive, and I don't seem to have made any note of the exact wireless SSID.

It started on 22 July 2016, 10 January 2017 was the most recent time I've seen the SNRM spike upwards.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4746
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Fastest ever downstream performance
« Reply #50 on: December 25, 2017, 03:38:12 AM »

A new level of madness recently, 8.11 Mbps downstream on 2017-12-14 and 1.54 Mbps upstream on 2017-12-17. Those are both speedof.me test figures, using the London “CoreIx” server, which is the server that gives the highest downstream figures for me.

Perhaps due to snow lying on those dates. The snow has gone now and performance figures decreased vastly and downstream sync rates reduced slightly, needed in order to maintain stability as actual d/s SNRMs we're far too low (<1dB) meaning observed packet loss occasionally. I'm assuming that the snow is correlated. The performance figures at the start of the monthndid not hit that extreme high level. possibly there was no snow at the beginning of december, unfortunately I do not remember.

Perhaps snow means isolation from distant RF noise sources? And perhaps it acts to change the electromagnetic environment around the bundle, producing some kind of frequency response shaping. (No idea what I'm talking about, Theoretical Physics first degree fails me.) If the latter is true it might be that that counts as a noise filter in the crosstalk too, blocking crosstalk from disturbers on short lines who can use the higher tones. Both could be true.
Logged

jelv

  • Helpful
  • Reg Member
  • *
  • Posts: 808
Re: Fastest ever downstream performance
« Reply #51 on: December 25, 2017, 10:48:39 AM »

I know when temperatures get really low (around -270oC) strange effects kick in and materials become super conductors.

It's not that cold in Skye is it?  :P
Logged
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Rick Cook, The Wizardry Compiled

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 22252
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Fastest ever downstream performance
« Reply #52 on: December 25, 2017, 05:14:44 PM »

A new level of madness recently, 8.11 Mbps downstream on 2017-12-14 and 1.54 Mbps upstream on 2017-12-17.

That certainly exceeds the capabilities of my circuit.  :o

Quote
Perhaps due to snow lying on those dates.

Without any other evidence, i.e. other residents in Heasta having gone away and switched off their equipment, I can accept that the snow was acting in a beneficial way.

Quote
Perhaps snow means isolation from distant RF noise sources?

I thought we had previously agreed that your isolated location was already playing its part in ensuring you have minimal RF ingress?
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Weaver

  • Kitizen
  • ****
  • Posts: 4746
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Fastest ever downstream performance
« Reply #53 on: December 26, 2017, 06:30:49 AM »

@Burakkucat - Indeed, I do think my isolated location and first-in-the-village situation should help with my clean low noise environment. I was thinking of things like radio stations, when I used the term "distant".

The amazing high value was only sustained for a couple of days. But on the 14th, many tests were done and all gave spectacularly high d/s or u/s throughput figures. Comparing the 14th with the 12th Dec, downstream IP throughout went up by ~400k as measured repeatedly using two completely different speed testers. So it was not just a glitch in speedof.me.

I took half a dozen measurements in each case, recorded all the numbers, and took the arithmetic mean and the max. (I would have thought that geometric means would be more sensible, but I actually want the bias from the high values.) I'm much more interested in the max as I believe that is reliable, because alien local or remote competing traffic or slowness within the remote end test server itself can reduce the figures, but external disturbances can't improve results. The very lowest outlier results, if any, in each group were discarded, assumed to be a failure due to the network not being quiet. I checked for alien traffic going through the router if any bad results were consistently seen.
« Last Edit: December 26, 2017, 06:55:54 AM by Weaver »
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4746
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Fastest ever downstream performance
« Reply #54 on: December 26, 2017, 06:44:20 AM »


Since I have three modems on the go, one of them dropping the link (for ~80-120 s typically) isn't a problem at all because the AA routers and my Firebrick at my end switch the load over to the other working links. I never even notice one dropping and resynching, apart from the notification tweets and SMS messages that I get from AA. I am fine with a few drops themselves per week because of my chosen low downstream target SNRM of <3dB. However periods of packet loss because the SNRM has dropped way too low aren't good.

There doesn't seem to be a “give up and resync if SNRM goes below x" option as far as I can see. I wonder if anyone has seen such a thing with other modems? Modem designers perhaps wouldn't want this, as they might regard it as reducing stability / reliability because the modem wouldn't “hang on in there” bravely regardless, something many customers might really want badly. But in my case my needs are different, I don't care much and if there is going to be packet loss when the SNRM is low then I just want to give up before that. (Reminds me a bit of modern intelligent magnetic hard disks with CPUs in them and internal bad sector hiding software tricks, which I imagine you do not want if in a RAID array.)

I really do want it all, bitswap [of course!], monitored tones please and definitely SRA from BT's MSAN/DSLAMs now I've got ADSL2, seeing the modem says it supports SRA.

I would be a bit surprised if these devices fail to do bitswap when they have gone to all the trouble of (supposedly) writing the code for SRA. I mean this implies that they aren't quite so mean and stingy with their software development efforts, so not bothering to get bitswap done wouldn't seem likely.

I wonder if they simply haven't done bitswap correctly?
« Last Edit: December 26, 2017, 06:55:01 AM by Weaver »
Logged

ejs

  • Kitizen
  • ****
  • Posts: 1639
Re: Fastest ever downstream performance
« Reply #55 on: December 26, 2017, 06:52:34 AM »

I think most DSL modems have always had an option to drop the connection once the SNRM hits a minimum value, but the minimum value always must be specified by the DSLAM, it's usually referred to as something like "CO min margin". It's one of those features that always been there, but not widely used.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 22252
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Fastest ever downstream performance
« Reply #56 on: December 26, 2017, 03:10:16 PM »

At the moment, I can only come up with one suggestion . . .

Perhaps you could install a time-switch for each modem and once every 24 hours, during a defined time window, power-cycle each device in turn.  :-\
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5284
Re: Fastest ever downstream performance
« Reply #57 on: December 26, 2017, 05:30:42 PM »

weaver my suggestion is to make sure you sync at adsl2 instead of adsl2+, adsl2+ will likely be slower on your lines.
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

ejs

  • Kitizen
  • ****
  • Posts: 1639
Re: Fastest ever downstream performance
« Reply #58 on: December 26, 2017, 06:32:13 PM »

I'm pretty sure @Weaver has already done that.

I think the ADSL2/2+ setting makes no difference on the newer exchange equipment anyway, I think it's actually that the earliest BT ADSL2+ exchange hardware does ADSL2+ poorly, especially on long lines, rather than anything about the ADSL2+ specification itself.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4746
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Fastest ever downstream performance
« Reply #59 on: December 27, 2017, 02:59:48 AM »

ejs - tis a 2015 Msan. Modems are indeed themselves set to ADSL2-only rather than "auto"-mode, thanks to Burakkucat's tip way back when.

@burakkucat - have thought of the switch thing, started looking round for suitable hardware.

I looked into the possibilities of remote-contrling a switch. For some reason, did not think about just a switch with a fixed time setting, not remote controlled.

AA now have a facility where you can get info and issue commands using a machine-to-machine http-based protocol, called CHAOS. I looked into that, no joy currently - what I need isn't yet documented.

I can remotely force a resynch now by  misusing manual commands to AA's control / admin / info web server 'clueless'. Such a dirty trick saves me from needing to obtain help manually power-cycling modems in the office. I haven't yet worked out how to automate that though. It would be very messy before they add explicit support for such in the CHAOS protocol.
Logged
Pages: 1 2 3 [4] 5
 

anything