On Tue, Jan 13, 2015 at 4:42 PM, Banerjee, Debabrata
wrote:
> On 1/13/15, 4:36 PM, "Yuchung Cheng" wrote:
>
>>On Tue, Jan 13, 2015 at 1:10 PM, Debabrata Banerjee
>>wrote:
>>>
>>> -/* RFC2861. Reset CWND after idle period longer RTO to "restart
>>>window".
>>> +/* RFC2581 4.1. Reset CWND after id
On Mon, Jul 29, 2013 at 2:02 PM, Artem S. Tashkinov wrote:
> Jul 29, 2013 11:43:00 PM, Eric wrote:
> On Mon, 2013-07-29 at 15:47 +, Artem S. Tashkinov wrote:
>>
>>> A wine developer clearly showed that this option simply doesn't work.
>>>
>>> http://bugs.winehq.org/show_bug.cgi?id=26031#c21
>>
[EMAIL PROTECTED] wrote:
Hi,
I am running a client/server test app over IPOIB in which the client sends
a certain amount of data to the server. When the transmittion ends, the
server prints the bandwidth and how much data it received. I can see that
the server reports it received about 60% that t
On Sep 2, 2005, at 10:33 AM, [EMAIL PROTECTED] wrote:
On Fri, 2 Sep 2005, John Heffner wrote:
Have you tried increasing the size of the receive buffer yet?
Actually, I just did. I changed rmem_max and rmem_default to 4MB and
tcp_rmem to "64k 4MB 4MB". It did seem to help, but I&#
On Sep 2, 2005, at 9:48 AM, Alexey Kuznetsov wrote:
Hello!
If you overflow the socket's memory bound, it ends up calling
tcp_clamp_window(). (I'm not sure this is really the right thing to
do
here before trying to collapse the queue.)
Collapsing is too expensive procedure, it is rather an
On Sep 2, 2005, at 9:52 AM, Alexey Kuznetsov wrote:
Hello!
I experienced the very same problem but with window size going all the
way down to just a few bytes (14 bytes). dump files available upon
requests :)
I do request.
TCP is not allowed to reduce window to a value less than 2*MSS no
m
On Sep 2, 2005, at 10:05 AM, [EMAIL PROTECTED] wrote:
This particular Win2k sender sends _only_ real-time data, it's not
capable of rewinding. So it's always sending small packets, from start
to finish, yet the problem still occurs.
Note that even real-time data can end up generating a stream
On Sep 1, 2005, at 6:53 PM, Ion Badulescu wrote:
A few minutes later it has finally caught up to present time and it
starts receiving smaller packets containing real-time data. The TCP
window is still 16534 at this point.
[tcpdump output removed]
This is where things start going bad. The wi
On Tue, 22 Feb 2005, Stephen Hemminger wrote:
> On Tue, 22 Feb 2005 15:34:42 +0100
> Daniele Lacamera <[EMAIL PROTECTED]> wrote:
>
> > One last note: IMHO we really need a better way to select congestion
> > avoidance scheme between those available, instead of switching each one
> > on and off. I.
> dd says it completes happily even when copying from
> random. 0+100 records in, 0+100 records out. It
This means that dd completed 100 reads, and none of them were of the
requested length (1 bytes).
> takes about thirty seconds to finish on the dual
> gigahertz processor intel box I'm us
On Tue, 9 Jan 2001, Tim Sailer wrote:
> Here is some more data:
>
> Inbound = 99.66 kB/s
> Outbound= 151 kB/s
>
>
>
> ports:/home/ftp# sysctl -a | fgrep net/core
> net/core/optmem_max = 10240
> net/core/message_burst = 50
> net/core/
On Mon, 8 Jan 2001, Tim Sailer wrote:
> > What is the round-trip time on the WAN?
> >
> > Packet loss?
>
> 101 packets transmitted, 101 packets received, 0% packet loss
> round-trip min/avg/max = 109.6/110.3/112.2 ms
Packet loss and RTT can be greatly affected by how much data you're
sending t
12 matches
Mail list logo
