Hello!
> > Yes its a SHOULD in RFC1122, but in any normal environment pretty much a
> > must and I know of no stack significantly violating it.
>
> I didn't know there was such a thing as a normal environment :)
Jokes apart, such "normal" environments are rare today.
>From tcpdumps it is clear
Hi!
> > This is NOT what I'm seeing at all.. the kernel load appears to be
> > pegged at 100% (or very close to it), the user space app is getting
> > enough cpu time to read out about 10-20Mbit, and FURTHERMORE the kernel
> > appears to be ACKING ALL the traffic, which I don't understand at all
Alan Cox wrote:
>
> > > TCP _requires_ the remote end ack every 2nd frame regardless of progress.
> >
> > um, I thought the spec says that ACK every 2nd segment is a SHOULD not a
> > MUST?
>
> Yes its a SHOULD in RFC1122, but in any normal environment pretty much a
> must and I know of no stack
> > TCP _requires_ the remote end ack every 2nd frame regardless of progress.
>
> um, I thought the spec says that ACK every 2nd segment is a SHOULD not a
> MUST?
Yes its a SHOULD in RFC1122, but in any normal environment pretty much a
must and I know of no stack significantly violating it.
RF
> and the transmitter is unrestricted, what happens?
> Does it have to do with TCP_FORMAL_WINDOW (eg. automatically reduce window
> size to zero when queue backs up?)
Read RFC1122. Basically your guess is right. The sender sends data, and gets
back acks saying 'window 0'. It will then do exponent
On Wed, Feb 21, 2001 at 10:07:32PM +, Alan Cox wrote:
> > that because the kernel was getting 99% of the cpu, the application was
> > getting very little, and thus the read wasn't happening fast enough, and
>
> Seems reasonable
>
> > This is NOT what I'm seeing at all.. the kernel load appea
Alan Cox wrote:
>
> > that because the kernel was getting 99% of the cpu, the application was
> > getting very little, and thus the read wasn't happening fast enough, and
>
> Seems reasonable
>
> > This is NOT what I'm seeing at all.. the kernel load appears to be
> > pegged at 100% (or very cl
> > > This is NOT what I'm seeing at all.. the kernel load appears to be
> > > pegged at 100% (or very close to it), the user space app is getting
> > > enough cpu time to read out about 10-20Mbit, and FURTHERMORE the kernel
> > > appears to be ACKING ALL the traffic, which I don't understand at a
> I can think of a couple possible solutions. our interface has a HUGE
> amount of hardware buffers, so I can easily simply stop reading for
> a small time if we detect conjestion... can you suggest a nice clean
> mechanism for this?
If you have a lot of buffers you can try one thing to see if it
> that because the kernel was getting 99% of the cpu, the application was
> getting very little, and thus the read wasn't happening fast enough, and
Seems reasonable
> This is NOT what I'm seeing at all.. the kernel load appears to be
> pegged at 100% (or very close to it), the user space app is
On Wed, Feb 21, 2001 at 10:07:32PM +, Alan Cox wrote:
> > that because the kernel was getting 99% of the cpu, the application was
> > getting very little, and thus the read wasn't happening fast enough, and
>
> Seems reasonable
>
> > This is NOT what I'm seeing at all.. the kernel load appea
On Wed, Feb 21, 2001 at 02:00:55PM -0800, Nye Liu wrote:
[snip]
> This is NOT what I'm seeing at all.. the kernel load appears to be
> pegged at 100% (or very close to it), the user space app is getting
> enough cpu time to read out about 10-20Mbit, and FURTHERMORE the kernel
> appears to be ACKIN
On Wed, Feb 21, 2001 at 11:58:23AM +, Alan Cox wrote:
> Dropping packets under load will make tcp do the right thing. You don't need
> complex mathematical models since dropping frames under load is just another
> form of congestion and tcp handles it pretty sanely
Alan: thanks for your respo
I am working on a very high speed packet based interface but we are having
severe problems related to bandwidth vs cpu horsepower. enclosed is a part
of a summary. PLEASE cc responses directly to [EMAIL PROTECTED]
Thanks!!!
--
"Who would be stupid enough to quote a fictitious character?"
14 matches
Mail list logo
