It is currently Sat May 25, 2013 9:57 am

All times are UTC - 8 hours




Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: CPU/GPU/HSF Thermal Testing
PostPosted: Tue Aug 22, 2006 2:48 pm 
Offline
SPCR Reviewer

Joined: Sun Aug 11, 2002 3:26 pm
Posts: 3997
Location: Phoenix, AZ
Discussion split from the Aero-case Condor Article discussion thread to avoid mucking up that thread needlessly.

Devon's post in the Condor thread raises some important points that merit a fuller discussion:
Devon wrote:
This is a question that has been on my mind a lot recently. It applies to CPU figures as well as GPU figures. I think smilingcrow has it right: They're not terribly reliable, and they are certainly not representative of typical usage.

I think this issue has already been dealt with, at least where cooling is concerned. SPCR has known for years that CPUBurn is one of the heaviest loads that you can use to stress a CPU; realistic, non-benchmark loads do not eat up as much power or generate as much heat. The purpose of using CPUBurn is to test heatsinks in a worst-case scenario. If a heatsink can handle a processor running CPUBurn, it will be fine for other strenuous activities. In addition, it is such a simple load that it makes testing easily repeatable — not something you can say about "typical" usage scenarios.

Knowing the maximum power draw has a similar use in the context of GPUs — it helps single out worst-case scenarios for testing. It was Xbitlabs' testing that helped me recognize that the stress-test that we were using (ATI Tool) wasn't stressing the X1900XTX enough to trust it as a benchmark.

However, when it comes to comparing different GPUs (or CPUs for that matter) with each other, I don't know that I can think of any feasible test method that I would trust. Using the same utility to test all processors (as we have been doing for some time) is less than ideal because different chips have different characteristics — the most stressful load is different for every chip. If we're serious about comparing a maximum power figure (vs. a typical figure), we need to use a customized utility for every processor.

Let me talk about CPUs for a bit, since it will allow me to use CPUBurn as an example. One of the nice things about CPUBurn was that it includes different utilities for P6 (P-III?) vs. K6 architectures. The fact that Intel and AMD's later chips were built on these earlier architectures has helped CPUBurn remain a useful tool, out of date as it is. Subsequent testing of the utility, which showed that no greater load could be found, confirmed the usefulness of CPUBurn.

However, with the release of Conroe, which is a significantly different architecture, things have changed. 2xCPUBurn no longer even approaches the heaviest load it is possible to put on the Conroe. Our testing showed it to dissipate about 35W — unbelievable on a chip with a TDP of 65W. To hit 65W, I would guess that we need a utility that simultaneously loads all of the chips SSE units, plus occupies all 4MB of cache. As far as I know, this utility does not exist. Real world encoding applications may come close, but ultimately they're not easily repeatable and are unlikely to be optimized to use 4MB of cache.

So, not only do we not have a utility that we can trust to give us maximum power dissipation on Conroe, but the usefulness of such a utility is less than it has ever been. Why should maximum load matter now when
a) typical usage is so far below, much lower than it has been with Intel's previous processors if CPUBurn is anything to judge by, and
b) the heatsink market is filled with products designed to cool twice the TDP of the Conroe.

It seems to me that the maximum power approach is really only useful when judging what is needed to cool a processor, and, given the two points I just made above, it is less relevant now than ever before. When comparing heatsinks, it is really only necessary to maintain the same chip/load combination for all heatsinks tested; maximum power is not a necessity in that case.

