Appologies for an OT post, but I am hoping someone here will
have an answer.
It appears that the select() call as found in RH 7.3 waits too
long before it returns. I come to this conclusion because I
was dropping a large number of UDP packets when I allowed the
select timeout to be > 0. However, if I force the timeout to
be zero in all cases, almost no packets are dropped (but the
packet generator/receiver uses all of the CPU) My traffic pattern
is 10Mbps send + 10Mbps receive on 4 ports (of a DFE-570tx 4-port
NIC, tulip driver), pkt size of 1200 to 1514.
If I understand select() correctly, it should work equally fast
with a timeout of zero or 10 minutes, as long as the file descriptors
are ready to be read from or written to.
I tried various kernels that I am sure have worked in the past,
all with the same results. The only thing I can think of is that
somehow glibc or whatever implements select is wierd in RH 7.3
(I'm installing RH 7.2 now to test that hypothesis.)
One interesting observation that sheds a bit of doubt on blaming
glibc is that when the timeout is > 0 (ie I'm dropping packets),
the ethernet driver is not receiving as many packets as the
sender is sending. It also does not have any substantial amount
of errors of any kind. The ports are connected via a loopback cable,
and all 4 ports exhibit this behaviour. With a timeout of zero though,
the send & receive counters are virtually identical.
If anyone has any ideas or suggestions, I'd love to hear them!
-- Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear- 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 : Tue May 14 2002 - 12:00:17 EST