On Thu, 27 Jun 2002, Hurwitz Justin W. wrote:
> On Thu, 27 Jun 2002, Nivedita Singhvi wrote:
>
> [ snip ]
>
> > That said, rx has been slower than sends in most of our testing
> > too.
>
> Is this a documented/explained phemomenon? Or are you and I the only
> people experiencing it? Do we have any idea as to its cause (or is it
> inherent architecturally)?
>
> Cheers,
> --Gus
Well, briefly, completely speculatively, and possibly unhelpfully,
- rx side processing can involve more work (stack length
is simply longer) and so can legitimately take longer.
This is especially true when options and out of order
packets are involved, and TCP fast path processing
on the rx side isnt taken. (I had done a breakdown
of this based on some profiles last year, but dont
have that at the moment)
- rx side reassembly could cause longer delays in the
case of fragmentation
- scheduler comes slightly more into play on the rx
side for TCP, may be since we can put stuff on the backlog
or prequeue q's (waiting for a recvmsg()) (??). this is
again, very off the cuff and based on some profiles
I had seen on send/rx side with rx side scheduler
showing up higher, and without having investigated
further at the time..(long time ago, dont quote me, etc..)
there are possibly many different scenario's here, and
I'm probably missing the most obvious causes...
thanks,
Nivedita
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 30 2002 - 22:00:12 EST