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: Summer - Winter  (Read 974 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 7564
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; 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: 1985
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

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 27144
  • 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

  • Addicted Kitizen
  • *****
  • Posts: 7564
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; 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

  • Addicted Kitizen
  • *****
  • Posts: 7564
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; 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

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 27144
  • 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

  • Addicted Kitizen
  • *****
  • Posts: 7564
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; 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

  • Addicted Kitizen
  • *****
  • Posts: 7564
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; 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

  • Addicted Kitizen
  • *****
  • Posts: 7564
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; 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

  • Addicted Kitizen
  • *****
  • Posts: 7564
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; 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

  • Addicted Kitizen
  • *****
  • Posts: 7564
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; 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
 

anything