Date: Fri, 19 Jan 2001 19:48:54 +1100 From: Greg Lehey <grog@linuxcare.com> To: Duncan Barclay <dmlb@dmlb.org> 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: <20010119194854.G376@sydney.worldwide.lemis.com> In-Reply-To: <XFMail.010119080558.dmlb@computer.my.domain>; from dmlb@dmlb.org on Fri, Jan 19, 2001 at 08:05:58AM -0000 References: <20010119104129.D376@sydney.worldwide.lemis.com> <XFMail.010119080558.dmlb@computer.my.domain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 19 January 2001 at 8:05:58 -0000, Duncan Barclay wrote: > > 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. They are the same revision. In fact, the three cards we have (two of mine, one of Anton's) had serial numbers within 10 of each other. Unfortunately, so far we haven't been able to get them to interoperate. Chris and I got our cards up and and pining, but we couldn't see each other. Anton has a more recent driver level, and we wanted to see if he and Chris could talk to each other. One of the problems is the amount of time we have here at the conference, so we'll probably put things off until I'm in Canberra in the next couple of weeks. A thing we were discussing yesterday was that the Linux driver doesn't give you control over hopsets. It's not clear which hopset Linux uses, but it's unlikely to be the Australian one. A thing we should investigate, anyway. >>> 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 ;-) I've pressed the power switch, and it's now running at 600 MHz. >> 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? Yes, I had meant to send it to you. I've done it under separate cover. Greg -- Linuxcare. Support for the BSD revolution. Check out my diary at http://echunga.linuxcare.com.au/diary.html 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?20010119194854.G376>