From owner-cvs-all Thu Jan 18 15:52:45 2001 Delivered-To: cvs-all@freebsd.org Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by hub.freebsd.org (Postfix) with ESMTP id D316737B401; Thu, 18 Jan 2001 15:52:17 -0800 (PST) Received: from dmlb.org ([62.253.135.85]) by mta06-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20010118235212.TTBQ285.mta06-svc.ntlworld.com@dmlb.org>; Thu, 18 Jan 2001 23:52:12 +0000 Received: from dmlb by dmlb.org with local (Exim 3.03 #1) id 14JOqi-000CaS-00; Thu, 18 Jan 2001 23:52:12 +0000 Content-Length: 2182 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010119101506.C376@sydney.worldwide.lemis.com> Date: Thu, 18 Jan 2001 23:52:12 -0000 (GMT) From: Duncan Barclay To: Greg Lehey Subject: Re: cvs commit: src/sys/dev/ray if_ray_oldcard.h if_ray.c if_ray Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18-Jan-01 Greg Lehey wrote: ... > I did some ktr hacks in the driver and looked at the time it used. > There were only about 10 remaps per packet, each at 5 µs, but I think > most of that time was the KTR_EXTEND overhead. I don't think that the > remap overhead was the reason for the slow performance. Hmm, as I read the pcic.c code, there is a delay of 50us per call (pcic_memory near the end). I've done a couple of tweaks since this to convert a sequence of writes to the memory on the card to one copy of a struct. This shaves a little more of the ping times but not much (about 0.5ms on a Libretto 50 with a P75 to a Windows 98 box with a P100). I'm not sure whether the driver and card can go much faster. I did some pings from W98 on the Libretto to the same P100 box, and had just over 7ms. I can get the same with the struct patches above and without them I get under 7.5ms on average without them. I would very much appreciate it, if you would have a look at the tx/rx packet handling code and see if I have done anything "slow". On tx, I use a couple of functions to write headers and control blocks. On receive I have to decode the packet type (in switches) and then call various functions to process the different types. All of this must add a little bit of overhead, but surely not the milli-seconds worth that we both see. All I can summize is that the cards themselves are slow or I have got sub-optimal settings on some of the RF timing parameters. On a lighter note, I received some 802.11 compliant cards from Raylink yesterday along with an access point. Once I've got these going (minor firmware issues) I can see if they are faster or not. I was chatting with some 802.11 experts at work and they say that you can get some really bad performance if you pick retries badly - e.g. continual packet collisions. > Greg > -- > Finger grog@lemis.com for PGP public key > See complete headers for address and phone numbers > --- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@dmlb.org | the alcoholics, and the permanently stoned. dmlb@freebsd.org| Steven King To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message