Join PrimeGrid
Returning Participants
Community
Leader Boards
Results
Other
drummers-lowrise
|
1)
Message boards :
Number crunching :
PrimeGrid's 16th Birthday Challenge
(Message 150637)
Posted 717 days ago by Eric Nietering
My 3900X is set up to run 4x 3 threads. Getting 14 to 14-and-a-half hours per WU. Ran a couple ahead of time at 1x 12 threads - just over 5 hours on those. Not nearly as much throughput that way. What times are you seeing running 2x 6 threads?
I do have each 3 thread task tied to a CCX using taskset in linux. All cores run at about 3870 MHz fully loaded like this.
And is it just me, or does the birthday cake banner only have 15 candles?
|
2)
Message boards :
Number crunching :
Good Riddance 2020! Challenge
(Message 147642)
Posted 865 days ago by Eric Nietering
I'm starting to see some 512K FFTs - ~10% longer runtime, with a ~10% credit increase.
480K task: https://www.primegrid.com/result.php?resultid=1171021330
512K task: https://www.primegrid.com/result.php?resultid=1171689363
|
3)
Message boards :
Number crunching :
2019 Tour de Primes
(Message 125870)
Posted 1582 days ago by Eric Nietering
D'oh!
47911922^65536+1 (Eric Nietering)
Time reported or deadline
31 Jan 2019 | 21:40:08 UTC
|
4)
Message boards :
Number crunching :
2019 Tour de Primes
(Message 125635)
Posted 1584 days ago by Eric Nietering
Summary
Tue Jan 29, 19 at 4:00 PM CST
Tonight
Clear. Local blowing snow in open areas early this evening. Wind north 30 km/h becoming light this evening. Low minus 39. Wind chill minus 48 in the evening and minus 53 overnight. Hazardous frostbite conditions.
Wednesday
Sunny. Wind up to 15 km/h. High minus 30. Wind chill minus 49 in the morning and minus 39 in the afternoon. Frostbite in minutes. UV index 1 or low.
Wednesday night
Clear. Becoming partly cloudy before morning. Wind up to 15 km/h. Low minus 35. Wind chill near minus 43. Frostbite in minutes.
It's not quite as cold here, but I revved my machines up a couple days early, too:
Overnight
Scattered flurries with isolated snow showers before 5am, then scattered flurries after 5am. Areas of blowing snow. Mostly cloudy, with a low around -23. Wind chill values as low as -45. Breezy, with a west wind 15 to 20 mph, with gusts as high as 30 mph. Chance of precipitation is 20%.
Wednesday
Areas of blowing snow before 4pm. Mostly sunny and cold, with a high near -14. Wind chill values as low as -52. Breezy, with a west wind 15 to 20 mph, with gusts as high as 30 mph.
Wednesday Night
Mostly clear, with a low around -24. Wind chill values as low as -40. West southwest wind 5 to 15 mph, with gusts as high as 20 mph.
Thursday
A 20 percent chance of snow after noon. Increasing clouds and cold, with a high near 0. Wind chill values as low as -40. West southwest wind 5 to 10 mph becoming south in the afternoon.
Thursday Night
Snow likely, mainly before midnight. Cloudy, with a low around -1. East southeast wind around 5 mph, with gusts as high as 10 mph. Chance of precipitation is 70%.
|
5)
Message boards :
Number crunching :
Setting core affinities: Linux, GFN multi-threading
(Message 124062)
Posted 1614 days ago by Eric Nietering
They all operate in the same basic format. They keep track of which of the slots are occupied, wake up every 30 seconds to see if any new tasks have started, and assign them to the newly opened slots. The timing can be adjusted, of course - you need to compromise running frequently (to handle new tasks sooner) with only running occasionally (to not waste a much CPU time).
You will want to check out the inotify filesystem event interface.
man inotify
There are lots of ways to access this, for example using the inotify-tools package in Mint/Ubuntu/Debian.
In your case, you might prefer to use a Perl module like Filesys::Notify::Simple, one of a few options you will uncover with the search terms notify perl in Synaptic.
Thanks! I'll have to check that out. I've used something that appears to be similar at work, but in the .NET land from Microsoft.
If/when I've gotten something working, I'll post back with some details.
|
6)
Message boards :
Number crunching :
Setting core affinities: Linux, GFN multi-threading
(Message 123963)
Posted 1621 days ago by Eric Nietering
I've had a dual CPU machine for about 2 years, and have had a bit of experience with this sort of thing. I use the taskset and top commands that River~~ mentioned, as well as mpstat, which is tells you which logical CPUs are busy. The lstopo program mentioned is also instrumental in determining which CPUs are paired together. In Debian and Ubuntu based systems, it's available in the hwloc package.
My computer is this one. It has two hex-core Intel Xeons, with hyperthreading, for a total of 24 virtual CPUs presented to the operating system.
Using lstopo, I found that the physical CPU cores are formed by the logical core pairs (0,12), (1,13), (2, 14), ... (11, 23). The first six of these pairs are found on physical CPU 0, and the remaining six pairs on physical CPU 1. So if we want to ignore the extra virtual cores, we can limit things to logical CPUs 0-11. As River~~ mentioned, this may be CPU and/or motherboard dependent (and perhaps linux version as well), so be sure to check.
On my AMD systems, the cores tend to be in pairs like (0, 1), (2, 3), (4, 5)..., so to fill every physical core, we need to assign threads to only the even or odd numbered logical CPUs, but not both.
The mpstat command gives details about the usage of each virtual CPU. It can do long term averaging, and give you details of only particular CPUs, and all sorts of things. An easy way to start, however, is:
mpstat -P ALL 1 1
This will print out (twice) the list of all CPUs (including a total at the top), and their usage broken down into the various bins that linux keeps track of. Very useful to verify that your configuration is working properly. On my system, with everything working right, I see CPUs 0-11 loaded at 100%, and 12-23 generally pretty lightly loaded, but often not quite zero, depending on what the OS is doing or what other programs are running.
I have written a handful of perl scripts to attempt to manage this sort of thing for me. They differ only in the number of tasks I want running at once. For instance, for large LLR tasks I want to be running two at 6 threads each. For medium LLR tasks, four at 3 threads apiece is good, and for the smaller ones, 6 at 2 threads each. I also have a setup for twelve at 1 thread each, though that isn't used much anymore. I also have one for 24 tasks at 1 thread each, for sieving challenges.
They all operate in the same basic format. They keep track of which of the slots are occupied, wake up every 30 seconds to see if any new tasks have started, and assign them to the newly opened slots. The timing can be adjusted, of course - you need to compromise running frequently (to handle new tasks sooner) with only running occasionally (to not waste a much CPU time).
There's a difference I noticed due to this challenge, between the CPU GFN21 program and the LLR program that is used elsewhere. As River~~ mentioned, the GFN21 application has an "overhead" thread. This thread is the second thread created, I've found. When running, say, six computation threads, there will be seven threads under the parent process. The first, and third through seventh threads are the computation threads, and the second thread is the overhead thread. This is different to how LLR works, where there's a separate process (the executable has "wrapper" in the name) that handles the overhead, and only the compute threads are handled by the second (non-wrapper) process.
As River~~ mentioned, if the linux scheduler is working properly, this doesn't add up to much benefit. However, if by default the scheduler is doing some not so smart stuff, the gains can be much greater.
|
7)
Message boards :
Generalized Cullen/Woodall prime search :
Benchmarks for GCW Sieve
(Message 103223)
Posted 2337 days ago by Eric Nietering
I can verify that the 64 bit application is much faster than the 32 bit one. I have a 2006 era Core 2 Duo system that I fire up for challenges. The installed OS is 32 bit Win-XP, but after reading through this thread I popped in a 64 bit linux live CD. It runs pretty much twice as fast. I imagine part of it is the upgrade to a modern linux kernel from the older-than-dirt Win-XP, but most of it is the change from 32 to 64 bits.
16 GCW-Sieve tasks on 32-bit WinXP averaged about 13663 seconds each. Computer/Tasks
16 recent GCW-Sieve tasks on 64-bit Xubuntu averaged about 6522 seconds each. Computer/Tasks
Normally it doesn't contribute a whole lot to my total challenge scores, but it's holding its own this time - within spitting distance of the i5 Sandy Bridge and the OC'd FX 8320.
|
8)
Message boards :
Generalized Fermat Prime Search :
GFN Status by n-Range (17-22)
(Message 90192)
Posted 2737 days ago by Eric Nietering
Looks like a few of the GFN-18 WUs are dropping out of the fast transforms, all the way down to x87 in some cases:
b = 1232796; 92K seconds vs. ~30K seconds normally: http://www.primegrid.com/result.php?resultid=667409629
b = 1237842; 76K seconds vs. ~18K seconds normally: http://www.primegrid.com/result.php?resultid=667635485
b = 1233608; 90K seconds vs. ~10K seconds normally: http://www.primegrid.com/result.php?resultid=667438497
|
9)
Message boards :
Number crunching :
Solar Eclipse Challenge
(Message 84477)
Posted 2985 days ago by Eric Nietering
If you (or anybody else) is interested in the issues that capacitors can cause, this website is an excellent resource: http://www.badcaps.net/. My guess as to what happened is that one or more of the CPU VRM caps had been failing for some time. Heat speeds this process up, and CPUs generate plenty of heat. After a while (months? years? who knows) of getting noisier and noisier power, the CPU couldn't handle it anymore. If the power supply is ok, chances are good that everything else is too. The motherboard might even be able to be saved.
Good luck with your new system!
|
10)
Message boards :
Number crunching :
Solar Eclipse Challenge
(Message 84163)
Posted 2997 days ago by Eric Nietering
I've got this computer: http://www.primegrid.com/show_host_detail.php?hostid=431181 which has an FX-8320. I have the second core in each module disabled (through the BIOS), leaving me with 4 cores. I have it overclocked to 4.4GHz. I left the base clock at 200MHz, and cranked the multiplier up to 22x.
The memory is 2x 4GB Crucial Tactical Tracer DDR3-1866 running at 2133MHz Dual Channel. Again I left the base clock the same and upped the multiplier.
The disk is a 128GB Samsung 830 SSD, on SATAIII.
Most of the SR5 WUs (480K and 512K FFTs) are taking 6.5-7 hours. There are a few that have been shorter: Ones with 448K FFTs run just over 6 hours, and the one with the 384K FFT was just over 5 hours.
At the default clock frequencies, things will take a little longer. I would expect a stock 8350 to take about 10% longer, and a stock 8320 to take about 20% longer.
Hope this helps!
Eric
|
Next 10 posts
|