If your interest is power itself (i.e. energy efficiency, not cooling), then maximum power is of little interest, since no modern chips run at full load all the time (I have a GeForce 3 that seemed to ... but I haven't seen any more recent examples).

For efficiency, it is far more useful to come up with a ballpark "typical" figure; for most people this is probably very close to the power consumption at idle. However, trying to test for typical usage is an exercise in futility. Nobody actually has "typical" usage (no family has 2.3 kids), and discovering and trying to characterize how different usage patterns vary from "typical" would require a wide-scale study. Even if such a study were done, the practical use of the information seems very low to me — making use of the information would require a close study of one's personal computing habits... and how many people do you know who could/would do that?

It seems to me that GPUs are very much in the same position as CPUs. nVidia's and ATI's chips have different power profiles, and, even if a steady state "maximum power" load could be found for each of their various processors, gaming is such a dynamic activity that such a load would be useful only for testing coolers, not judging differences in power consumption.

...

_________________
Senior Contributing Writer, SPCR


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 22, 2006 3:28 pm 
Offline

Joined: Fri Dec 26, 2003 6:54 am
Posts: 2978
Location: Sweden
About maxing out a C2, would it use more power if you run CPUBurn, 2x P95 (not set to highest priority), and some other apps at the same time? Or would some kind of priority still make the same result (read power consumption) as a single app run?

I think I've read that SuperPi is great for testing L2 cache, but I'm not sure at all.


Top
 Profile  
 
 Post subject: Re: CPU/GPU/HSF Thermal Testing
PostPosted: Tue Aug 22, 2006 5:12 pm 
Offline

Joined: Tue Dec 13, 2005 1:08 pm
Posts: 1407
Location: Michigan
Devon wrote:
This is a question that has been on my mind a lot recently. It applies to CPU figures as well as GPU figures. I think smilingcrow has it right: They're not terribly reliable, and they are certainly not representative of typical usage.

I found the LostCircuits Conroe/X2 EE article rather interesting.

Image

They actually made some effort at showing some wattage for amount of work done on some real processes. They weren't processes I was terribly interested in, but it was nice to see.

Quote:
However, with the release of Conroe, which is a significantly different architecture, things have changed. 2xCPUBurn no longer even approaches the heaviest load it is possible to put on the Conroe. Our testing showed it to dissipate about 35W — unbelievable on a chip with a TDP of 65W. To hit 65W, I would guess that we need a utility that simultaneously loads all of the chips SSE units, plus occupies all 4MB of cache. As far as I know, this utility does not exist. Real world encoding applications may come close, but ultimately they're not easily repeatable and are unlikely to be optimized to use 4MB of cache.

The CPUTest from 3DMark06 might be a good candidate, but it is also nice if the test like Prime95 will actually test for errors--as merely a system merely continuing to run doesn't mean it is running properly. Some test for thermal throttling would also be good--Netbursts were certainly capable of merely throttling themselves down.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 22, 2006 5:22 pm 
Offline
*Lifetime Patron*

Joined: Sat Apr 24, 2004 1:45 am
Posts: 1765
Location: At Home
Devonar, thanks for the long post.
Devonavar wrote:
SPCR has known for years that CPUBurn is one of the heaviest loads that you can use to stress a CPU; realistic, non-benchmark loads do not eat up as much power or generate as much heat. The purpose of using CPUBurn is to test heatsinks in a worst-case scenario.
Prime95 typically adds about 7 to 10W extra to total system power draw compared to CPUBurn if you use the Torture test with in-place large FFTs. At least that’s what I’ve found with C2D systems. As it runs through a number of different FFT tests, it takes a while to ramp up to this maximum wattage. I guess there’s an optimum FFT size for stressing the C2D to the max. Once you’ve determined what that is, you can always set it in the manual configuration box and go straight for the burn. :)

Mats wrote:
About maxing out a C2, would it use more power if you run CPUBurn, 2x P95 (not set to highest priority), and some other apps at the same time? Or would some kind of priority still make the same result (read power consumption) as a single app run?.
I’ve noticed that when running two separate system loading utilities, that sometimes the system doesn’t stay fully loaded and the power load drops. If I then set the affinity of each application manually so that they are both locked to a single core, the system then jumps to a 100% load.

It shouldn’t be too difficult to develop a utility that gives you the choice of testing the SSE, Integer or Floating Point units on a CPU, along with the option of running on multiple cores. When you are testing up to 4 cores per CPU and up to 2 CPUs per system, it would be useful to have a utility that can handle all of that from one GUI.
If anyone is interested in collaborating on developing a utility with this functionality, then let me know. I would write it in Delphi as that’s the only programming environment that I know reasonably well. It would probably be easiest to use Intel’s Integrated Performance Primitives libraries, as they support SSE. Unless someone has a better idea! Even if I write the thing myself, I would probably still need some assistance from a C++ programmer to help create a custom DLL than contained the subset of the library routines that the utility needed.


