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: Stupid question  (Read 892 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 7101
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Stupid question
« Reply #15 on: April 21, 2019, 09:55:20 AM »

Chrys - I always thought that given the tools I could write such a thing, a packet scheduler that would try and arrange the timing of packet transmit operations on different links so that the end of the packet is sent at the right time so that it arrives just very very slightly after some other ‘preceding’ packet that is going out on another link, to make the receiving end happy as it sees the arrival order that it likes. That could possibly be in tension with a requirement to absolutely maximise tx throughput as if there are not enough packets in your overall tx queue then you might have to make a short packet wait when its end arrival time is supposed to be after the end of a long packet on another link. Quite a bit to think about.

You were saying that that system didn’t work properly when saturated - was that just bad design or bugs? Not on account of some legitimate (-ish) reason for it?
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 7101
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Stupid question
« Reply #16 on: April 21, 2019, 10:21:36 AM »

I looked at line 2 in more detail. I did in fact find some slight evidence that it had been struggling. There were some errored seconds on the downstream, and it was the only link with ES. This was in downstream not upstream though. Could the modem have been struggling with receiving the inbound return TCP ACKs associated with this huge test upload? (the 15 min backup of my iPad to the Apple servers) I couldn’t see enough CRCs to explain this.

I resynched modem #2, and the downstream dropped because the d/s sync had been well below the target 3dB (down to 1.7-2.2dB) in the early morning. Resync caused downstream sync rate to go down to a very slow 2.828 Mbps, which is the slowest of the four, and poor historically, aside from faults. It was a very noisy time of day, in the very early morning, and so a time to achieve the slowest speed and max reliability from a resynch operation.

However more importantly for present purposes, the upstream resynched at 509kbps down from a prior 519kbps. So slight evidence of ‘pressure’ on the upstream, but extremely weak surely? More significantly perhaps, the u/s SNRM had been at 5.5dB instead of the 6dB target. Drooping below the u/s target is unusual (for the u/s) with these links. So it is possible that link #2 could be said to be struggling.
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5694
Re: Stupid question
« Reply #17 on: April 21, 2019, 05:33:38 PM »

No idea what caused it, but if I was to speculate the algorithm probably was designed so it wouldnt wait forever to do correct order of packets so if the line was saturated and packets were delayed too long, then it perhaps just reverted to a FIFO policy as a fallback.
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

aesmith

  • Reg Member
  • ***
  • Posts: 831
Re: Stupid question
« Reply #18 on: April 22, 2019, 09:11:53 AM »

I don't know the details of A&A's load sharing mechanism, but just wondered if speed mismatches could be causing out or order packets which could hurt TCP throughput.   I say "could" because in real Internet traffic there are so many drops and other bits of damage to the data stream, that a few issues at the local link often make no difference.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 7101
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Stupid question
« Reply #19 on: April 22, 2019, 03:55:40 PM »

@aesmith In my case it would have to be something going on where the speed effects of packet reordering are different for different links among the four. So the question is why is the reordering situation different?

Links 2 and 4 are both a bit ‘low’, and looking at the sync speeds it is not just as simple as saying that link 2 is slow because it is second below the fastest which is link 1.

Maybe the rule is : fastest = x, slower ones = y (approx), slowest one = z. (Not that that tells you anything that helps really understand.)

Or alternatively, the rule might be that link 4 has the value z because it has a lower loading factor (90% not 95%).
Logged

ejs

  • Kitizen
  • ****
  • Posts: 1936
Re: Stupid question
« Reply #20 on: May 04, 2019, 08:20:16 AM »

Going back to the original question, it occurred to me that @Weaver could try changing the interleaving order from "on" to "auto". The interleaving "on" setting imposes a minimum INP level of 2 for the upstream, which I think tends to cost upstream bandwidth. Set to auto the upstream can operate with lower level of error protection. Unfortunately changing the interleaving order option will probably affect both the upstream and the downstream.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 7101
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Stupid question
« Reply #21 on: May 04, 2019, 06:41:31 PM »

Since the arrival of 21CN hardware at NSBFD, AA now offers me the following with ADSL2 :
    downstream = on | off | medium ; upstream = on | off
and no mention of ‘auto’ at all

I just took a look at the modems’ stats. Here are the INP values.
line  downstream INP  upstream INP
1262.0
2292.0
3262.0
4262.5
Logged
Pages: 1 [2]
 

anything