Date: Fri, 19 Jan 2001 10:41:29 +1100 From: Greg Lehey <grog@lemis.com> To: Duncan Barclay <dmlb@dmlb.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Chris Yeoh <cyeoh@linuxcare.com.au>, Anton Blanchard <anton@linuxcare.com> Subject: Re: cvs commit: src/sys/dev/ray if_ray_oldcard.h if_ray.c if_ray Message-ID: <20010119104129.D376@sydney.worldwide.lemis.com> In-Reply-To: <XFMail.010118235212.dmlb@computer.my.domain>; from dmlb@dmlb.org on Thu, Jan 18, 2001 at 11:52:12PM -0000 References: <20010119101506.C376@sydney.worldwide.lemis.com> <XFMail.010118235212.dmlb@computer.my.domain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, 18 January 2001 at 23:52:12 -0000, Duncan Barclay wrote: > > 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). It doesn't seem to happen. > 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. Well, according to Chris and Anton, the card can go faster, about 3 ms under Linux. They're both here at the conference, so if I can grab them we can try it out and at least get an average of FreeBSD and Linux :-) > 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. I skimmed through the code, and got a vague idea of the structure. On any modern machine (mine is a 00 MHz PIII), you'd have to write exceptionally poor code for it to explain this kind of performance. I haven't finished analysing the ktr output, which is why I haven't mentioned it before, but it looked as if we were getting interrupts after about 3ms, but that there were two of them. This might be a misinterpretation, but the times between issuing the commands and the interrupts were definitely in the order of 3-4 ms. > 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. I'm not really sure what use access points are for the Raylinks. They're low end cards which have that advantage for casual home users. I can't think of any good reason to use them in managed mode. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010119104129.D376>