Top
 Profile  
 
 Post subject: Re: CPU/GPU/HSF Thermal Testing
PostPosted: Tue Aug 22, 2006 5:32 pm 
Offline
*Lifetime Patron*

Joined: Sat Apr 24, 2004 1:45 am
Posts: 1765
Location: At Home
QuietOC wrote:
The CPUTest from 3DMark06 might be a good candidate, but it is also nice if the test like Prime95 will actually test for errors--as merely a system merely continuing to run doesn't mean it is running properly. Some test for thermal throttling would also be good--Netbursts were certainly capable of merely throttling themselves down.
RMClock seems to be the best utility for managing EIST and it also has a feature whereby it can alert you when CPU thermal throttling is activated. It sounds like a good candidate. I haven’t seen it in action yet, but I’m sure I will when I try passively cooling later in the week.
I strongly agree that the ability to test for errors is important.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 22, 2006 8:43 pm 
Offline
SPCR Reviewer

Joined: Sun Aug 11, 2002 3:26 pm
Posts: 3997
Location: Phoenix, AZ
I think you guys are missing the thrust of Devon's post. The point isn't "how to get the maximum heat out of a CPU for testing" it is, "Why are we trying to get the maximum heat out of CPU for testing?" If a CPU or GPU can never run as hot as during the testing, what's the point of testing it under those conditions? Isn't that a bit like crash testing a car into a wall at 500 mph? Sure, you get results, but of what value are they if the test conditions can never really happen.

I think an important concept is to separate the testing of the heatsink's ability to cool from the testing of the heat source's (CPU/GPU) ability to make heat. Remember that we're testing HS's here, not CPU's. (that's a different kind of review altogether)

Right now, our testing tries to do both at the same time. We try to get the heat source to produce as high, and as consistent, a wattage as possible, and then test the heatsink-in-question's ability to cool that wattage. Now there is good reason to test like this, namely that it most closely replicated the theoretical "worst case" real world condition, but, as Devon pointed out, "theoretical worst case" is becoming further and further separated from the "real world". With the exception of gaming and high-load apps like video or 3D rendering, the "real world" tasks of computing are little changed in the last 5 years, while the "theoretical" computing power has gone through the roof. Considering that <5% of computer users play demanding 3D games ("gamers") and probably <0.1% of users do any sort of extended CPU-intensive tasks like video editing, does it really make sense to use those conditions as the basis for measurement?


I have a possible outline for revising how we test, and think about, HSF performance, for discussion:


Part A: Separate the Heatsink performance testing from the heatsource testing by moving to a simulated die testbed. With the pace of change of CPU/GPU marchitecture and architecture it's darn near impossible to keep a consistent testbed to make reviews comparable. Test heatsink A on one GPU, and heatsink B on another and you have no real idea of how they compare to each other...you only know how they cool on the specific heatsource they were tested on. But, test on a standardized simulator that doesn't change, and you will have a library of performance to compare against. Plus, with a real CPU/GPU, we're only taking a guess at what the real wattage is. The people who design the heatsinks don't design them on real CPU's, why should we test them on them.

Yes, simulators have issues too, namely with accuracy, but those are minor compared to vaguarities in our current on-die testing. (If the Procooling refuges here in our forum want to start a "Simulator Design" thread, go right ahead)

Then a completely different second type of testing could be done on any CPU's or GPU's that we review, to determine how much heat they actually produce. We're starting to do that. It's technically more demanding, but it can be done. Combine accurate heat-production numbers with accurate heatsink performance numbers and you can match the components together. If we continue to increase the number of CPU and GPU reviews we do it would make sense to continue our development of a testing methodology to determine their wattage. But if reviews of them are going to be rare, then we can just test unknown heat sources with heatsinks that we have tested on a simulator to get comparitive indications of their heat production.


