Date: Fri, 19 Jan 2001 08:05:58 -0000 (GMT) From: Duncan Barclay <dmlb@dmlb.org> To: Greg Lehey <grog@lemis.com> Cc: Anton Blanchard <anton@linuxcare.com>, Chris Yeoh <cyeoh@linuxcare.com.au>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/ray if_ray_oldcard.h if_ray.c if_ray Message-ID: <XFMail.010119080558.dmlb@computer.my.domain> In-Reply-To: <20010119104129.D376@sydney.worldwide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18-Jan-01 Greg Lehey wrote: > 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 :-) Great, can you also confirm that the cards are the same firmware revision. If Linux doesn't report it, the raycontrol programme can. There are some real differences in the firmware that might affect performance. >> 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 Hmm, this may be your problem, 0MHz isn't that fast ;-) > 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. But there is nothing I can do in the code to fix this. I will go over some of the card set up parameters again. This sounds like something is slightly wrong in the definition of RF time frames. The unfortunate thing is that the documentation I have is for slightly different firmware and there is some "divined" aspects to the numbers in my driver, the Linux one and the NetBSD one. It would be very easy to have set the slot period too long etc. Can you send me your KTR version so I can carry out similar experiments? >> 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. These cards were designed over five years ago and are actually pretty good for their time compared to some others (remember I design wireless LAN products for a living). Whilst I agree that access points in general are not much use for a home user, in offices/factories a huge number can be deployed to give wide coverage. Up until about three years ago, the market for wireless LAN was all vertical. Take a look at the type of products that Symbol offer, they embed their offerings in factory/shop terminals. > Greg Duncan --- ________________________________________________________________________ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010119080558.dmlb>