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 504 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6978
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Stupid question
« Reply #15 on: Today at 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: 6978
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Stupid question
« Reply #16 on: Today at 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: 5658
Re: Stupid question
« Reply #17 on: Today at 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
Pages: 1 [2]
 

anything