Part B I'm a little less sure of, but here's the gist: We need a way to portray the testing results so that you can quantify better what the outcomes will be in the real world if using the tested heatsink. The Condor review illustrated this. It "failed" the torture testing, but we're pretty sure that it would work for most people in the real world. But that's a subjective analysis, and you can see how much confusion that caused. I don't have a real good answer for how to do that analysis without subjectivity though. You could determine what "average" hardware is, and test just on that, maybe. Or you could come up with some range of "normal use", like Intel does for their TDP, and test only at that level. Or maybe its a matter of just presenting the data we already gather differently, maybe a graph showing what the temps/noise would be at a range of wattages instead of just a single number at the highest wattage our testbed du jour could come up with.

_________________
Senior Contributing Writer, SPCR


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 23, 2006 2:55 am 
Offline
*Lifetime Patron*

Joined: Sat Apr 24, 2004 1:45 am
Posts: 1765
Location: At Home
Rusty075 wrote:
I think you guys are missing the thrust of Devon's post. The point isn't "how to get the maximum heat out of a CPU for testing" it is, "Why are we trying to get the maximum heat out of CPU for testing?" If a CPU or GPU can never run as hot as during the testing, what's the point of testing it under those conditions?
I agree, although I’m still not clear as to what is the best software to use for SPCR’s purposes.
To keep it real, one approach is to look at the types of applications that regular people use that are likely candidates for high power consumption and see how they compare to testing utilities such as Prime95 etc. Candidates would be such things as media encoders, which not only consume a lot of CPU power but can often be running for hours at a time. H.264 encoding or decoding might be a prime candidate. There aren’t than many application types that fit into this category, so it shouldn’t take that much time to investigate.

Even if you find a better solution for general CPU testing purposes, utilities such as Prime95 which use error checking are still very useful and I would say necessary for system testing. This is true whether over-clocking or under-volting. Since SPCR does under-volt in certain of its tests, you’ll still need to use such utilities at times.
Running the tests on CPU heatsinks with two different CPU loads is probably the best answer, although more time consuming. That way people can see what the typical scenario is and also what the worst case scenario is.

The situation for GPUs seems much more complex, as when playing a game the load on the GPU can vary considerably from scene to scene. For games that are released as demos, do they typically have a timed demo mode? I think this is the mode that you run when benchmarking a GPU.
It would be possible to run a small number of games in this mode and monitor the effect on GPU temps with a given cooling solution. Using a GPU that allows its sensor readings to be monitored externally would make it easier to keep track of temps, as you can use Speedfan which will show min, max and mean temp readings. I’m not sure if ATI & NVidia’s software supports this feature.
It would take effort to choose a range of games that stressed different features of modern GPUs. And don’t current GPUs vary in their architectural design considerably more than CPUs do! This could lead to very large differences depending on which GPU architecture a heatsink is tested on.

Oh boy, it’s a can of worms; no wonder people use Prime95 & 3DMark. :?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 23, 2006 6:54 am 
Offline
SPCR Reviewer

Joined: Sun Aug 11, 2002 3:26 pm
Posts: 3997
Location: Phoenix, AZ
smilingcrow wrote:
Even if you find a better solution for general CPU testing purposes, utilities such as Prime95 which use error checking are still very useful and I would say necessary for system testing. This is true whether over-clocking or under-volting. Since SPCR does under-volt in certain of its tests, you’ll still need to use such utilities at times.


Utilities like that are useful if you are testing a CPU, but CPU errors are meaningless if you are testing a Heatsink. For a heatsink the only things that matter are °C/W and dBa. Now if it was a CPU review where you were testing overclocking, underclocking, unvolting abilites, etc, then error checking would be important part of the methodology. But to a heatsink, the only thing that matters is it's input wattage. Think about it this way...if in our testing that our CPU had Prime95 errors while testing with a Brand X heatsink. Is that result meaningful? No, because CPU's are individually unique...just because our had errors doesn't mean your's will, and the heatsink probbaly had nothing to do with it.

The idea of uses "real" apps to get typical wattage information seems like the right track, but even that is full of pitfalls. Those apps will typically run as fast as the CPU will let them, so it doesn't really help us come up with a single "typical" wattage to use for testing. Do you test with a wattage that equals the fastest CPU out there, or the median? I think an easier way would be to pick one arbitrary wattage to test heatsinks at, and then allow the community to compile a "typical wattage" of actual CPU's. Then a user could look at what their individual wattage is in comparison to the "testing" wattage and extrapolate what the temps would be in their system if they bought that heatsink.

