stephenbrooks.orgForumMuon1General30 Million-BILLION particle timesteps
Username: Password:
Search site:
Subscribe to thread via RSS
K`Tetch
2011-12-29 03:40:59
Just happened a few moments ago

Here's a brief piece about it http://muon1.blogspot.com/2011/12/300-million-billion-particle-timesteps.html
Zerberus
2011-12-29 04:47:57
Congrats!  Progress sure accelerates.

Yes, increasing computer power may have something to do with it.  Unfortunately, the latest simulations are so big that older machines simply cannot complete them in a timely manner.  Maybe the next generation of clients could adapt to high vs. low-end machines to some degree, e. g. lower machines preferring simulations that complete faster and high-end CPUs battling the monster simulations.

Edit: For me, it's still some minutes short before the milestone hits.  Maybe some correction?
[Edited by Zerberus at 2011-12-29 04:49:33]
K`Tetch
2011-12-29 05:36:43
I've been keeping track of it, seems ok.

And there's no way to tell the length of a simulation before it's simulated.  And unlike other forms of distributed computing, there's no 'time to return' (which you need in brute force to know when to write it off and re-assign).  I still do some sims with p3-based systems, works fine.  And we've been having 1800mpts+ simulations since PhaseRotLinac1 3 years ago (and until 2 years ago, my fastest system was a dual p3-550)

Zerberus
2011-12-30 02:38:21
It should know the length once it generated the simulation (I'm speaking about the physical length of the device, btw).  So a simulation with 450m will usually complete faster than one with over 700m. That's what I referred to.  Not possible?
K`Tetch
2011-12-30 03:06:55
But the length doesn't factor much into the calculation length (mpts).  I have 13 results in my results.txt, all 9X ones, and they range from 10.2Mpts to 632.1Mpts.  The 'physical length' is roughly the same, but one takes 20 seconds to run, the other takes 10-15 minutes.  That's what I meant by 'can't tell'.

And frankly, does it matter?  The only criteria is 'is it a better design'?

You'll notice that on most lattices, I'm near the back for yield (0.6% roughly for 9X), even though I am 14th for MPTS on 9X (and at one point, I was 4th).  I don't use the samplefiles, so I don't head off in the same direction as you lot.  I'll do some manual designs and tinkering, most of the time my results mean nothing to you and the others on a samplefile, but if I end up finding a new area of study, then you will all come looking

Perhaps suggesting that slow systems (or at least some of them) work independently, almost as a feeder system (or yield 'scouts' as it were) might be an idea.  The problem is most of us start chasing after the first good result we get and focus on that, risking getting stuck in a local maximum.  It's like thinking Snowdon is the biggest mountain because there's no bigger mountains in the local area (Wales) even though there's a bigger one in the UK (Ben Nevis).  Likewise there's a bigger one in Europe (Mount Blanc) and the biggest on Earth is Everest.  But even Everest is a local maximum, because Olympus Mons is bigger. 

So doing the low-yield scouting, effectively looking for mountain ranges at all, is perhaps a better use for the slower computers.  Once that's done, then the swarm can measure the heights of the peaks to see which is the tallest.  (This is also the reason the client does a random design every so often, so that there is a variation of designs to blend in with the existing ones.
Zerberus
2011-12-30 05:57:51
I run two clients simultaneously, each one on three cores.  One runs samplefiles, the other doesn't. So I get the best from both worlds.

But I'm no export, you are.  Just trying to help the project.  Currently the client tries to send with 50k of data, a value older machines may not even reach before the lattice is abandoned.  So maybe that policy should be tweaked instead (e. g. wait three days, then send what you have).
K`Tetch
2011-12-30 07:11:50
me, an expert?  HA!
You should see the kinds of conversations I have with Stephen!  I am someone who gets it, somewhat, and tries really hard to follow things.

Typically ,we're going through lattices every 5-6 months.  50 results or so is the autosend limit (depending on the lattice) and the yield/mpts graph shows about 1200mpts is the current 'high yield'. Let's say 1000 for ease (factoring in the randoms)
50 of them is 50,000 MPTS.

According to the benchmarking thread, a 1.6Ghz atom (pretty slow) does around 100kpts/sec.  so that's going to take 500,000 seconds, or 5.7 days.  If you go back to the system I build January 2000 (a dual p3-550) that did 32kpts/sec, so multiply by 3. 2 weeks, for a system that's almost 12 years old.  Half it again, and you've got the performance of my wife's old celeron 333, circa 1997. That's a month for a 15 year old system, that's far slower than my wife's cellphone.

And just because it's 'not active' doesn't mean the work is useless or rejected.  If you look at the lattice graphs page ( http://stephenbrooks.org/muon1/graphs/ ) you can see that some lattices are still getting results in, and being counted, several years after they've been taken off 'active' status.  At least one lattice has been re-activated based on late results.  Look at PhaseRotD for instance.  It was taken off active status some time in 2007, but in 2008 it got a yield boost.  PhaseRotB is still getting results back (over 1MPTS/sec, a bit faster than my q6600 system!) and that lattice started in mid-2004.

And, of course, you can always use manualsend.bat
[Edited by K`Tetch at 2011-12-30 07:17:21]
Zerberus
2012-01-02 14:29:21
Even manualsend needs 10000 bytes or it will reject sending.

Maybe we should introduce ''retro'' clients.  Weaker machines running older lattices.  Maybe one of them even takes a leap forward, miracles happen sometimes. 
K`Tetch
2012-01-02 18:52:28
Nah, it's really not an issue.  it's a day at most for a 1.6 atom between manual sends, and that's assuming a client running on the high-yield end of the projects.  And in doing the best lattices, I've noticed that the yields are a bit lower with 4.45 than 4.44d on the older lattices.  not by much, but a touch, but it's far more accurate (probably because of the peak being 'noise' (see the high-res scan thread)
Zerberus
2012-01-03 03:50:07
I may have observed a worst-case scenario then, with almost every simulation entering the ''5 rounds wash-rinse-repeat cycle'' aka re-run...
Stephen Brooks
2012-01-09 15:47:37
Yes, it takes a while on slower computers if it does that.  Remember it's still going to autosave every 4 minutes so you shouldn't lose much progress (even if the progress is slow!) Also remember the 5x rechecks can often be avoided if you have a modern sample file on that machine, because rechecks are only triggered if your first result gets a better score than anything in your local results store (including downloaded sample files).
K`Tetch
2012-01-11 07:06:57
Well, I think the problem is that some clients, on some lattices are still running 4.44, while the rest are on 4.45. I looked at the graph showing mpts against yield marked by client version, and I've noticed the 'tips' of the graph are 4.44's. They lead because of the 'noise' that was part of the 4.445 upgrade.

Also, something I've noticed myself is that the first run is often a better yield than the end design.  So it does what it thinks is a better design (because the 1-run yield is above the 5-run yield) but after 5 runs, it's below the initial threshold.

In fact it happened as I was typing this.
http://db.tt/cSxbDFdY
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel charactermstdn.io

Site has had 17092366 accesses.