stephenbrooks.orgForumMuon1Generalv4.44b released
Username: Password:
Search site:
Subscribe to thread via RSS
Stephen Brooks
2007-12-17 19:36:43
I've made this improved version available now.  Not sure if it's quite fixed all our problems but I switched off the compiler switch that was causing older computers to crash.  If a few people could try it and see whether they get "bad" -2%/0Mpts results, that would be helpful.  You may also see the version history.
2007-12-17 21:58:02
Good news and bad news, first the bad news, its back to the drawing board for you, the good news, I have a screenshot of the fault condition.
2007-12-17 22:00:51
In a rare first for me - 444b appears to be running flawlessly on an old t-bird and a PIII.  No issues thus far.
2007-12-17 22:14:06
Just to confirm that I was running the v4.44b client:

2.982972 (364.8 Mpts) [v4.44b] <PhaseRotEb1a> {11D3FC4871D2394AA3D17C5B}
-2.000000 (0.0 Mpts) [v4.44b] <PhaseRotEb1a> {611923A440A33376DC01C2DE}
2007-12-18 01:20:17

Working on 3 machines - but not on the 4th.  Strange phenomena... -2.0000000 all the way down the line.
This was happening with 4.44a - upgraded to b... same stuff.

This is an Athlon 3800+ running WinXP.
The other three seem just fine with things.  Semperon 1.6, T-bird 1.2, and Duron 950. All on XP.
2007-12-18 10:36:25
i'm just calculating such a result:

Interpreting lattice file 'PhaseRotEb1a'... Done
Beamline consists of 100 units, genome of 51 parameters
Using seed 0+1*2 = 2
Adding components to simulation space
Tantalum rod source data loaded.
Building proximity grid 3x3x50 (450 cells)... Done
Tracking central particle to synchronise RF phases... Done
Done adding components
Determining nearby components...
Normalising beam...
- Starting -
t = 331.06ns (48145/48145 particles) 0.0 Mpts
t = 721.72ns (48145/48145 particles) 0.0 Mpts
t = 752.78ns (48145/48145 particles) 0.0 Mpts

cpu-consumption is 90%, but it don't seem like any particles are calculated
Stephen Brooks
2007-12-18 10:46:36
I think you'll find if you restart Muon1 it'll produce good results for a while.  Today I'm going to try and replicate this effect.
Stephen Brooks
2007-12-18 10:47:21
Yes they are apparently stuck on the rod all the time!  So the program just goes to check if they have started yet, without any of them leaving.
2007-12-18 11:05:20
It's still takes a very long time to send results!
After installing 4.44b I moved the results from 4.44a to the 4.44b directory and executed manualsend.bat and it took a very long time to send 54 results.
2007-12-18 11:56:48
The client's also about 20% slower, now takes 2.5 hours on a rerun instead of 2 hours (output dropped from 960 kpts/sec to 800 kpts/sec measured over 14 hours).  Could that be because off the turned off optimiser?
Stephen Brooks
2007-12-18 12:41:31
Slower compared to 4.44/a or 4.43d?  I benchmarked the original 4.44 to make sure the Mpts rate was about the same, but this version probably changes that.  There's some strange CPU utilisation behaviour as well.

I can't replicated the -2% bug so far just by running the program.  Did these results start happening after a send or something?
2007-12-18 12:56:22
Yesterday, to trigger the fault condition, whilst the client was running I made and saved a small change to config.txt then performed a manual send.  The optimization then running completed successfully, subsequent results being of the -2%/0Mpt flavour.
Stephen Brooks
2007-12-18 16:10:25
It could be manualsend then.  You mean it took both?  I'll try triggering either way.
Stephen Brooks
2007-12-18 16:16:28
I've just noticed mine started doing it here (after a long time).  Checking sendlog.log revealed a send took place!  So I think that's the clue.
2007-12-18 20:24:28
Definitely a "send" issue Stephen.  I duplicated it on two machines using manual send.  It seems to begin to behave again if you kill the process, delete the results.txt and any autosave file - then restart.

I always do a manualsend - so I don't know if it manifests with autosend.
2007-12-18 22:51:00
[[Slower compared to 4.44/a or 4.43d?]]

Compared to both.  V4.43d and V4.44a were both 960 kpts/sec per core and now V4.44b it's 800 kpts/sec per core (measured over 24 hours now).  Also noticed with some simulations memory usage was abnormally high, sometimes up to 120 megabytes per client, whilst usually it's about 20-25 megabytes per client.
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel RSS feed

Site has had 22186058 accesses.