Now how to construct a testing methodology around that is still something I don't have a handle on. One way would be to use a simulator that has a variety of preset wattage levels, say at 10watt increments from 10 to 100. You could then run a series of tests and produce a data point at each increment. Plot those on a graph (instead of a table like we do now) with ΔC on one axis and W on the other, and readers can see the patterns. The trouble is that you'd have to run a separate series of tests for each fan speed as well and plot their lines on the graph as well. The resulting graph would be a wealth of information...but as someone who has run HSF tests before, I would hate to have to produce it. Each data point takes about an hour to produce. That's 10 hours to do each 10-point run. Multiply that by three fan speed settings, and you're talking about 30 hours of continuous testing to get one graph. Plus we typically do at least three individual runs and average the outcomes...that works out to 90 hours of testing per heatsink. Unless you find some way to automate the process, that's simply not workable.


GPU testing is equivalent to CPU testing, really. You just swap "app" for "game". I think you're on the right track of using gameplay to come up with a wattage. Do the testing with a few different cards and a pattern may emerge, something to the effect of, "Doom3 averages a GPU wattage that is 75% of the GPU's theoretical max. 3DMark is 95%, etc" That sort of testing you'd only have to do once, not everytime you testes a new heatsink.


Can of worms..can of worms indeed. :lol:

_________________
Senior Contributing Writer, SPCR


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 23, 2006 8:29 am 
Offline
*Lifetime Patron*

Joined: Sat Apr 24, 2004 1:45 am
Posts: 1765
Location: At Home
Rusty075 wrote:
Utilities like that are useful if you are testing a CPU, but CPU errors are meaningless if you are testing a Heatsink. For a heatsink the only things that matter are °C/W and dBa. Now if it was a CPU review where you were testing overclocking, underclocking, unvolting abilites, etc, then error checking would be important part of the methodology. But to a heatsink, the only thing that matters is it's input wattage. Think about it this way...if in our testing that our CPU had Prime95 errors while testing with a Brand X heatsink. Is that result meaningful? No, because CPU's are individually unique...just because our had errors doesn't mean your's will, and the heatsink probbaly had nothing to do with it.
Agreed, I didn’t intend to imply otherwise, I was simply stating that Prime95 is a useful tool for testing stability when under-volting.

Rusty075 wrote:
The idea of uses "real" apps to get typical wattage information seems like the right track, but even that is full of pitfalls. Those apps will typically run as fast as the CPU will let them, so it doesn't really help us come up with a single "typical" wattage to use for testing. Do you test with a wattage that equals the fastest CPU out there, or the median? I think an easier way would be to pick one arbitrary wattage to test heatsinks at, and then allow the community to compile a "typical wattage" of actual CPU's. Then a user could look at what their individual wattage is in comparison to the "testing" wattage and extrapolate what the temps would be in their system if they bought that heatsink.
I like the idea of testing at two CPU speeds; one at a midrange speed for a particular CPU range and the other at the top end and preferably beyond using over-clocking.
I think there may well be a need for this because at the higher CPU frequencies the extra VCore needed tends to mean that the cooling efficiency is not linear at all, so extrapolation becomes too inaccurate to be meaningful.
A remaining question is, do you under-volt when testing the mid-range CPU? Or you could run the test twice, once at stock VCore and once undervolted.
It’s more work, but at least you don’t have to run the audio tests for each variation as the fan speeds are constant between them.
And you only need to determine the lowest stable VCore for the particular CPU & motherboard combination the once and that information can be carried forward for other tests.
For the current C2D range, I would test at 2.13 GHz and ~3.2 GHz.

