hi, can anybody throw some light as to how to find out the core temperature of cpu/motherboard ?
with best regards perumal --- In [email protected], "J. Biran" <[EMAIL PROTECTED]> wrote: > > Some motherboard makers provide utilities to monitor > temperatures in real time. i.e. ASUS PCprobe. Check your > manufacturer's web site. > > > > OC sounds enticing, but be careful. > > > > After first time your system hangs or corrupts your data > because of overclocking you'll wish you were not as > aggressive. It's might be fun for a gaming system. > > > > All chips on your computer slow down the hotter they get. > They get hotter the faster you clock them. Not to mention > their lifetime decreases exponentially with temperatures. > > > > Joseph Biran > ____________________________________________ > > > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of dingo > Sent: Tuesday, May 27, 2008 8:21 AM > To: [email protected] > Subject: RE: [amibroker] Re: Dual-core vs. quad-core > > > > As long as the temp stays down you'll be ok. Several years > ago I had a water cooled dual Xenon rig and had some runs > that took several days - never missed a beat. > > > > Paul mentioned Coretemp and although I haven't used it > myself it looks like it would do the trick: > http://www.alcpu.com/CoreTemp/ > > > > Are you using the cpu fan that came with the chip or an > after market one? If you do overclock then you'll > definitely need to get a good after market fan - check > www.maximumcpu.com for reviews. I'd do it anyway just as > insurance - the prices are very reasonable unless you get > exotic which shouldn't be necessary. > > > > I looked back in the thread but didn't see where you said > what mother board you're using... And you did mention the > 6600 - is that your cpu? > > > > d > > > > _____ > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve Dugas > Sent: Tuesday, May 27, 2008 11:11 AM > To: [email protected] > Subject: Re: [amibroker] Re: Dual-core vs. quad-core > > Hi Paul - Something occurred to me today and I was hoping to > get your opinion ( as well as D's or anyone else with the > knowledge who would care to comment ). Do you think, even > *without* overclocking, that running these chips flat-out at > 100% for hours or days at a time could possibly cause > overheating and subsequent damage/destruction to the chip? > Is there a simple and cheap way to just monitor the temps ( > no overclocking involved ) to be sure we do continue running > flat-out if temps are approaching or entering the danger > zone? Thanks very much! > > > > Steve > > ----- Original Message ----- > > From: Paul Ho <mailto:[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Monday, May 26, 2008 7:44 AM > > Subject: RE: [amibroker] Re: Dual-core vs. quad-core > > > > Steve, > > My knowledge on OC is quite limited, I have only OCed 3 pcs > in the last 4 to 5 years. Fortunately, they are all still > working, so you can say that my experiences have been > favourable. OC reminds a lot about Car Hot Rodding in my > younger days. they are quite similar, both are attempts to > modify a basically mass manufactured product to performance > higher than their specifications. Both are based on home > grown wisdom rather than instituitionalised research. OCing > is basically elevating both the CPU clock speed as well as > that of the memory bus, and my methods, all from what I read > on the internet are always based on first clocking the > memory controller hub (MCH), and once that is done, > overclock the CPU by increasing the multiplier, (CPU speed > is always adjusted as a multiplier of bus speed becasue they > need to be synchronised). > > The danger related to OC is always that of overheating, > firstly the CPU, and secondary the MCH. So choosing a MB > that has decent cooling features for particularly the MCH is > of the most importance.(CPU are always well looked after by > MB manufacturers, and increasingly MCH is going the same > way). In addition, the faster the memory, the more sucessful > the exercise is. So My advice is always getting the fastest > memory you can afford. (this is even more so given what > Tomasz has said recently in his AB performance tests. > > Before you overclock, you need to download a few tools > > 1. cpuz > > 2. coretemp > > 3. memory tesing > > You also need to find a set of instructions for your MB. I > found this set of instruction for my MB pretty good > http://www.hardforum.com/showthread.php?t=1169366 In this > instruction, you will find where to download the tools I > mentioned, as well as a good methodology to follow. You may > be able to find you MB specific instructions on this site. > > > > Also I found that disabling all devices that I dont need > helps - these include parallel and serial ports, basically > all the things I dont use and I can disable through the Bios > setting. > > > > Testing: I only use AB for stress and performance testing (I > use the recommened software from the site for diagnostic > tests), because that is what I'm ocing for. What I would > suggest would be to use a few of your AFLs, insert in them a > few Getperformancecounter statements (AB function). These > should include a relatively simple AFL, a long and > complicated AFL testing lots of symbols (to test Memory > access performance) and one that is somewhere in between. At > the same time - monitor the temperatures. These are far more > meaningful tests than the stress tests that most OC sites > recommend. > > > > I think dingo is quite an expert in this area. may be he > will say a few words. > > Cheers > > Paul. > > _____ > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve Dugas > Sent: Monday, 26 May 2008 5:47 AM > To: [email protected] > Subject: Re: [amibroker] Re: Dual-core vs. quad-core > > Hi Paul - I found your comment about overclocking > interesting, have googled around a bit but find that most of > the discussion is over my head. For example The Overclockers > Forum > > > > http://www.ocforums.com/showthread.php?t=516399 > > > > discusses overclocking the Intel Q6600 chip on my new > computer and people are claiming to get as much as 3.8GH out > of this 2.4 GH chip. If you can find the time, would you > mind saying a few words about overclocking, how it is done, > and what are the dangers/limits etc? Do you need special > software to monitor the core temps? Thanks! > > > > Steve > > ----- Original Message ----- > > From: Paul Ho <mailto:[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Wednesday, May 14, 2008 2:12 AM > > Subject: RE: [amibroker] Re: Dual-core vs. quad-core > > > > I havent noticed any slow down when I run 2 instances of AB > optimizing almost on a continuous bases on my core 2 Duo. I > have 4 Mb L2 cache. In fact with overclocking, I'm able to > increase the core speed significantly, and noticably faster > on AB optimization, without increasing the temps to above 50 > deg C > > > > _____ > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of Tomasz > Janeczko > Sent: Wednesday, 14 May 2008 5:25 AM > To: [email protected] > Subject: Re: [amibroker] Re: Dual-core vs. quad-core > > Hello, > > I just run the same code on my relatively new notebook (Core > 2 Duo 2GHz (T7250)) > and the loop takes less than 2ns per iteration (3x speedup). > So it looks like the data sits entirely inside the cache. > This core 2 has 2MB of cache and thats 4 times more than on > Athlon x2 I got. > > > If what you say is true, and one core alone fills the > memory > > bandwidth, then there should be a net loss of performance > while > > running two copies of ami. > > It depends on complexity of the formula and the amount of > data per symbol > you are using. As each array element has 4 bytes, to fill 4 > MB of cache > you would need 1 million array elements or 100 arrays each > having 10000 elements > or 10 arrays each having 100K elements. Generally speaking > people testing > on EOD data where 10 years is just 2600 bars should see > speed up. > People using very very long intraday data sets may see > degradation, but > rather unnoticeable. > > Best regards, > Tomasz Janeczko > amibroker.com > ----- Original Message ----- > From: "dloyer123" <[EMAIL PROTECTED] > <mailto:dloyer123%40yahoo.com> > > To: <[email protected] > <mailto:amibroker%40yahoogroups.com> > > Sent: Tuesday, May 13, 2008 8:12 PM > Subject: [amibroker] Re: Dual-core vs. quad-core > > > Nice, tight loop. It is good to see someone that has made > the effort > > to make the most out of every cycle and the result shows. > > > > My new E8400 (45nm 3GHz, dual core) system should arrive > tomorrow. > > The first thing I will do will be to benchmark it running > ami. I run > > portfolio backtests over a few years of 5 minute data over > a thousand > > or so symbols. Plenty of data to overflow the cache, but > still fit > > in memory. No trig. > > > > I'll post what I find. > > > > If what you say is true, and one core alone fills the > memory > > bandwidth, then there should be a net loss of performance > while > > running two copies of ami. > > > > > > > > --- In [email protected] > <mailto:amibroker%40yahoogroups.com> , "Tomasz Janeczko" > <groups@> > > wrote: > >> > >> Hello, > >> > >> FYI: SINGLE processor core running an AFL formula is able > to > > saturate memory bandwidth > >> in majority of most common operations/functions > >> if total array sizes used in given formula exceedes DATA > cache size. > >> > >> You need to understand that AFL runs with native assembly > speed > >> when using array operations. > >> A simple array multiplication like this > >> > >> X = Close * H; // array multiplication > >> > >> gets compiled to just 8 assembly instructions: > >> > >> loop: 8B 54 24 58 mov edx,dword ptr [esp+58h] > >> 00465068 46 inc > > esi ; increase counters > >> 00465069 83 C0 04 add eax,4 > >> 0046506C 3B F7 cmp esi,edi > >> 0046506E D9 44 B2 FC fld dword ptr [edx+esi*4- > > 4] ; get element of close array > >> 00465072 D8 4C 08 FC fmul dword ptr [eax+ecx- > > 4] ; multiply by element of high array > >> 00465076 D9 58 FC fstp dword ptr [eax- > > 4] ; store result > >> 00465079 7C E9 jl > > loop ; continue until all elements are processed > >> > >> As you can see there are three 4 byte memory accesses per > loop > > iteration (2 reads each 4 bytes long and 1 write 4 byte > long) > >> > >> On my (2 year old) 2GHz Athlon x2 64 single iteration of > this loop > > takes 6 nanoseconds (see benchmark code below). > >> So, during 6 nanoseconds we have 8 byte reads and 4 byte > store. > > Thats (8/(6e-9)) bytes per second = 1333 MB per second > read > >> and 667 MB per second write simultaneously i.e. 2GB/sec > combined ! > >> > >> Now if you look at memory benchmarks: > >> > http://community.compuserve.com/n/docs/docDownload.aspx?webt > ag=ws- > > pchardware&guid=6827f836-8c33-4063-aaf5-c93605dd1dc6 > >> you will see that 2GB/s is THE LIMIT of system memory > speed on > > Athlon x64 (DDR2 dual channel) > >> And that's considering the fact that Athlon has > superior-to-intel > > on-die integrated memory controller (hypertransfer) > >> > >> // benchmark code - for accurrate results run it on LARGE > arrays - > > intraday database, 1-minute interval, 50K bars or more) > >> GetPerformanceCounter(1); > >> for(k = 0; k < 1000; k++ ) X = C * H; > >> "Time per single iteration > [s]="+1e-3*GetPerformanceCounter()/ > > (1000*BarCount); > >> > >> Only really complex operations that use *lots* of FPU > (floating > > point) cycles > >> such as trigonometric (sin/cos/tan) functions are slow > enough for > > the memory > >> to keep up. > >> > >> Of course one may say that I am using "old" processor, > and new > > computers have faster RAM and that's true > >> but processor speeds increase FASTER than bus speeds and > the gap > > between processor and RAM > >> becomes larger and larger so with newer CPUs the > situation will be > > worse, not better. > >> > >> > >> Best regards, > >> Tomasz Janeczko > >> amibroker.com > >> ----- Original Message ----- > >> From: "dloyer123" <dloyer123@> > >> To: <[email protected] > <mailto:amibroker%40yahoogroups.com> > > >> Sent: Tuesday, May 13, 2008 5:02 PM > >> Subject: [amibroker] Re: Dual-core vs. quad-core > >> > >> > >> > All of the cores have to share the same front bus and > > northbridge. > >> > The northbridge connects the cpu to memory and has > limited > > bandwidth. > >> > > >> > If several cores are running memory hungry > applications, the > > front > >> > buss will saturate. > >> > > >> > The L2 cache helps for most applications, but not if > you are > > burning > >> > through a few G of quote data. The L2 cache is just > 4-8MB. > >> > > >> > The newer multi core systems have much faster front > buses and > > that > >> > trend is likely to continue. > >> > > >> > So, it would be nice if AMI could support running multi > cores, > > even > >> > if it was just running different optimization passes on > different > >> > cores. That would saturate the front bus, but take > advantage of > > all > >> > of the memory bandwidth you have. It would really help > those > > multi > >> > day walkforward runs. > >> > > >> > > >> > > >> > --- In [email protected] > <mailto:amibroker%40yahoogroups.com> , "markhoff" > <markhoff@> wrote: > >> >> > >> >> > >> >> If you have a runtime penalty when running 2 > independent AB jobs > > on > >> > a > >> >> Core Duo CPU it might be caused by too less memory > (swapping to > >> > disk) > >> >> or other tasks which are also running (e.g. a web > browser, audio > >> >> streamer or whatever). You can check this with a > process explorer > >> >> which shows each tasks CPU utilisation. Similar, 4 AB > jobs on a > > Core > >> >> Quad should have nearly no penalty in runtime. > >> >> > >> >> Tomasz stated that multi-thread optimization does not > scale good > >> > with > >> >> the CPU number, but it is not clear to me why this is > the case. > > In > >> > my > >> >> understanding, AA optimization is a sequential process > of > > running > >> > the > >> >> same AFL script with different parameters. If I have > an AFL with > >> >> significantly long runtime per optimization step (e.g. > 1 minute) > > the > >> >> overhead for the multi-threading should become quite > small and > >> >> independent tasks should scale nearly with the number > of CPUs > > (as > >> > long > >> >> as there is sufficient memory, n threads might need > n-times more > >> >> memory than a single thread). For sure the situation > is > > different if > >> >> my single optimization run takes only a few millisecs > or > > seconds, > >> > then > >> >> the overhead for multi-thread-managment goes up ... > >> >> > >> >> Maybe Tomasz can give some detailed comments on that > issue? > >> >> > >> >> Best regards, > >> >> Markus > >> >> > >> > > >> > > >> > ------------------------------------ > >> > > >> > Please note that this group is for discussion between > users only. > >> > > >> > To get support from AmiBroker please send an e-mail > directly to > >> > SUPPORT {at} amibroker.com > >> > > >> > For NEW RELEASE ANNOUNCEMENTS and other news always > check DEVLOG: > >> > http://www.amibroker.com/devlog/ > >> > > >> > For other support material please check also: > >> > http://www.amibroker.com/support.html > >> > Yahoo! Groups Links > >> > > >> > > >> > > >> > > > > > > > > ------------------------------------ > > > > Please note that this group is for discussion between > users only. > > > > To get support from AmiBroker please send an e-mail > directly to > > SUPPORT {at} amibroker.com > > > > For NEW RELEASE ANNOUNCEMENTS and other news always check > DEVLOG: > > http://www.amibroker.com/devlog/ > > > > For other support material please check also: > > http://www.amibroker.com/support.html > > Yahoo! Groups Links > > > > > > > > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.100 / Virus Database: 269.24.1/1468 - Release > Date: 5/26/2008 3:23 PM >
