Very Computer

To paraphrase the question: are there separate streams for uploading
and downloading in the DSL technology?

Thanks for your ideas.

JTR

Shaken

--
Bob
http://www.canadianisp.com - Find an Internet Service Provider anywhere in
Canada
http://www.carricksolutions.com - The largest PPPoE / Broadband Help
Website.

Quote:> If I'm downloading a file using a DSL connection and then start
> uploading anothe file at the same time, will the downloading speed
> decrease?

> To paraphrase the question: are there separate streams for uploading
> and downloading in the DSL technology?

> Thanks for your ideas.

Quote:> If I'm downloading a file using a DSL connection and then start
> uploading anothe file at the same time, will the downloading speed
> decrease?

Quote:> To paraphrase the question: are there separate streams for uploading
> and downloading in the DSL technology?

What you run into, is that TCP implementations do not tend to take into
consideration highly assymetric connections. Downstream tcp traffic
actually uses some upstream bandwidth to maintain connection with the
server on the other end. You receive a chunk of data, then your system
has to tell the server you got it, and please send me more. If this
upstream bandwidth gets slowed for any reason, then the server on the
other end will fall into step, and then the download slows down. A
number of things can cause this. The most common is 'queing' of traffic.
Your system can send a lot faster upstream than the downstream is coming
to you. So you can get a large queue built up, that is more upstream
traffic than downstream. If there is no prioritizing of this stuff, the
upstream traffic that is used to maintain the constant downstream, gets
drowned out to an extent, delaying the return traffic to the server
that is handling the download. Which causes the server to slow down its
transmittals to you. The result is slowed download. Sometimes severely.
But this is a TCP implementation issue, more so than DSL per se.

That's my understanding of the issue, anyway.

--
Hal Burgiss

--
Hal Burgiss

--
Bob
http://www.canadianisp.com - Find an Internet Service Provider anywhere in
Canada
http://www.carricksolutions.com - The largest PPPoE / Broadband Help
Website.

Quote:> Not necessarily. I have no problems getting max on 1.5M/256 ADSL both
> directions simultaneously. I think partly because I am bridged and the
> upstream queue is handled on the ISP's router (presumably more
> intelligently than a home router). And using traffic shaping on Linux to
> prioritize traffic. In fact, I hold the upstream queue on my box, so I
> can control it, and feed it out as needed. Not sure which has more
> impact, but getting max both ways is just not a problem (for me).

> --
> Hal Burgiss

Quote:> Then you do not have an ADSL connection.  Plain and simple.  You may
> have another type of DSL.  The items I mentioned can not be controlled
> that is the nature of ADSL plain and simple.  You need to upload to
> download.  If your upload is already maxed you can not download at a
> high speed.

Brief quote from draft-ietf-pilc-asym-03.txt:

   6.4.1 Per-Flow queuing on the upstream bottleneck link

   When bi-directional traffic exists in a bandwidth asymmetric network
   competing ACK and data traffic in the return path may degrade the
   performance both downstream and down stream flows [KVR98].
   Therefore, it is highly desirable to use a queuing strategy combined
   with a scheduling mechanism at the return path.  

   A simple scheme can be implemented using a per-flow queuing with a
   fair scheduler (e.g. simple round robin service to all flows or
   priority scheduling).   A smaller MTU may be used to mitigate the
   impact (jitter) of bi-directional traffic on low speed links, More
   advanced schemes (e.g. WFQ) may also be used to improve the
   performance of transfers with multiple Acknowledgement streams such
   as p-http.[Seg00].

   On a slow uplink, appreciable jitter may be introduced by sending
   large DATA packets ahead of ACKs. One way of reducing the delay is
   to use transparent link fragmentation to fragment the data packet
   into small pieces before transmission [RFC1990, RFC2686].

   RECOMMENDATION: Per-flow (or per-class) scheduling is widely
   implemented and widely deployed.  The scheme has particular benefits
   for slow links. It is recommended as a mitigation on its own or in
   combination with one of the other techniques outlined here.

[...]

--
Hal Burgiss

--
Doc_Savage

--
Bob
http://www.canadianisp.com - Find an Internet Service Provider anywhere in
Canada
http://www.carricksolutions.com - The largest PPPoE / Broadband Help
Website.

If you have a 100Mbs LAN, how fast does your system transfer traffic?
50M, 60M or whatever. It generates it that fast whether it is a 100M LAN
connection or 128K internet connection. Where does that "excess" go? In
somebody's queue, until it can be sent on its merry way. The router has
a queue (I have no idea how large). Even if the router does not have a
queue, the ISP's router/equipment does. Possibly even multiple queues.
What you want control over is the queue. You want to hold that on an
intelligent device (presumably your system), so you can prioritize the
upstream traffic intelligently and *then* feed it back out. (I don't
have a clue if recent MS can do this or not, but it is very possible.)

--
Hal Burgiss

--
Bob
http://www.canadianisp.com - Find an Internet Service Provider anywhere in
Canada
http://www.carricksolutions.com - The largest PPPoE / Broadband Help
Website.

| In order to download data you need to upload information.  So if you
| saturate your upload then yes your download will go to a crawl.
|

Not according to my simple test here on W2K and a PCI modem.  There is some impact, dropping from a normal 1250+ Kbps down to ~1100 Kbps down as a foreground process.  I wouldn't exactly classify this as a crawl.  The background process was a relatively long FTP upload, at full speed.  The upload process shared the bandwidth between processes equally.  I didn't test download in the background process since I would generally be more interested in the foreground process anyway.

Looking at the help file on foreground-background priority, I find that there is some slight amount of control on foreground-background processes as seen here...  two options...  however, I am not sure as to how this would apply to up/downloading.

~~~~~~~~~~~~

To change the performance of foreground and background programs

  1.. Open System in Control Panel.
  2.. On the Advanced tab, click Performance Options.
  3.. Under Application response, do one of the following:
    a.. Click Applications to assign more processor resources to the foreground program than the background program.
    b.. Click Background services to assign equal amounts of processor resources to all programs.
 Notes

  a.. To open a Control Panel item, click Start, point to Settings, click Control Panel, and then double-click the appropriate icon.
  b.. Choosing the Applications option will result in a smoother, faster response time for your foreground program. If you want a background task, such as a Backup utility, to run faster, choose the Background services option.
  c.. The Applications option allocates short, variable time slices, or quanta, to running programs, while the Background services option assigns long, fixed quanta  
~~~~~~~~~~~~~

I don't know how this is going to display...  hoping for the best.

--
Cheers, Dan
<><><><><>

--
Doc_Savage

Quote:> On Tue, 30 Jul 2002 18:37:56 -0400, "Doc_Savage"

Quote:> In order to download data you need to upload information.  So if you
> saturate your upload then yes your download will go to a crawl.

Back when I had 384K/128K for an agonizing ten months or so (too far
from CO), I could hose the connection with a couple of full speed *
downloads*.  Roommate *ed mightly about it, too.