Configuration of Compaq R3000
jkim at niksun.com
Thu Jan 27 13:26:48 PST 2005
On Thursday 27 January 2005 03:21 pm, Kelly Black wrote:
> Dear Jung-uk Kim,
> It works! Thank you! I downloaded it and built the module. I can't
> read Japanese so the readme was not much use. I blindly tried "make
> ; make install" and it put the module in /boot/kernel. Fortunately,
> the comments in the program are pretty good. When I tried "kldload
> acpi_ppc" it loaded the module with no trouble. (I had already
> applied the patchs that you had posted earlier.)
:-) You did it right.
> This time when I ran it the time was down to 95 seconds which is
> faster than my desktop system, a one year old P4, and is much
> faster than CygWin. (Our opteron system runs this program in 81
> seconds.) It was pretty cool to start the process up and a little
> while later hear the fan kick in. There is nothing like instant
> feedback! :-)
So I guess we beat Gentoo big time? ;-)
> The only problem is that I have to run the machine with acpi
> enabled to take advantage of the driver. I've had some stability
> problems with acpi enabled so I will probaly only use this under
> special circumstances.
It should be fixed if you have applied 'timer' fix:
(I am sure you have but just checking...) If you see more
instabilities, please let me know.
> Again, thank you for this pointer and thank you for all your work
> on this machine. Your work made it possible to get FreeBSD working
> on this beast. It has been surprising how many little things have
> made this machine so difficult to configure.
Yeah... It was really painful and took nearly a week just to make it
> I will try to attach a copy of the program and makefile with this
> email as per your request. To create an executable type "make
> hermite" and then run the executable, ./hermite, from the command
> line. You will have to create a directory called "graph" wherever
> you happen to put the files because at the start of the run it
> writes a file to that directory.
> Finally, there is a stochastic component, and a random variable is
> added at each time step. The time required will vary from slightly
> from run to run, so you have to make multiple runs and average them
> to get a better idea of how long it takes. This is not quite the
> full blown version. We double the matrix size and double the time
> steps for the bigger problem and have to make multiple runs because
> of the stochastic part.
It seems to me that it's more like FPU benchmarking than overall CPU
performance test. FreeBSD/amd64 is slowly catching up in that area
but it's far from ideal.
We need lots of optimization in that area (e. g., using SSE/SSE2).
More information about the freebsd-amd64