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:

Pages: [1] 2

Author Topic: Summer - Winter  (Read 6597 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Summer - Winter
« on: May 20, 2019, 08:33:40 AM »

I had an idea. I have lost a lot of downstream speed, about 10%. Looking back, if I remember correctly, this could be true for earlier years when early summer downstream sync rates are compared with midwinter. Now the question is, is it due to the length of the day, or temperature, or dry-wet weather? Anyway, seasonal, just based on day length or otherwise environmental or neither.

It might be that I could find records of my own or in kitz postings to give me a comparison basis, but I can’t go back far because I changed modem models roughly 12 months ago, I forget when.

Would anyone else be interested in doing such a comparison in the future though ? Say we save comprehensive data now, say, on a dry day. Or better still on a wet day too. Then we do the same in winter and compare. We might be able to find some generalities - bit loadings, noise levels.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Summer - Winter
« Reply #1 on: May 20, 2019, 06:48:05 PM »

I now have over 5 years of my own adsl stats data stored. Last time something like this was mentioned, I produced a graph showing the attenuation and speed over a whole year. Attenuation increases as temperature rises, reducing the speed.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Summer - Winter
« Reply #2 on: May 20, 2019, 07:28:14 PM »

Attenuation increases as temperature rises, reducing the speed.

I do not regularly monitor the statistics for my own circuit but, from observations made over the last 12 years, I agree with the above statement.
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: Summer - Winter
« Reply #3 on: May 21, 2019, 08:11:18 AM »

Ah. Makes a lot of sense. And I do have a long length of copper. Temperature is about 7% higher here in summer than in winter, occasionally even more, even 9%.

I shall try to find ejs’ Previous thread. Sincere apol as usual for repeatedly asking same questions. The reason I asked now is because my deterioration seemed large and sudden. And temperature is probably the answer. There was snow in April and that would have cancelled out any possible effect associated with the rapidly shortening nights. Of course, so far north the difference in the length of the day is greater. But there are definitely kitizens further north than me.

Thanks for reminding me about the existence of the earlier thread.

[Moderator edited to merge three "tweet"-like posts into one.]
« Last Edit: May 21, 2019, 03:05:18 PM by burakkucat »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Summer - Winter
« Reply #4 on: July 23, 2019, 11:40:11 AM »

Recently I have lost a lot of downstream speed - down from 1.55 Mbps to 1.36 Mbps combined total TCP payload (I think) - anyway, wherever speedtest2.aa.net.uk and the testmy.net upload test report.

This has had a very noticeable bad effect on the quality of FaceTime video calls. Idiot FaceTime goes out to the internet and back (I am pretty certain) even when all it needs to do is cross the 300 Mbps WLAN. In fact the way I have the WLAN set up, I default to being on a different SSID than my wife, so if I FaceTime call her in the house then if FaceTime were only sane there would be a full 300Mbps allocation for each of us and we would not be experiencing contention between the two of us. (However, I presume that each of us would have to divide up the bandwidth between our own tx and rx, as I am telling myself that this is not a full duplex WLAN medium?) But incredibly I am having to make do with half of 1.3 Mbps as the FaceTime bottleneck. And there is the cost of all those bytes received and transmitted, cost incurred for no reason.

But in addition to the upstream loss there has been a loss of very very roughly 1 Mbps IPv4 TCP payload downstream, down from an earlier 10.6 Mbps to around 9.69 Mbps. Measurement s seem to be all over the place on this. The actual downstream sync rates now report we’re captured at around 2.2 - 3.0 dB downstream SNRM and upstream at 6 dB upstream SNRM. Sync rates are as follows:

Live sync rates:
  #1: down 2737 kbps, up 522 kbps
  #2: down 2716 kbps, up 505 kbps
  #3: down 2788 kbps, up 412 kbps
  #4: down 2883 kbps, up 499 kbps

For upstream, the egress rate limiters are set to IP PDU rates of
    upstream_sync * 0.884434 * 0.965

where :

* 0.884434 =‘protocol efficiency factor’ is my opinion of the protocol bloat - expansion in the number of bytes set due to the wasteful extra junk added by ATM and other protocol layers below IP (exclusive), ie PPP inclusive and below based on a 1500 byte packet being sent. This is the most optimistic least bad case. The waste will be far far worse in some scenarios, eg for short packets, and for an ATM AAL5 payload of a length that does not fit well into a multiple of 48 bytes certain number of ATM cells so leaving empty space in a cell. This should be the fastest theoretical possible rate that you can drive the modems at, expressed as IP PDU rate. This may well be impractical though and could overload the modem, because of considerations missing from my calculation and because in a realistic scenario not all packets will be of the length chosen here (1500 bytes in this case) which was the easiest packet to deal with as efficiency is optimal. If some packets have other lengths then that would mean that the modem would be overloaded and won’t be able to keep up.

and

* 0.965 =‘modem loading factor’ is my choice for the amount of stress put on the modem in the upstream direction, a multiplier which is applied to the sync rate times the protocol effieciency factor to give the IP PDU egress rate . This has been changed. It used to be: 0.70 or 0.75 for the slowest line (line 3), and ~0.95 for all other lines. For reasons unknown it now seems to be that that strategy of ‘low factor for slowest line’ does not give any advantage and in fact that strategy may give slightly worse results, but despite a large number of tests it is difficult to get accurate results as there is always a lot of statistical ‘noise’ in the upstream speed results, even with quite large uploads. So that strategy has now been abandoned and currently all lines use the same modem loading factor (MLF) since experiments show that now equal MLFs is optimal.

As far as I can work out the reason things are now the way they are is to do with the effect of the unequal speeds of the lines on the behaviour of TCP implementations at one end of the other. Because of the misbehaviour of line 3 upstream, which was only 330k u/s sync rate last week


In earlier posts, we were talking about temperature change seasonally. I think this might have to be the answer, conductivity vs temperature or else the state of some joints vs temperature. But regarding the latter, it can’t be dodgy occasional joints as the results are the same across all lines. It seems to me that the apparent frequency-independence of the phenomenon, because the fractional change is the same (bearing in mind the error bars) for upstream and downstream. I haven’t gone through the bits per bin allocations and compared with an old snapshot though, which I should do to check out any ideas of frequency independence.

* Two attached files - zipped up full stats on all modems:

I have attached complete stats for all four modems, see below .zip files simply containing zipped-up plain text taken straight from the modems’ Broadcom CLI raw output.
  • The first one is straight raw command line stuff captured.
  • The ‘Burakkucat’ file is the same stuff, still plain text, but formatted in a way that I hope will prove to be helpful to the Kuro Neko’s tools and save a bit of finger wear, assuming I have got the formatting correct, that is, should my friend want to peruse these stats.

[Moderator edited to remove the size zero files.]
« Last Edit: July 25, 2019, 02:32:51 PM by burakkucat »
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Summer - Winter
« Reply #5 on: July 23, 2019, 04:52:11 PM »

Unfortunately both attachments are of size zero . . .  :(
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: Summer - Winter
« Reply #6 on: July 25, 2019, 12:30:38 PM »

I’ll try again  :-[

I have mended the original post and I have also had a second attempt here. I see one of the attempted attachments this time round shows as size = 0. I’m not sure how to delete the zero-length one.

[Moderator edited to remove a size zero file.]
« Last Edit: July 25, 2019, 02:35:22 PM by burakkucat »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Summer - Winter
« Reply #7 on: July 25, 2019, 04:50:44 PM »

In the attached files, the ‘Burakkucat’ file wasn’t. Burakkucat helped me to discover a bug - there is a textual date at the top of the file which is garbage.

The date-to-formatted-text library routine I used had one of those ‘picture format’, very vaguely printf-like arguments which determined the syntax of the textual date output. It had the format code "yyyy.mm" in it but lower case mm - it now appears - meant ‘minutes’ not ‘months’, and it should have been in upper case. So the date is garbled and has the ‘minutes’ value twice, showing instead of ‘months’, as well as where ‘minutes’ should be.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Summer - Winter
« Reply #8 on: July 25, 2019, 08:28:23 PM »

Looking through the error rates on the various modems, I kept seeing a pattern, where
- recent downstream error counts were not too bad, then (it gave the impression that…)
- before that there had been a really bad patch earlier,
- but the count for the total period was not that much worse so making me think that the bad patch was a one-off, roughly.

The total period covered was as much as 28 days for some of the modems.

I’m not entirely sure why - I wasn’t really thinking about it logically - but I just got the idea that the modems were struggling with the download at times, or had been so. I was always missing the bad period in question. So anyway, I decided to force a retrain on modems 1, 2 and 4. I ordered each to do a reboot.

The fuzzy thinking is that a lot has changed, the temperature has gone through the roof, it is dry now. I was wondering if the modems might be struggling and if so the reason could be because current electrical environment and noise distribution conditions are now too differerent from when the modem initially trained up and did its analysis.

Amazingly this forced retrain worked like magic. The (presumed TCP payload) upstream figure reported by speedtest2.aa.net.uk was 1.53 Mbps, not a crappy 1.25-1.35 Mbps, right back to where it should be. The excellent upstream test offered by testmy.net was 1.43 Mbps instead of ~1.28Mbps. That 1.53 Mbps figure is exactly what it should be; correcting for TCP +/- time stamps and IPv4 or IPv6 gives us a range of IP PDU rates from a TCP SDU rate, and the kind of number we would ideally get for IP PDU rate would be ~1.6Mbps currently, at these IP PDU modem upstream rates = these u/s sync rates × protocol efficiency of 0.884434 × 96.5% current choice of modem loading factor for all lines equally now, not using a different rate for the slowest line any more.

So there is a lot going on here that I just do not understand. The recent rise in temperature should make things worse, but now all that is blown away and we have a huge step change. Here we suddenly find another dimension to the complex issues behind measurement through the mechanism that is bonded TCP payload-based results rather than proper measurements of the lines only, excluding software behaviour and protocol types and implementation specifics. Straight physics is most definitely out. I made measurements earlier today just before the resets and they were not good.

I have all the stats for all modems captured after the miraculous upstream rate recovery if anyone wants to have a look at them.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Summer - Winter
« Reply #9 on: July 25, 2019, 09:29:59 PM »

Looking at the downstream figures after this round of retrains, sync rates have dropped so much that according to my calculations I should have lost a lot of combined IP PDU rate, something like 1.55 Mbps (pred). Actual speed tests for downstream, presumed TCP payload, with the speedtest2.aa.net.uk tester have dropped from say ~10.6 Mbps downstream a few weeks ago, to 9.53 Mbps today, accompanied now by 1.54 Mbps upstream.

Sum of sync rates (which needs correction to be applied obviously) has dropped from 12.742 Mbps in January to 10.960 Mbps now.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Summer - Winter
« Reply #10 on: September 12, 2019, 10:42:09 AM »

Post month-of-hell live sync rates:
  #1: down 2876 kbps, up 525 kbps
  #2: down 2762 kbps, up 512 kbps
  #3: down 2916 kbps, up 419 kbps
  #4: down 2850 kbps, up 496 kbps

Downstream total sync = 11.404 Mbps ; -> 10.086 Mbps IP PDU (assuming 0.884434 protocol efficiency). The downstream TCP payload measured is about 9.9 Mbps

Upstream total sync = 1.952 Mbps; -> 1.728561 Mbps IP PDU (assuming 0.884434 protocol efficiency) @100% modem load factor; 1.668061 Mbps @ 96.5% modem load factor. The upstream TCP throughput given by speed testers is ~1.2-1.3 Mbps, which is really horrible; realistically expecting speed tester upstream = ~1.56Mbps ; which was a real measured speed tester result a few months back, not a prediction.

Speed testers used were both speedtest2.aa.net.uk and test.my/upload ; roughly agreeing.
« Last Edit: September 12, 2019, 10:56:21 AM by Weaver »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Summer - Winter
« Reply #11 on: January 07, 2022, 07:01:14 AM »

The summer-winter thing really is very significant indeed. It seems to be worth about ~10% of download sync rate.


Modems:: Live sync rates:
  #1: downstream 2.902 Mbps, upstream 673 kbps
  #2: downstream 2.946 Mbps, upstream 531 kbps
  #4: downstream 3.082 Mbps, upstream 396 kbps

--

* Estimated combined IP PDU rate totals (*):   
     downstream:  7.503 Mbps ( at 95% MLF ),
          upstream:  1.344 Mbps ( at 95% MLF ).


------------------------------------------------------------------------

(*) Calculated from:
   IP PDU rate = sync rate × protocol efficiency × MLF;
   where :
   *   protocol efficiency = 0.884434 ⇐ (
      ADSL and ATM,
      assumed PDU size = 1500 bytes,
      DSL header overhead = 32 bytes
      );
   *   if MLF = 100% = no rate-limiting, maximum rate;
   *   MLF downstream = 95% (assumed);
   *   MLF upstream      = 95% (assumed)

------------------------------------------------------------------------


Not only are the downstream sync rates really really high, this is achieved with zero or nearly zero errors in any line at almost all times, just now I’m getting a few errors though:



       Summary of DSL links’ wellbeing and error counts
     ────────────────────────


* There are 3 modems in total. They are:     #1, #2 and #4
* The active, contactable modems are:        #1, #2 and #4
* The modems successfully queried are:       #1, #2 and #4


   ────────────────────────────────────────────────
   ***                                                                                     ***
   ***     There is some badness; all is not well !   😦                  ***
   ***                                                                                     ***
   ────────────────────────────────────────────────


--
* ES (less serious): The following link has a few CRC errors, at a lower error rate, where the ES rate < 60 ES / hr (†):
   Link #2 downstream: 'previous' period: ES per hr:   4.00, mean time between errors: 900 s, collection duration: 900 s


─────────────────────────────────────────────────
(†) The duration of the ’latest‘ errored seconds (ES) collection
bucket is variable, with a _maximum_ of 15 mins. The buckets’
start times are always 15 mins apart. A ‘previous’ bucket's
duration is a fixed 15 mins. An ES is a 1 s time period in which one
or more CRC errors are detected. A CRC error is a Reed-Solomon
coding-uncorrectable error, ie. corrupted data is received that
cannot be recovered.
─────────────────────────────────────────────────
                                              ◅ ◅ ◅◊▻ ▻ ▻


« Last Edit: January 07, 2022, 07:05:10 AM by Weaver »
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Summer - Winter
« Reply #12 on: January 07, 2022, 04:18:33 PM »

Your circuits are prime examples of the seasonal temperature effects due to --
  • their length
  • having a significant proportion of that length just lying on the surface of the ground
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: Summer - Winter
« Reply #13 on: January 07, 2022, 07:27:04 PM »

Just to note, it has been really cold and wet recently, with lying snow a couple of days ago for one day only.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Summer - Winter
« Reply #14 on: January 08, 2022, 11:34:21 PM »

I looked it up, and according to https://www.cirris.com/learning-center/general-testing/special-topics/177-temperature-coefficient-of-copper, for copper at ≈290 K, α = 0.00393 K-1 in the following expression:

     R = R0 [ 1 + α ( T - T0 ) ]

The above formula is only a linear approximation. Depending on what you read there is a delta-T power law with quadratic, or cubic or fifth power coefficients and that may depend on temperature too. So, putting in some numbers, for a -20 K change at ≈290K, we have a fractional resistivity change of 1.0786. I think that’s +0.657 dB, for a winter rx power increase due to the -20 K change, but someone had perhaps better sanity check me. Does anyone know what the effect of that on sync rate should be ?

On the mainland, the summer-winter change would be really much higher: maybe something like ~30K or even ~35K rarely, very occasionally even ~45K.
« Last Edit: January 08, 2022, 11:47:51 PM by Weaver »
Logged
Pages: [1] 2
 

anything