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: Upstream combined performance deficit (again) - run out of ideas  (Read 3137 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Upstream combined performance deficit (again) - run out of ideas
« on: September 10, 2019, 02:57:13 AM »

I’ve tried to think of everything but I don’t understand it. The combined upstream throughput measured by two differed speed testers is at least 250k down compared to what it should be. I’m getting speed tester upstream combined results of 1.25Mbps - 1.3Mbps instead of an earlier 1.56 Mbps (guessing that means TCP payload). I’ve allowed for TCP headers’ overheads in those expectations and in any case this is comparing speed tester results with others from the same tester earlier when things were good.

Some while back, when this happened before, I put it down to packet corruption causing drops and TCP retx. There was evidence of errors in the DSL stats relating to one line, line 3 iirc. Curing the errors fixed the combined performance so that gave support to the theory. So I need to look for bad stats again.

Perhaps I also need to look at the wrong direction. Look for errors in downstream, not in upstream, in case downstream TCP ACKs are getting dropped due to corruption. Perhaps I am stupid to think about looking at upstream?

If not that, then what? Just unfortunate packet recording which upsets TCP ? And doesn’t give a good combination of aggregate speeds?

I can see 54 ES per day on line 1 upstream, 37 on line 2, 11 on line 3 and 7 on line 4  - any of those enough?

*The speed testers were https://speedtest2.aa.net.uk and the upload test at https://testmy.net/upload and both were consistent. The former is better for me in theory because it is close, being at my ISP, whilst the latter is convenient because it allows an upload-only test and the size of the test transmission is controllable.



See also attached PDF of spreadsheet with test results over recent months.
« Last Edit: September 10, 2019, 04:27:23 AM by Weaver »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Upstream combined performance deficit (again) - run out of ideas
« Reply #1 on: November 03, 2019, 01:28:43 AM »

And then one day, suddenly, the long-standing upstream inefficiency disappears; it has been the cause of so much whinging and moaning on my part. After a sizeable improvement to a sustained 1.44 Mbps upstream rate reported by speedtester2.aa.net.uk, the measured upstream rate figure is back to an all-time record high of 1.58 Mbps. The downstream is 10.66 Mbps.

Firebrick current upstream rate limiters' IP PDU tx rates (egress speeds), per-line ::
  #1: 479310 bps
  #2: 435106 bps
  #3: 328496 bps
  #4: 435106 bps
Total combined rate: 1.678018 Mbps

Fractional upstream IP PDU rate speed contributions:
  #1: 28.564%  [█████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
  #2: 25.930%  [████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
  #3: 19.576%  [█████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
  #4: 25.930%  [████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]


Current sync rates down and upstream:
  #1: down 3023 kbps, up 553 kbps
  #2: down 2990 kbps, up 502 kbps
  #3: down 3107 kbps, up 379 kbps
  #4: down 3085 kbps, up 502 kbps
and 98% modem loading factor in use on each line. So total sync rate = 1936 kbps sync


[Recap: last week: For the earlier 1.44 Mbps upstream result a day or so earlier, these were the sync rates at the time:
   #1 560 kbps sync rate and 98% modem loading factor
   #2 532 kbps
   #3 452 kbps
   #4 502 kbps
Total : 2046 kbps sync]


So amazingly, the sum of the sync rates goes down and the true measured speed goes up ! Also the slowest rate is worse and the rates are not more closely spaced. So not one single thing makes sense.



Efficiency compared to the ideal; converting IP PDU rates to TCP payload rates (TCP SDU rates):

The current sum-of-IP-PDUs-rate of 1.678018 Mbps corresponds to an IPv6 TCP with timestamps payload rate of
        ( 1 - ( 60 + 12 ) / 1408 ) * 1.678018 = 1.5922 Mbps TCP payload rate;
with an IP packet length assumed to be 1408 bytes, our current MTU.
Alternatively, assuming no TCP timestamps, a similar calculation
        ( 1 - ( 60 + 0 ) / 1408 ) * 1.678018 = 1.6065 Mbps.

So the measured result of 1.58 Mbps TCP payload rate reported by the speed tester is superb when compared with these ideal calculated figures, very efficient at 99.2% of the 1.5922 Mbps with-timestamps ideal maximum, or 98.35% of the without-timestamps case.
« Last Edit: November 03, 2019, 05:01:05 AM by Weaver »
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Upstream combined performance deficit (again) - run out of ideas
« Reply #2 on: November 03, 2019, 05:43:44 PM »

I can't explain it.  :-\

However all snapshot plots have been created (for each of the four lines) and will soon be on their way to the "Weaving Shed". (b*cat just needs to attach a ZIP archive to an e-mail message.)

In terms of electrical properties, all four lines now appear to be more or less identical. Here follows the calculated anf and cele parameters --

[Snapshot-20191103-0038]$ find -name anf\* -type f | sort | xargs cat
-146 dBm/Hz per sub-carrier
-146 dBm/Hz per sub-carrier
-146 dBm/Hz per sub-carrier
-146 dBm/Hz per sub-carrier
[Snapshot-20191103-0038]$ find -name cele\* -type f | sort | xargs cat
-72.5 dB per sub-carrier
-72.7 dB per sub-carrier
-72.8 dB per sub-carrier
-72.6 dB per sub-carrier
[Snapshot-20191103-0038]$
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

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Upstream combined performance deficit (again) - run out of ideas
« Reply #3 on: November 03, 2019, 11:06:28 PM »

Do we have any idea what might be the source of noise on tones 124/125 ? Have we looked at this before? My notes say "AERONAUTICAL MOBILE aeronautical communication services, NATS" but I have no idea really what that is exactly. Guessing, I talked some while back about Tiree airport, the nearest airport; if airports are even relevant I do not know.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Upstream combined performance deficit (again) - run out of ideas
« Reply #4 on: November 03, 2019, 11:46:50 PM »

I suspect that your "SNR vs frequency peak" thread, from March 25, 2019, is one of the discussions.

I can also remember mentioning aeronautical transmissions and you mentioned Tiree. Then there is the topology of your location to consider . . . if an open view to the SSW, could Northern Ireland be relevant?  :-\  Probably not.
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

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Upstream combined performance deficit (again) - run out of ideas
« Reply #5 on: November 04, 2019, 12:45:56 AM »

I was looking back at old data for SNRM per bin and I saw a mention of a radio transmitter in the North East of Ireland, Cnoc Bhreacáin (as it would appear from an anglicised ’Knockbrackan’) which is a lot further away as Tiree then. I then realised that I had forgotten the Western Isles and disregarded Inverness airport, although in the latter case there are some high mountains in the way on the mainland. Are these distances enough that these points can be disregarded? Freemaptools.com shows me:
  • Tiree airport - 60 miles
  • Cnoc Bhreacáin - ~182 miles
  • Inverness airport 72 miles
  • Benbecula airport - 58 miles
  • Barra airport - 59 miles
  • Stornoway airport - 73 miles
60 miles to Tiree, ~182 to Cnoc Bhreacáin and only 72 miles to; mind you, in the latter case,

In the case of Benbecula, I have both Beinn nan Càrn immediately above Heasta and then the whole of the Skye Cuilfhionn mountain range blocking line of sight. In the case of Stornoway, similarly, I have the high moors to the north west of Heasta and then the mass of the huge Beinn na Cailliche which towers above Broadford.
« Last Edit: November 04, 2019, 10:46:39 AM by Weaver »
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Upstream combined performance deficit (again) - run out of ideas
« Reply #6 on: November 04, 2019, 01:19:23 AM »

Thank you for reminding me of those distances and directions. I don't think any of them will be responsible.

Could a marine service be responsible? A length of rusty barbed-wire, joined with a granny-knot, might form a sufficiently non-linear junction capable of cross-modulating a marine radar with the LW Radio 4 broadcast from either Burghead or Westerglen (which ever is nearer to Skye) and then squawking harmonics.

  :shrug2:
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

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Upstream combined performance deficit (again) - run out of ideas
« Reply #7 on: November 04, 2019, 11:08:29 AM »

Oh I see, intermodulation from some non-linearity could create a sum or difference frequency of two frequencies (and Sums and differences of their harmonics) one being something locally generated and the other being one of the high power long range sources Burakkucat mentioned such as Westerglen which has a long range. Both Westerglen and Burghead are a long way away and have various huge mountain ranges in the way. I don’t know how much lack of line of sight matters, bouncing off the ionosphere ? This is not my area of expertise at all. It seems possible, from the evidence of the data sets, that Westerglen is not audible in Skye and maybe neither is Burghead. But a ship further south with Burakkucat’s rusty wire could halve the distance to Westerglen so act as a power relay via intermod as Burakkucat suggests. If it is a ship, then it may not be permanent, so the question is: are the data sets varying in time ? Looking back, the graphs from 18 months ago are the same as those now. So do we reject ships as they are assumed not to be around permanently?

There are ships that are around in various places around Skye for long periods of time: the Ronja xxx ships, such as Ronja Skye and Ronja Viking - if I have remembered the names correctly, are around the island for long periods of time. These ‘well boats’ have a huge central container full of sea water and salmon. Salmon from the fish farms are pumped into these. At some point, after travelling between the various fish farms, the ships must leave the area to go off and deliver the load of fish. I’m not sure where they go to - to the south of Scotland or to Norway perhaps? I don’t know anything about them. I had to jump on to one of these ships because I was asked to go and diagnose a poorly PC on it. So that’s the only reason I know anything about them at all. Anyway the point is that although they are around for a fairly long period of time, they can’t be constant interference sources.

Way too much speculation and ignorance from me. Need someone who knows about long distance rf propagation and about the rf environment if the geographical area too.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Upstream combined performance deficit (again) - run out of ideas
« Reply #8 on: November 04, 2019, 02:06:23 PM »

Does the Firebrick load balancing send whole packets/frames down each link, or does it send fragments?
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Upstream combined performance deficit (again) - run out of ideas
« Reply #9 on: November 10, 2019, 08:38:38 AM »

I have never seen fragments. I am fairly confident that it just sends whole IP packets down each line in turn, I presume, in a ratio according to the rate of each link. The manual, which is available on the firebrick website, says very little in the matter, with one sentence whose English I do not understand at all, something about the link that is ‘least far ahead’. The firebrick needs needs tx limiter rates to be given for each link, given in the XML config file, and these must control how it apportions the traffic in the correct ratios.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Upstream combined performance deficit (again) - run out of ideas
« Reply #10 on: November 10, 2019, 05:19:24 PM »

I was thinking if it deals with whole packets, maybe a mismatch in speeds or inaccuracy in the algorithm could cause either packet loss or possibly packets being misordered.  Thinking about how it might work, well speculating really, your modems connect to the Firebrick by Ethernet so actual transmission can't actually be at 400kbps or whatever, it can only transmit at 100meg (or 1Gig if it's GE), or not at all.  Network equipment normally deals with this by transmitting for say 125ms then pausing then sending some more, to get the correct average.  I would guess the Firebrick as a short queue for each interface being emptied in this fashion, then a longer queue for the bonded group, which de-queues into the interface queues as space becomes available.  Remembering that if it's packet by packet then it may be offering a 40 byte packet to one interface, then a 1500 byte to the next.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Upstream combined performance deficit (again) - run out of ideas
« Reply #11 on: November 11, 2019, 10:59:50 AM »

That would work, wouldn’t it. New evidence shows that it can work incredibly well sometimes https://forum.kitz.co.uk/index.php/topic,24044.0.html

But at other times it’s efficiency is 21-30% below what I would expect for reasons that I simply cannot fathom. I need to get traffic captures in the two states and then get some help interpreting them because I’m way too fuzzy.

I think I need three hands, one pair to start the traffic capture going, then another to hit ‘upload’ using the testmy.net upload speed test; so I might have to recruit my beloved to help.
« Last Edit: November 11, 2019, 11:06:17 AM by Weaver »
Logged
 

anything