|
PureBytes Links
Trading Reference Links
|
hi,
can anybody throw some light as to how to find out the core
temperature of cpu/motherboard ?
with best regards
perumal
--- In amibroker@xxxxxxxxxxxxxxx, "J. Biran" <jbiran@xxx> 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: amibroker@xxxxxxxxxxxxxxx
> [mailto:amibroker@xxxxxxxxxxxxxxx] On Behalf Of dingo
> Sent: Tuesday, May 27, 2008 8:21 AM
> To: amibroker@xxxxxxxxxxxxxxx
> 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: amibroker@xxxxxxxxxxxxxxx
> [mailto:amibroker@xxxxxxxxxxxxxxx] On Behalf Of Steve Dugas
> Sent: Tuesday, May 27, 2008 11:11 AM
> To: amibroker@xxxxxxxxxxxxxxx
> 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:paultsho@...>
>
> To: amibroker@xxxxxxxxxxxxxxx
>
> 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: amibroker@xxxxxxxxxxxxxxx
> [mailto:amibroker@xxxxxxxxxxxxxxx] On Behalf Of Steve Dugas
> Sent: Monday, 26 May 2008 5:47 AM
> To: amibroker@xxxxxxxxxxxxxxx
> 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:paultsho@...>
>
> To: amibroker@xxxxxxxxxxxxxxx
>
> 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: amibroker@xxxxxxxxxxxxxxx
> [mailto:amibroker@xxxxxxxxxxxxxxx] On Behalf Of Tomasz
> Janeczko
> Sent: Wednesday, 14 May 2008 5:25 AM
> To: amibroker@xxxxxxxxxxxxxxx
> 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" <dloyer123@xxx
> <mailto:dloyer123%40yahoo.com> >
> To: <amibroker@xxxxxxxxxxxxxxx
> <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 amibroker@xxxxxxxxxxxxxxx
> <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: <amibroker@xxxxxxxxxxxxxxx
> <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 amibroker@xxxxxxxxxxxxxxx
> <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
>
------------------------------------
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
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|