Rusty075 wrote:
GPU testing is equivalent to CPU testing, really. You just swap "app" for "game". I think you're on the right track of using gameplay to come up with a wattage. Do the testing with a few different cards and a pattern may emerge, something to the effect of, "Doom3 averages a GPU wattage that is 75% of the GPU's theoretical max. 3DMark is 95%, etc" That sort of testing you'd only have to do once, not everytime you testes a new heatsink.
There’s a complication here in that ATI & NVidia use very different methods for achieving the same ends due to their architectures being quite different. This is much more pronounced than the differences between AMD & Intel CPU designs I suggest. I say this because whereas C2D has pretty much got K8 beat across the board and by a significant margin, in the ATI versus Nvidia battle they both win certain battles (games) and lose others.
I agree that this has nothing to do per se with GPU heatsink efficiency, but if you intend to test a heatsink on a VGA card installed in a case, then it should influence how you approach this test.
There’s a good chance that game A is more power efficient on an ATI chip, whereas game B is more power efficient on a NVidia chip. This means that the reported GPU temps when used with a particular combination of heatsink and game may not be representative for most scenarios.
The way I see around this is to determine which game stresses a particular architecture the most and use that when testing a heatsink on a GPU built with that architecture.
The downside is that if you really want to perform real-world testing of GPU heatsinks, you need to test them on both GPU platforms using the most demanding game for each platform

The kick in the ass for this sort of testing is that GPU technology is evolving much faster than CPU technology and Games are also evolving more quickly than typical desktop applications. So keeping on top of this would be fairly demanding.
Then there’s the really murky area of how do all these CPUs, GPUs & heatsinks interact within the confines of a myriad of differing PC setups.

Rusty075 wrote:
Can of worms..can of worms indeed. :lol:
It’s starting to mutate into a great big bucket of writhing worms in front of my very eyes. Aaaaaaaaaaaaaaagh. :x


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 23, 2006 10:46 am 
Offline

Joined: Sun Jan 25, 2004 7:50 am
Posts: 308
Location: Moscow, Russia
However, with the release of Conroe, which is a significantly different architecture, things have changed. 2xCPUBurn no longer even approaches the heaviest load it is possible to put on the Conroe. Our testing showed it to dissipate about 35W — unbelievable on a chip with a TDP of 65W.
Well, there might be a simple answer to this: a single TDP rate is assigned to all models based on a particular core revision, no matter what the frequencies are. Knowing the frequency\temp dependency it's easy to conclude that only top models actually produce the declared amount of heat while lower freqency ones can be much cooler.

BTW, the same applies to max core temps.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 23, 2006 6:12 pm 
Offline
SPCR News Editor

Joined: Thu Feb 10, 2005 11:20 am
Posts: 2157
Location: TN, USA
If you use a die simulator is it necessary to test different source sizes?

Is a 4cm x 4cm heat source good enough? Is it better to test with a 3cm x 3cm AND a 5cmx5cm? Would you need all 3 sizes?

Die sizes vary widely in area and shape but with a heat spreader on the vast majority of them you could use a square or nearly square heat source and call it good.

Does testing off center matter? If so would you test off center in 1 direction, 2 directions, or 4?


http://www.overclockers.com/articles708/ seems to give good data that uniform tempature across the heat source is close enough to realworld when a heat spreader is involved.

http://www.procooling.com/index.php?fun ... s&disp=140 lists a large number of advantages and issues to using a copper block as the heat source. More than I'd be willing to copy here.

_________________
.
Please put a country in your profile if you haven't already.
This site is international but I'll assume you are in the US if you don't tell me otherwise.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Sep 06, 2006 5:25 pm 
Offline
*Lifetime Patron*

Joined: Mon May 23, 2005 7:05 am
Posts: 618
Location: State College, PA
Atomic PC (Aussie mag that I get here in NZ) uses a heat block to test all their heatsinks at 80W heat dissipation and compare the dC between different heatsinks. Couldn't find any details on their site here but I'm sure they'd be happy to share the details if anyone's interested. It certainly seems to be the most elegant way of testing any sort of heatsink and would get around the problems that arise when platforms change.

As for max power consumption figures - these are of considerable interest to me in terms of planning a system build, working out PSU ratings and the effect on my electricity bill. I work on the very rough assumption that CPU tasks scale similarly between platforms, so power consumption under "common" tasks isn't of huge interest. There's always the possibility that CPU A will complete a certain task in the same time using less power than CPU B, even though they have the same max consumption under Prime95, but how large that difference would be (and if it would be real world relevant) and who would be willing to test it is a different matter :)

tricky subject though..


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group