Posts by Travis DJ

1) Questions and Answers : Web site : Questions about R@H's san setup (Message 45883) Posted 10 Sep 2007 by Travis DJ Post: I was wondering about the reason for the choice of the Polyserve matrix server/san backend over a Dell\|EMC SAN solution. The company I work for recently purchased a Dell/EMC Cx10 SAN and we have it attached to 3 PowerEdge 1950s. To date we haven't had any trouble with it or the 1950s; in fact one day I was load-balancing our UPSes and (intentionally) uplugged one of the two power inputs on the SAN. No sooner than I plugged it back into another UPS, Dell gold technical support was calling my cell phone and asking if there was any trouble. Needless to say I was impressed. It almost seems like anathema to invest in a SAN solution owned by HP that will be running on Dell servers. :)
2) Message boards : Number crunching : 64-Bit Rosetta? (Message 19258) Posted 24 Jun 2006 by Travis DJ Post: This is almost over my head..but from what I know.. FPU registers are 80-bit which is why they can store two 32-bit values and there are 8 of them. That also explains why SSE is a better option (than making a pure x64 binary) because the 8 SSE registers are 128-bit wide and can hold 4 single precision results per register and it wouldn't require a rewrite. What I am not sure I fully comprehend is how the FPU behaves in x64 mode. I understand that the GPRs in x64 are really actually general purpose registers as opposed to IA-32's somewhat limited uses on all the available registers can be used for. At least form Wikipedia, it's said that SSE2 repleaces x87 in x64 mode and there is the choice of 32 or 64 bit precision (I assume that's called by the programmer in the code). So from what I gather from reading that and what I already know, it seems right to assume there is no real benefit from making a 64-bit binary for Rosetta given what the program does as SSE/2 can fully accomodate that in 32-bit mode as it is. Right? :)
3) Message boards : Number crunching : 64-Bit Rosetta? (Message 19256) Posted 24 Jun 2006 by Travis DJ Post: This is almost over my head..but from what I know.. FPU registers are 80-bit which is why they can store two 32-bit values and there are 8 of them. That also explains why SSE is a better option (than x64) because the 8 SSE registers are 128-bit wide and can hold 4 single precision results per register. What I am not sure I fully comprehend is how the FPU behaves in x64 mode. I understand that the GPRs in x64 are really actually general purpose registers as opposed to IA-32's somewhat limited uses on all the available registers can be used for. At least form Wikipedia, it's said that SSE2 repleaces x87 in x64 mode and there is the choice of 32 or 64 bit precision (I assume that's called by the programmer in the code). So from what I gather from reading that and what I already know, it seems right to assume there is no real benefit from making a 64-bit binary for Rosetta given what the program does as SSE/2 can fully accomodate that in 32-bit mode as it is. Right? :)
4) Message boards : Number crunching : Client errors (Message 18535) Posted 12 Jun 2006 by Travis DJ Post: A fantastic program for Pentium-M/Centrino (and newer) systems is Notebook Hardware Control. They also have added support for AMD systems recently and it's getting better. It's a fantastic, low overhead, very detailed monitoring program (and looks cool too). And it's free..
5) Message boards : Number crunching : Client errors (Message 18175) Posted 8 Jun 2006 by Travis DJ Post: From what I recall about the Compatibility Tab, it basically tells the program the current OS is "X" and passes along settings and so on so the program literally thinks its running on something else. I would imagine there is some very small degree of performance degredation when doing this... considering the overhead of XP pretending to be 2K..
6) Message boards : Number crunching : Rosetta for Intel Mac Mini? (Message 18040) Posted 8 Jun 2006 by Travis DJ Post: From David, it appears that there may be only one way at the present to get Rosetta working on an Intel Mac Mini... Have patience. Don't bother with Boot Camp (and installation, licensing, etc..) there is a mac-i686 version already compiled and being tested over on Ralph@Home. Once the bugs are squashed it will be automatically be available to Intel Mac Rosetta@Home users. So join, sit back, and wait for the magic to happen on its own. :)
7) Message boards : Number crunching : Very slow computer boot up since adding Rosetta (Message 18035) Posted 8 Jun 2006 by Travis DJ Post: Without knowing just what exactly is running in memory during startup.. it could be that with the installation of BOINC and attachment to R@H that your memory requirement increased past what's physically available. To find out if that's the case, after you've gotten to your desktop, hit CTRL+ALT+DEL to bring up your task manager, go to the performance tab. Look at the Physical Memory (K) box and note the total RAM. Then look at the Commit Charge (K) box and note the total. In general if the Commit Charge total is within 32,000KB of the Physical Memory total, Windows has already begun to make use of the Page File on your Hard Drive thus slowing your machine more and more as demand increases. The best fix is a memory upgrade chip with 512MB or more capacity. You can't ever have too much RAM but I'd not suggest any more than 3GB in a WinXP (32-bit) system, per Microsoft. If you google a bit you can find "Microsoft Bootvis" and install it to get an idea of what is running, when it runs, and how much memory, etc is going on while your system boots. Hope that helps.
8) Message boards : Number crunching : Client errors (Message 18033) Posted 8 Jun 2006 by Travis DJ Post: Teemu, Are both your Pentium-M systems laptops, desktops or both? In my experience with laptops & Pentium-M CPUs the one thing that makes all the difference in the world when running something like BOINC is making sure you clean out your heatsink/fan at least monthly. P-Ms handle high heat very well, up to about 90C but you really don't want it to hover around design spec all the time. So if your problem is heat related (I'm not saying it is, but this is a good housekeeping suggestion anyhow) keeping it dust-free can lower your temp 10-15C. When mine starts staying around 85C all the time I know it's time to clean it then the temperarture goes back down to 70-73C under full load. PS: Are you running boinc as a service or only when a user is logged in?
9) Message boards : Number crunching : Are INTEL systems not getting enough credit or are AMD systems getting too much? (Message 16115) Posted 13 May 2006 by Travis DJ Post: Greenhornet is producing roughly 160,000 seconds of work on the 8th. If, as you claim, the dual core score is doubled by fact that it was a dual core, the amount of time the Boinc client would report would be 86,400 seconds. no no.. where you're wrong is each core processes one workunit at a time - so that means two workunits and not double the time (What you said was as if I get two guys to mow my two yards they'll do double the work in double the time; rather if they both mow both lawns simultaneously at the same speed they'll get double the work complete in the same amount of time compared to one man mowing one lawn at a time). The whet/dhry score is a combined number for both cores running for a fixed amount of time. Basically what you get is two workunits completing at (given a similar workunit) close to the same time as one workunit completing on a single core of the same speed. So, if you find a way to make time go faster than realtime, let me know so I can get some of that double-time performance. :)
10) Message boards : Number crunching : Are INTEL systems not getting enough credit or are AMD systems getting too much? (Message 15956) Posted 11 May 2006 by Travis DJ Post: From what I'm seeing, I imagine that Smoke1 is probably running the default client, and GreenHornet is running an optimized Boinc client in addition to being overclocked. GreenHornet has a dual core cpu. So divide the fpops/iops by two and that's roughly how much work per cpu core is possible. It's probably not overclocked, the numbers make sense in relation to the Athlon64 3000+ you have. If you take into consideration the 'high' numbers of the X2 but remember it only has one memory interface and the wu_time/xxx factor then the claimed credit would be accurate .. In any case I thought the benchmark code in BOINC clients was identical across the board no matter if the client was 'optimized' or not. There is bound to be some variation as said above even on a same system- for that reason LHC@home implemented a system to average the claimed credit into the final granted credit of a given workunit.