stephenbrooks.org : v4.44b released

Xanathorn

Tue, 18 Dec 2007 22:51:00 +0000

[[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.

[DPC]DanC

Tue, 18 Dec 2007 20:24:28 +0000

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.

Stephen Brooks

Tue, 18 Dec 2007 16:16:28 +0000

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.

Stephen Brooks

Tue, 18 Dec 2007 16:10:25 +0000

It could be manualsend then. You mean it took both? I'll try triggering either way.

Rgtx

Tue, 18 Dec 2007 12:56:22 +0000

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

Tue, 18 Dec 2007 12:41:31 +0000

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?

Xanathorn

Tue, 18 Dec 2007 11:56:48 +0000

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?

Meloentje

Tue, 18 Dec 2007 11:05:20 +0000

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.

Stephen Brooks

Tue, 18 Dec 2007 10:47:21 +0000

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.

Stephen Brooks

Tue, 18 Dec 2007 10:46:36 +0000

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.

adalbert.b

Tue, 18 Dec 2007 10:36:25 +0000

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 Auto-saving... t = 721.72ns (48145/48145 particles) 0.0 Mpts Auto-saving... t = 752.78ns (48145/48145 particles) 0.0 Mpts cpu-consumption is 90%, but it don't seem like any particles are calculated

[DPC]DanC

Tue, 18 Dec 2007 01:20:17 +0000

hmmm... 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.

Rgtx

Mon, 17 Dec 2007 22:14:06 +0000

Just to confirm that I was running the v4.44b client: tantalumrodz=445;d1l=000;d2l=002;d3l=000;d4l=001;d5l=001;d6l=000;... 2.982972 (364.8 Mpts) [v4.44b] <PhaseRotEb1a> {11D3FC4871D2394AA3D17C5B} #gen=0;tantalumrodz=437;tantalumrodr=689;decaycells=760;s1l=190;s1f... -2.000000 (0.0 Mpts) [v4.44b] <PhaseRotEb1a> {611923A440A33376DC01C2DE}

[DPC]DanC

Mon, 17 Dec 2007 22:00:51 +0000

In a rare first for me - 444b appears to be running flawlessly on an old t-bird and a PIII. No issues thus far.

Rgtx

Mon, 17 Dec 2007 21:58:02 +0000

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.

Stephen Brooks

Mon, 17 Dec 2007 19:36:43 +0000

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.