 |
| Stephen Brooks 2004-10-05 07:38:06 | I've just uploaded v4.41c; the modification history is there. I'm not sending the 'upgrade prompt' signal out until a few people have tried it to make sure it doesn't give problems on their systems (I've had it running for a day or so and it seems to do everything fine here). Not a major update, this one, just more of a bug fix/maintenance thing. |
| [DPC]fenrir 2004-10-05 12:06:05 | at what time will you stop accepting the 4.41b results? or will you continue accepting these reults since there are no major changes in the client. |
| Stephen Brooks 2004-10-06 01:31:17 | There are only minor changes so I'm still accepting results. It's just that the optimisation might work slightly better with the new client. |
| kitsura 2004-10-06 03:29:19 | A timely upgrade. |
| [DPC]TeamNWW - Huub 2004-10-06 06:01:31 | OK.. i already had a couple crashes.. i am not sure yet what the problem was.. after running for a while and generating a coule of results, the background client would not start again after a reboot.. this was with a 10Mb+ results.dat file and a auto.sav file present.. i got the background client running again after removing the auto.sav file.. however.. it crashed on me again after maybe an hour.. i then removed the auto.sav file again and removed the results.dat file.. started again.. it now has been running smoothly for about 12 hours or so.. |
| Stephen Brooks 2004-10-06 06:54:42 | I got a crash today (after uploading it yesterday), though it hasn't yet repeated. The executable with debugging line trace switched on is now available here. Run that instead of your normal EXE (use the -b and -c switches to get background and commandline respectively). |
| [DPC]TeamNWW - Huub 2004-10-06 15:03:17 | ok.. silly question maybe.. but i had a crash with the debug client.. great error message.. but do i have to type it over or something? i couldn't find a log file or something like that.. |
| AySz88 2004-10-06 19:39:01 | Win XP Pentium 4 2.53 This is the error window I get, running it in the background: Title bar: lcc runtime: GP fault. Stack trace Message: 0 bmagnetfield [25] d:\sjb39\muon1\muon1.c 87 1 addbmagfield [4] d:\sjb39\muon1\muon1.c 160 2 fdt [10] d:\sjb39\muon1\muon1.c 17 3 advanceparticle [4] d:\sjb39\muon1\muon1.c 35 4 advancebeam_t [49] d:\sjb39\muon1\muon1.c 350 5 advancebeam [32] d:\sjb39\muon1\muon1.c 393 6 SVCLIB_main2 [124] d:\sjb39\muon1\muon1.c 184 7 WinMain [0] d:\sjb39\muon1\muon1.c 60 Current instruction: 0x439d07 |
| Stephen Brooks 2004-10-07 01:58:09 | OK, I've just had a look and fixed something that _might_ have been causing this due to floating point rounding oddities. The new version is called v4.41d and is available for download on the main page, also with its own debug EXE if you get crashes still. |
| Stephen Brooks 2004-10-09 07:59:38 | Well if no-one has any complaints about v4.41d before Oct-14 (and I'm testing it on 2 computers now), I'll send out the 'upgrade' signal to everyone. |
| [DPC] ZeRoC00L 2004-10-09 10:50:27 | No problems here with v4.41d. (i did have crashes with v4.41c, so the d version looks better crashproof !!) |
| Emery Cox 2004-10-10 19:03:51 | 4.41d (muon1.exe but not muon1_background.exe nor muon1_cmdline.bat) crashes for me before even displaying graphics. |
| Nexus 2004-10-11 00:09:17 | Neither one has crashed for me yet. But I didn't run 441c for very long. |
| [dpc]alphen 2004-10-11 01:38:55 | I have no problems with 4.41c but if I upgrade it to 4.41d muon keeps stopping after a few minutes. What could be the problem? |
| Stephen Brooks 2004-10-11 02:49:36 | If you have crashes with v4.41d, try substituting the debugging EXE for the normal muon1.exe (that is, store muon1.exe somewhere else and rename the debug one to "muon1.exe" so that the other two launchers [cmdline and background] will run it). Then if it produces an error box, take a screenshot or write down what it displays. If it quits without an error box it might help to run the commandline one via muon1 -c from a DOS window, so you can at least see at what stage it stopped. |
| Stephan Hermens[RKN] 2004-10-11 03:52:08 | Hello. I get this messages after a restart with the commandline. W:\priv\dc\muon>muon1 -c Muon1 started New simulation Searching for auto-saved file... Building proximity grid 6x2x50 (600 cells)... Done Restored simulation at 116.7ns - Starting - /* Debug Message Box */ lcc runtime: GP fault. Stack trace 0 bmagnetfield [10] d:\sjb39\muon1\muon1.c 72 1 addbmagnetfield [4] d:\sjb39\muon1\muon1.c 160 2 fdt [10] d:\sjb39\muon1\muon1.c 17 3 advanceparticle [4] d:\sjb39\muon1\muon1.c 35 4 advancebeam_t [49] d:\sjb39\muon1\muon1.c 350 5 advancebeam [32] d:\sjb39\muon1\muon1.c 393 6 SBCLIB_main2 [124] d:\sjb39\muon1\muon1.c 184 7 WinMain [0] d:\sjb39\muon1\muon1.c 60 Current instuction: 0x439a2d I made a backup of the .sav-file, if you need it for testing. Good luck bug hunting Stephan |
| Stephen Brooks 2004-10-11 05:00:14 | If you delete the old .sav file does this error still happen? |
| spldart 2004-10-11 06:26:59 | Been running D on my dually now for a day and no problems. It is running 1% slower than the previous client. |
| Stephan Hermens[RKN] 2004-10-11 06:46:31 | quote: It starts up ok and begins with a new simuation. Another machine crashed a while after restarting from 17 ns. I get this after restart from the latest .sav file: W:\priv\muon4.4>muon1 -c Muon1 started New simulation Searching for auto-saved file... Building proximity grid 4x2x50 (400 cells)... Done Restored simulation at 102.1ns - Starting - t = 108.75ns (1243/76288 particles) 51.2 Mpts The debugging Stack trace is the same. Here are some of my conclusions from what I saw. In both cases the client crashes on the simulation of ChicaneLinacB atfer restarts at some point. Notice that the simulation now runs up to 108.75 ns when the first particles enter the bending chicanes (if I recall correctly). The simulation I posted previously had run from start to 118 ns when I shut the system down. Here the particles were already in the bending chicane, so the client crashed immediatly. My guess is that some part of the parameters used in the line where the crash occurs doesn't get properly reinitialized when the save file is read. The error therefore is probably somewhere in the routine for restarting from a save file. Or the routines writing and reding the save file are not working together properly. Good luck bug hunting Stephan |
| Stephen Brooks 2004-10-11 06:49:22 | Yeah I was coming to just the same conclusion as I came back. In v4.41c,d I moved a module-initialisation command out of the main routine and into the module itself, which is neater, but it didn't detect it needed to be initialised when an autosave is being recovered. The module in question is the chicane magnets. I'll try fixing this and releasing an *e version... |
| Stephen Brooks 2004-10-11 08:35:48 | OK, there's now a v4.41e up for download. I'll be waiting for reports of any problems for the next week or so, before I put out the signal asking everyone to download. |
| Emery Cox 2004-10-13 21:38:43 | In muon1.exe (v4.41e), something flashed by like "[FATAL] unable to delete result from non-existant queue." |
| UnderTitan 2004-10-14 00:31:37 | Stephen, 441e seems to work a LOT faster than 441b, so far. I'm using the same computer, and the ns are just flying! |
| kitsura 2004-10-14 07:33:55 | Have tested ChicaneLinac and PhaseRot for 24 hours each both seem quite stable so why is it still considered beta? |
| Stephen Brooks 2004-10-14 07:39:30 | --["[FATAL] unable to delete result from non-existant queue."]-- Did you put your auto*.sav file in the new version but not the queue.txt or something? This will happen also if you decide to delete queue.txt while the program is running a result that it thinks ought to be in the queue. As for it going faster, am I right in thinking that it's going faster when the t=500ns or more? That's because I increased the time threshold for ChicaneLinacB and towards the end it'll not be simulating very many particles. |
| Stephen Brooks 2004-10-14 07:43:06 | It'll come out of beta in a few days if no further issues are found. It has crashed a couple of times in weird ways here... or at least not given a line number output. It could be XP SP2 doing that, somehow. |
| kitsura 2004-10-14 09:12:52 | You installed that piece of crap SP2? I won't install something that breaks the functionality of my current OS as well as _not_ fix the existing vulnerabilities. We are all better without it. |
| Stephen Brooks 2004-10-18 03:36:54 | Well I'd got a reply to you saying "Save it for the Slashdot forums" ready to send in my browser, but then kinda got distracted and released another version of Muon1 instead. I agree there are some oddities with SP2 but I'm now pretty sure these weren't crashing Muon. Basically, Windows won't be secure until all its applications are secure, so Microsoft changing the rules as to how you can execute unsafe code is alright in my opinion, and the fix for it is pretty trivial (replace malloc by VirtualMalloc or something like that). I don't do anything of the sort in my programs. The thing that really confused me personally is why, after I'd spent about an hour waiting for it to contact the server and download the huge thing, did the patch include updates for MineSweeper and the Windows Screensavers?! Did they just TAR their new Windows install and send it to us over the net or what? Also it included a number of amusing but useless things like Windows-coloured shields that pop up when I try to open a Word document attachment from an e-mail  The thing I thought was going to give me problems, particularly on the Muon Server, was the Windows Firewall, but actually I just made exceptions for the 3 FTP programs I use and it's fine now. (Though I'm not sure how much of a firewall it is any more if it lets FTP.exe through...) |
| Stephen Brooks 2004-10-18 03:39:38 | I'm hoping v4.41f will be the definitive stable new Muon1 now, as it's basically v4.41e (which passed 7 days in beta) with a small feature added that I doubt interacts with anything else. |
| [DPC]fenrir 2004-10-18 12:43:48 | I believe I discovered the small feature, nice feature. I can't tell if it is faster though, since I haven't run any benches on this system with this client and older clients. but sofar it is working  will the next addition be a client that can be run as a service? |
| Stephen Brooks 2004-10-18 13:38:29 | It won't make existing properly-configured systems faster, but what it will do is make it a lot easier to deploy Muon1 to a hetrogenous farm of computers (AMD, Intel, with and without hyperthreading, single, dual or quad socket, single or dual core etc.) without having to configure each individually. It'll also be good for people who don't know much about the innards of their PC, as it'll just work out of the box. |
| kitsura 2004-10-18 13:47:44 | But you still have to configure it to run as a service which is a pain. So its not really able to run out of the box just yet. |
| Stephen Brooks 2004-10-19 03:39:34 | Yes, I don't know anything about services, so you'll have to figure out your own way of doing that still. What I was saying was that you could now just copy the Muon1 install directory straight onto the machines and not have to touch config.txt. Copying a muon1_background.exe shortcut into the 'startup' folder would make it run automatically. So now it's just moving the same files onto each computer rather than doing anything specific for each one. |
| RoyalFlusher 2004-10-19 05:53:26 | So, if I understand correctly, the line threads=x is now obsolete? |
| kitsura 2004-10-19 06:09:48 | quote: I use MS Srvany utility to configure dpad to run as a service as on my Win2k and XP boxes. The upside to this is that it can be run without having anyone login to the PC. Of course Win9x still has to depend on the startup folder or registry to launch but then there is no real need to login to Win9x PCs so by default they will startup to the desktop. |
| The_Mule 2004-10-20 00:00:15 | The new version v441F still crashes on some of my systems. Is there a debug-version available so I can send u the errors that they generate? Now I have just the standard Windows-message... |
| Stephen Brooks 2004-10-20 11:35:41 | quote:Well for nearly all cases, writing "Threads [,,,]: auto" should do the correct thing. Some people have found that by playing around with other numbers of threads - for instance by running 4 on a HT processor instead of the expected 2, they can squeeze an extra percent of performance out, but that's all very platform specific. I leave the feature in there so people can at least play with these things. Also, it means you can (if you want) partition one multi-processor machine to have N processors on Muon1 and use the rest for either your work or other projects. |
| [TNT]danzigrules 2004-10-24 09:36:30 | so if I want to upgrade, do I just overwrite all the files in my current muon folder? I won't lose the work that I have already done, in the results? Thanks |
| Stephen Brooks 2004-10-24 11:16:34 | Since the install archive doesn't have any results.txt results.dat or user.txt, these files will remain when you extract 'on top of' your current install. |
| [TNT]danzigrules 2004-10-24 11:18:26 | ok thanks Stephen |
| Pascal 2004-11-14 03:26:12 | Did anyone already check the thing with the number of threads? I have two Athlon machines, lets have a look at this.. |
