On Mon, May 14, 2001 at 04:15:12PM -0500, Samuel Meder wrote:
> I'm seeing a similar effect myself. When I use all my available sdsl
> bandwidth (say doing a bulk data transfer), DNS lookups will often
> time out. This is with the default buffer settings/2.4.4.
The problem is that the DNS resolv
> I'm curious about this effect so I've been trying to find information
> on this and while I can find lots of information on the Ethernet
> capture effect there doesn't seem to be anything on the TCP capture
> effect. Could someone point me at an explanation of this effect?
it is exactly the sam
Alan Cox wrote:
> > causes the earlier started one to survive and the later to
> > starve. Running bcp instead of the second (which uses UDP) at
> > 11000 bytes per second caused the utilization in both directions
> > to go up nearly to 100%.
> >
> > Is this a normal TCP stack behaviour?
>
>
On Sun, May 13, 2001 at 10:54:15PM +0200, [EMAIL PROTECTED] wrote:
> On Sun, May 13, 2001 at 09:38:53PM +0200, [EMAIL PROTECTED] wrote:
> > Using 2.2.19 I discovered that running two simultaneous scp's (uses up whole
> > capacity in TCP traffic) on a 115200bps full duplex serial port nullmodem cab
On Sun, May 13, 2001 at 09:38:53PM +0200, [EMAIL PROTECTED] wrote:
> Using 2.2.19 I discovered that running two simultaneous scp's (uses up whole
> capacity in TCP traffic) on a 115200bps full duplex serial port nullmodem cable
> causes the earlier started one to survive and the later to starve. R
> causes the earlier started one to survive and the later to starve. Running bcp
> instead of the second (which uses UDP) at 11000 bytes per second caused the
> utilization in both directions to go up nearly to 100%.
>
> Is this a normal TCP stack behaviour?
Yes. TCP is not fair. Look up 'captur
6 matches
Mail list logo
