|
Other BSD and UNIX/UNIX-like Any other flavour of BSD or UNIX that does not have a section of its own. |
|
Thread Tools | Display Modes |
|
|
|||
DragonFly BSD evaluation
I successfully installed DragonFly BSD on a Tyan S2892. There are however several issues:
1. The kernel only sees 3GB of the 4GB of memory. I think this is a typical i86 desease, which also exists in FreeBSD. I guess to solve this a kernel recompile is required...or the AMD64 version if it would be available in DragonFly BSD 2. The DragonFly BSD kernel apparently only sees one core of the total 4 CPU cores available: two dual core Operon 275 CPUs or the CPU load spreading is simply wrong. Here is a test that proves this, by running a GNU Octave script (see below) that measures the calculation time. In the first test I just ran one script, the second time the script was run two times at the same time. Elapsed time for a 100X100 matrix: Single run in FreeBSD (AMD64): 74s Single run in DragonFlyBSD: 66s Two concurrent runs in FreeBSD (AMD64): 74s for each run Two concurrent runs in DragonFlyBSD: 132s for each run FreeBSD is doing what you expect, spread the load, while DragonFlyBSD seems to put to different processes in one core. Any thoughts? Code:
clear all runs=3; % (5) cumulate = 0; p = 0; vt = 0; vr = 0; vrt = 0; rvt = 0; RV = 0; j = 0; k = 0; x2 = 0; R = 0; Rxx = 0; Ryy = 0; Rxy = 0; Ryx = 0; Rvmax = 0; f = 0; for i = 1:runs x = abs(randn(100,100)); tic; % Calculation of Escoufier's equivalent vectors p = size(x, 2); vt = [1:p]; % Variables to test vr = []; % Result: ordered variables RV = [1:p]; % Result: correlations for j = 1:p % loop on the variable number Rvmax = 0; for k = 1:(p-j+1) % loop on the variables if j == 1 x2 = [x, x(:, vt(k))]; else x2 = [x, x(:, vr), x(:, vt(k))]; % New table to test end R = corrcoef(x2); % Correlations table Ryy = R(1:p, 1:p); Rxx = R(p+1:p+j, p+1:p+j); Rxy = R(p+1:p+j, 1:p); Ryx = Rxy'; rvt = trace(Ryx*Rxy)/((trace(Ryy^2)*trace(Rxx^2))^0.5); % RV calculation if rvt > Rvmax Rvmax = rvt; % test of RV vrt(j) = vt(k); % temporary held variable end end vr(j) = vrt(j); % Result: variable RV(j) = Rvmax; % Result: correlation f = find(vt~=vr(j)); % identify the held variable vt = vt(f); % reidentify variables to test end timing = toc; cumulate = cumulate + timing; end times(5, 3) = timing; disp(['Escoufier''s method on a 100x100 matrix (mixed)________ (sec): ' num2str(timing)]) clear x; clear p; clear vt; clear vr; clear vrt; clear rvt; clear RV; clear j; clear k; clear x2; clear R; clear Rxx; clear Ryy; clear Rxy; clear Ryx; clear Rvmax; clear f; |
|
|||
Quote:
|
|
|||
Quote:
you: http://forums.freebsd.org/showthread.php?t=3064 Normally a 32-bit system should be able to access up to 64GB of memory with a kernel adjustment. The drawback is that the system will be somewhat slower. I used to work with a compute server with 32GB of memory running a 32-bit Red Hat kernel. |
|
||||
To get the most out of your memory - see AMD64; or refer to 'PAE' on Wikipedia. Not all flaviours of BSD may support it.
I think I would take an amd64 build over an i386 PAE build anyday (note: amd64 like i386 is just an old name for the arch; not the chip required!)
__________________
My Journal Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''. |
|
|||
I see. Interesting. I recall running across this some years ago during the 5.x release and realizing that my processor wasn't supported (it still isn't - it doesn't support the EM64 mode).
http://www.freebsd.org/releases/7.1R...tml#PROC-AMD64 Something to keep in mind when I go shopping for another server or lease. |
|
||||
A 32-bit kernel can only access 4 GB of RAM. A 32-bit process can only access 4 GB of RAM (actually less due to the way kernel memory is separated from user memory, usually in a 2/2 split, but some OSes can use 1 GB kernel/3 GB user).
A 32-bit kernel using PAE can access 64 GB of RAM, although most systems seem to be limited to less (BIOS? chipset? CPU?). A 32-bit process cannot access more than 4 GB of RAM. The only benefit to PAE is that it enables you to run multiple 32-bit processes, each accessing their own separate 4 GB. A 64-bit kernel can access (currently) 2^48 bytes of RAM (limited by the width of the physical address bus, or whatever it's called), and a 64-bit process can also access the whole 2^48 bytes of RAM (or does that use the full 2^64 logical memory space? this physical limitation always confuses me). Eventually, the hardware/memory/address (whatever it's called) bus will be widened out to the complete 2^64 bytes of RAM. Hence the "rule of thumb" that if you need to access/use more than 4 GB of RAM (more than 3 GB actually), you should use a 64-bit system. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
DragonFly handbook | JimC | Other BSD and UNIX/UNIX-like | 1 | 28th February 2009 07:25 PM |
DragonFly 2.2 iwi support... | sorivenul | Other BSD and UNIX/UNIX-like | 0 | 19th February 2009 07:17 AM |
DragonFly BSD 2.2 released | matthias | Other BSD and UNIX/UNIX-like | 0 | 18th February 2009 02:37 PM |
NTFS on DragonFly BSD | Malakim | Other BSD and UNIX/UNIX-like | 4 | 17th October 2008 03:43 PM |
URL evaluation tools to determine if serving malware | dk_netsvil | Off-Topic | 0 | 30th June 2008 04:55 PM |