On Wed, Feb 02, 2011 at 04:04:36AM +1100, Bruce Evans wrote: > On Tue, 1 Feb 2011, Slawa Olhovchenkov wrote: > > > I do some more test and build kernel with KTR. > > Now I don't think that inetrrupt overhead on FreeBSD weight: I try > > polling and don't see any difference. > > > > I see many reported by netperf send errors. I found this > > http://docs.freebsd.org/cgi/mid.cgi?E1Aice9-0002by-00. > > > > After insert into src/nettest_bsd.c usleep(1000) if ENOBUF I see 53% > > idle and ./loop 2000000000 "Elapsed 15188006 us" -- this near to linux > > (Elapsed 14107670 us). > > This partly works around the problem that it is impossible to select() > on the ENOBUFS condition in FreeBSD at least, and thus impossible to > write ttcp or nettest correctly. The userland sender either has to > sleep for a while it gets an ENOBUFS error, and thus let the hardware > sender go idle in the interval between the condition becoming clear > and the sleep finishing, or it has to retry immediately and thus consume > 100% CPU getting ENOBUFS errors until the condition clears. I use > HZ = 100. Thus usleep(1000) would actually sleep for an average of 15000 > us, and the system would be idle (doing nothing) for about 10 times > as long as with HZ = 1000. I uses an old version of ttcp which tries > to sleep for 18000 us. This ensures that the the sleep is too long > even with HZ = 1000 (except I changed 1 line in the old ttcp to either > not sleep at all or to try to sleep for only 1000 us). Not sleeping > at all uses 100% CPU, but since I mostly use this for testing the > maximum packet rate I don't care much about that unless the CPU being > used by ttcp interferes with kernel and/or hardware activity. > > Another reply said that Linux blocks on ENOBUFS instead of returning > it. That seems better, provided it doesn't block in the O_NOBLOCK case. > This should involve select() working so that you can avoid the block > even in the !O_NONBLOCK case. Correct versions of ttcp and maybe > nettest can then be written very easily -- at least ttcp would prefer > to just block in sendto().
It's not simple to me, modify kernel code for working select(). Now I see another use for blocking behavior: some application, runnig on the same box, don't handle ENOBUFS. If bad programm exhaust buffers -- this application can fail. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[email protected]"
