Pix and ADSL

Discussion in 'Cisco' started by PES, Oct 23, 2004.

  1. PES

    PES Guest

    I have a client who recently started experiencing (2 weeks ago) performance
    issues on an adsl connection facilitated by a Pix 506. The connection is to
    a regional isp utilizing Alltel as a backhaul.

    Alltel and the isp both stated that Alltel had made dslam changes that had
    caused issues for users with Orckit and Fujitsu (orckit) modems. However,
    they claim to have resolved the issues.

    The symptoms are that one file upload will totally dominate the circuit.
    For example, if you start an ftp upload of a 4mb file and start a speed
    test, you may see upload and download speeds dropping into the 10-20kbps
    range. The connection is unusuable. I can reproduce this with download as
    well, but it is less defined (presumably due to bigger download pipe). We
    currently have 768down/384up

    My theory is that they are queuing way to deep. My ping Reponses are
    typically are less than 90ms from another isp with no load. As soon as I
    start pushing a single file up to an ftp server elsewhere, that will jump to
    3000ms.

    I cannot try different queue methods or traffic shaping, due to the absence
    of a router or traffic shape device. I would like to know what on the
    backhaul or isp side could contribute to one session completely dominating
    the connection and making it unusable. Am I off track with my queuing
    theory? Could this simply be reduced bw due to line noise/faulty equipment?
     
    PES, Oct 23, 2004
    #1
    1. Advertising

  2. In article <>,
    PES <NO*SPAMpestewartREMOVE**SUCKS> wrote:
    :I cannot try different queue methods or traffic shaping, due to the absence
    :eek:f a router or traffic shape device. I would like to know what on the
    :backhaul or isp side could contribute to one session completely dominating
    :the connection and making it unusable. Am I off track with my queuing
    :theory? Could this simply be reduced bw due to line noise/faulty equipment?

    They may have now implimented one of the TCP extensions that delays
    ACKs in order to "improve" performance.

    I'm currently getting hit badly by delayed ACKs between a Novell Netware
    system and an SGI IRIX system -- once circumstances are such that
    congestion control is needed (e.g. a TCP packet gets dropped
    for whatever reason), the connection never recovers. Wreks havoc on
    the 55 Gb backups. :( In our case, we see the connection [which
    is simply cross-switch] get driven to 23-24 Kbyte/s.

    Snoop the frames at the TCP level, and see if one end is sending out
    a small burst of frames, and the other end is not ACKing promptly
    (e.g., every second frame as required in the original TCP standards)
    but is instead waiting for a timer to expire before sending back
    a response. For us, the timer is fairly close to 200 ms,
    so we only get about 5 packet-groups per second going through.
    The legal value of the Delayed ACK timeout is up to 1/2 second.
    --
    "No one has the right to destroy another person's belief by
    demanding empirical evidence." -- Ann Landers
     
    Walter Roberson, Oct 23, 2004
    #2
    1. Advertising

  3. PES

    S. Gione Guest

    I have a client that experienced something similar with a 506. I suppose
    it's possible that it could also be applicable to yours.

    When the 506 wasoriginally installed (with v6.1), the interface default
    speed was 10baset. At some point the ISP made some changes which resulted
    in severe performance degradation. Sho int showed a large number of input
    errors.

    When the interface speed was changed to "auto" (with v6.3) the problem went
    away. It turned out to be duplex problems.


    "PES" <NO*SPAMpestewartREMOVE**SUCKS> wrote in message
    news:...
    > I have a client who recently started experiencing (2 weeks ago)

    performance
    > issues on an adsl connection facilitated by a Pix 506. The connection is

    to
    > a regional isp utilizing Alltel as a backhaul.
    >
    > Alltel and the isp both stated that Alltel had made dslam changes that had
    > caused issues for users with Orckit and Fujitsu (orckit) modems. However,
    > they claim to have resolved the issues.
    >
    > The symptoms are that one file upload will totally dominate the circuit.
    > For example, if you start an ftp upload of a 4mb file and start a speed
    > test, you may see upload and download speeds dropping into the 10-20kbps
    > range. The connection is unusuable. I can reproduce this with download as
    > well, but it is less defined (presumably due to bigger download pipe). We
    > currently have 768down/384up
    >
    > My theory is that they are queuing way to deep. My ping Reponses are
    > typically are less than 90ms from another isp with no load. As soon as I
    > start pushing a single file up to an ftp server elsewhere, that will jump

    to
    > 3000ms.
    >
    > I cannot try different queue methods or traffic shaping, due to the

    absence
    > of a router or traffic shape device. I would like to know what on the
    > backhaul or isp side could contribute to one session completely dominating
    > the connection and making it unusable. Am I off track with my queuing
    > theory? Could this simply be reduced bw due to line noise/faulty

    equipment?
    >
    >
     
    S. Gione, Oct 23, 2004
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alex Clarke

    Sweex ADSL Annex-A wired ADSL Router Switch

    Alex Clarke, Oct 15, 2005, in forum: Computer Support
    Replies:
    2
    Views:
    5,773
    Alex Clarke
    Oct 16, 2005
  2. Adam Aglionby

    ADSL router as ATA without ADSL bit?

    Adam Aglionby, Aug 24, 2005, in forum: UK VOIP
    Replies:
    2
    Views:
    1,550
  3. adsl pci modem, and adsl ethernet modem

    , Jan 16, 2005, in forum: Computer Information
    Replies:
    8
    Views:
    723
  4. DarkoN
    Replies:
    0
    Views:
    701
    DarkoN
    Oct 10, 2006
  5. -pau.fr
    Replies:
    0
    Views:
    718
    -pau.fr
    Oct 29, 2006
Loading...

Share This Page