Re: Mersenne: preventive measures
Aaron Blosser wrote: [the prime95 icon is ] mostly RED which would have been a good "alert" color. Maybe slowly flashing YELLOW or something, or make is usually GREEN then YELLOW for messages and RED for big problems. Is there an "official international math color?" Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: preventive measures
The point is that I certainly couldn't accept software coming in from outside being run without any sort of intervention; however, I'm quite happy to manually download a new version, virus check it place it in a secure local filestore for people to update automatically, if they wish. So you would just leave the feature disabled then. I would be more than happy to let it update manually, anything the virus checker dosn't spot on the fly during the update, it wont spot on a file scan either so that isn't a problem. And for those people out there who don't use one, well they wont find virii whatever method is used for update. Actually the main problem is that many users seem to manage to operate without an unZIPping utility anywhere on their command path... this makes it hard to write a procedure which will work for all users, if the update package is a .ZIP file. So I'm probably going to have to unZIP the file place the constituent files in local file store anyway. Might as well run a couple of virus scans whilst I'm at it... So make it a self extractor, where is the problem in that? In fact if it is going to self extract you could compress with rar instead of zip and increase the compression a bit. -- James Smith [EMAIL PROTECTED] Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: preventive measures
OK, I haven't been following this thread so this may have already been mentioned and discarded, but how about some sort of "auto update" feature. It could be turned on/off in the options and would enable people to run almost unattended with updates coming either as and when required, or they could be set to occur in tandem with an exponent update. I appreciate that most software updates require the software to be stopped during update then started again afterwards, but would it not be possible for the update to update the required files to temporary ones, that replace the old ones on the next reboot using win9x runonce facility in the registry. e.g.. the updates being prime95.new etc. I know this means the updates only happen at the reboot, but who can convince a win 9x machine to run longer than 8 hours without one anyway? (off topic - have you seen the "continuous running fix" for win98 yet? no joke, It fixes a bug that causes the computer to lock up after 49.7 days. 49.7 days? I cant get mine to last 49.7 hours!) Another method would have to be found for updating the OS2 / Linux etc. clients, but I am sure there must be one. -- James Smith [EMAIL PROTECTED] Yes, actually that's more what I had in mind. I thought that maybe there could be a little status bar at the bottom of the Prime95 window that scrolls important information or something. I like the bit about having the icon change color, but it's already mostly RED which would have been a good "alert" color. Maybe slowly flashing YELLOW or something, or make is usually GREEN then YELLOW for messages and RED for big problems. For folks running this on a lot of machines, you'd obviously just turn this feature off on most of them, only keeping it turned on for your own personal machines. Well, these are all good thoughts, let's see what George and Scott can do...they've already done so much as it is. Aaron Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: preventive measures
How about this?: If mprime finds that it needs to update itself, it downloads the new files, renames the old ones, renames the new ones, and quits at five 'til. One minute past the hour, a cron job notices that mprime isn't running and restarts it. phma Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: preventive measures
On Mon, Apr 12, 1999 at 09:30:12PM -0500, Amy and Shane Sanford wrote: A easy way with any OS that has some sort of easy batch file support (such as the flavors of Windows from what I remember Unix). Have the Prime program download the files to the current directory (maybe a self executable zip file). Then execute the download. The download will unzip all the files including a batch file which when launched will replace the nessecary files with the new ones. The orginal prime program then would launch the batch file (maybe with a execution delay of 2 seconds) then close itself (and unload any .dlls if nessecary). The Batch file then takes over with the file updates, cleans up the mess, and then launches the new prime program before it closes. The problem really is NOT solving the technical problem of how to update the program on the fly. That's a bit challenging, sure, but it's really not all that hard. The real problem is ensuring that this scheme is secure. When there's no human being in the loop, the system becomes ripe for abuse. For example, I could use established DNS poisoning attacks to redirect ftp.mersenne.org (or wherever the software is automatically downloaded from) to a host of my choosing, and provide malicious software there posing as an "update" to the mersenne software. Then your computer would happily dowload and install my evil program! Any automatic executable download system is suceptible to this problem in some form or another, unless it provides some form of cryptographic signature or other verifiability check. But doing things like that runs afoul of the US government's medieval crypto policy. Now, providing a method for one person to automatically update a bunch of remote computers they control is something else entirely, and that does not have the same security implications. For example, Aaron Blosser installed prime95 on 3000 (or so) Windows computers from his desktop, using remote administration software. I've done similar things on Solaris (Unix) here at school, to run Distributed.net's client software. Anyways, what does this have to do with Mersenne primes? -andy -- Andy Isaacson [EMAIL PROTECTED] [EMAIL PROTECTED]Fight Spam, join CAUCE: http://www.csl.mtu.edu/~adisaacs/ http://www.cauce.org/ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
RE: Mersenne: preventive measures
At 08:41 AM 1999/04/10 -0600, "Aaron Blosser" [EMAIL PROTECTED] wrote: George...is it too late to request features for the new version? I had done some thinking on it, and wouldn't it be great if there were some sort of "live update" feature, where it could upgrade itself when new versions come out. That's pie in the sky and I remember discussing previously how that wouldn't work for everyone - security issues, bandwidth issues, etc. but perhaps if it were an option. This feature would have meant that V17 shift count bug would have cost the project more cpu years than it did. In my case, its impact is a little under 1 cpu year (one exponent in the 10.5M area) because most processors I'm running were at older versions. There is a publicly available service which checks for changes in web pages, and sends email when a checked page changes. I think Internet Explorer V5 supports some sort of favorite-page-change detection too. This combined with being able to remotely stop an NT service and deposit updated files from a batch procedure on one workstation makes managing large numbers of workstations practical and quick. At the very least, I think that there should be an "alert" or other notification of some sort when a new version comes out, rather than relying on emails being sent. The problems with version 17 should give a good example of how that would help. A problem is found with a version, or simply a new faster version is out, so the next time Prime contacts Primenet, it sees some flag set and pops up a box on the screen telling the user about the new version. And a seperate option for how often to check for "messages" besides the number of days between checking in at primenet to update expected completion dates. I would find a popup box a terrible nuisance, so I'd like an option to turn it off or on, with default off. The feature I'd like to see at some point is the LLtest code made dual-cpu aware, splitting the load so one cpu does one half of the run-length and the other cpu does the other half, so that the onboard and on-chip caches would be more efficiently used, and total working set smaller, and exponents completed more quickly. I have a dual-pentium 200 MMX that isn't terribly fast when running two prime95 instances on exponents above 10^7. The performance on the dual-pentium or dual-ppro systems I have access to is, when running two instances, about 1.6 times that of running 1 instance. So there is some room for improvement. On this setup, there are 2 L1 caches, but one L2 cache being shared by two prime95 instances. Ken Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
RE: Mersenne: preventive measures
At 12:45 PM 1999/04/11 -0600, Aaron Blosser wrote: ... IE4 and IE5 have that (probably Netscape too?), and I think the web site that checks and sends emails is www.mindit.com. mindit.com is not the one I was thinking of; there's one based in a US university (Dartmouth?). This combined with being able to remotely stop an NT service and deposit updated files from a batch procedure on one workstation makes managing large numbers of workstations practical and quick. Remember, you're talking to a guy who installed thousands of instances of NTPrime remotely, across 3 different states, in a matter of days (using nothing more than 4NT batch files and RCMD/NETSVC programs from the resource kit). But we won't go there. :-) I'm not saying it can't be done, but it'd be so much easier with some sort of built-in method for self-updates. I remember. It can be done with less (just what's built in to NTWS). I would find a popup box a terrible nuisance, so I'd like an option to turn it off or on, with default off. If it were an option, there should be a way for REALLY important alerts to get through, so that anyone running v17 would have been alerted about the bug even if normal alerting were turned off. Wouldn't you rather have some exceptions get through, with the decision about what qualifies as "exceptional" being made by George and/or Scott? No. I would not want it popping up on each of my computers, requiring a mouse click on each; too tedious. Email is sufficient. A popup for each instance on each multiple-cpu system is really a nuisance. Imagine if USWest had seen 2500 of those popups on the same day. VIRUS!!! Lynch whoever's responsible!! The feature I'd like to see at some point is the LLtest code made dual-cpu aware ... Amen. In fact, if it were possible to code it to split the work among multiple CPU's in any way, then it *is* technically possible to have even seperate machines work on the same number, though you'd be limited by the network link speed. I think even gigabit ethernet would be insufficient. Networking means driver overhead. The point of doing it is to regain efficiency and reduce total runtime of one exponent so it's small compared to the machine's working lifetime, even for 8-digit exponents. Consider. If you had a chip with multiple FPU engines, couldn't you code the program to take advantage of that? From there, it's only a small step to using the FPU processors on *seperate* CPU's, and from there, given a fast enough link, seperate CPU's on entirely different machines. Several big if's. Factoring could easily be parallelized, since it consists of 16 passes. And the total amount of data being transported is very small. Ken Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: preventive measures
Hi all, At 04:56 PM 4/3/99 -0600, Ken Kriesel wrote: Since we now have a wealth of exponents to be tested or retested, requiring a total expenditure of billions of cpu-hours, perhaps we could introduce a little more formalism into the program-validation process. I volunteered months ago to test 1 or 2 exponents in each runlength. Several have completed. Brian Beesley offered to double-check my results, and George has assigned them to Brian as double-checks. The nature of the just-discovered bug suggests that more test cases are in order. I propose the following be considered, for each future version released (and for the versions in heavy use currently): 1. Code review by qualified volunteers. A good idea for the C code, I doubt the assembly code qualifies. 2. George and such other people as are qualified, determine which exponents make good test cases, based on a review of the code. My input: 1) Those near the end of each range should be checked for excessive convolution error. In fact, it would be nice it the QA suite recommended the crossover points for the FFTs. 2) Exponents that are close to a multiple of the FFT length. Crandall's "magic numbers" are very sensitive here. 3. Volunteers with some cpu-power run LLtests and double-checks on the test cases selected. As pointed out earlier, a few hundred iterations *should* suffice. But Ken may decide a few more lengthy checks are required. And as v17 pointed out, the shifting code needs to be checked in the above tests. Since this project is in a sense George's baby, I feel he has the right to ok or nix this. If he says ok, I volunteer to be the contact point for volunteers to enlist as either code reviewers, testers, or both. After a week or two I will summarize to George. OK, I never turn down a volunteer! I hereby appint Ken the coordinator of the official GIMPS QA project. First order of business is a plan of action - formulating the QA test suite. How much CPU power are we going to require? Would enough tests to keep 5 volunteers busy for 24 hours suffice? Will the ports run shorter suites? This QA suite will not be my baby, so don't be shy folks in chiming in with ideas or offering to help Ken out. I'll put in whatever hooks you folks need. Now for some good news Prime95 v19 is under way. It involves rewriting ALL the FFT code! So this QA project is quite timely. What's new in v19? It should support FFT lengths from 32 up to 4M with PFA lengths (3*power-of-two and 5*power-of-two) supported. It has a slightly modified memory model that should be more efficient in using the Pentium's TLB (translation look-aside buffers) cache for larger FFT sizes. A little less memory traffic for some FFT lengths. P-1 factoring support. What isn't coded yet: Save files for P-1 and ECM factoring. A O(n log n) GCD to make P-1 and ECM factoring on larger exponents feasible. A more memory efficient but slower stage 2 for large exponents. Several FFT sizes are not coded yet. Obviously, don't expect v19 anytime soon! Here's a teaser: A 128K FFT is 1.5% faster, a 512K FFT is 5% faster. Oh, and by the way, the re-engineered assembly code will be easily usable in other large integer programs. Best regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: preventive measures
First order of business is a plan of action - formulating the QA test suite. Something that is already built-in to 'mprime' is the self-test. Could the QA people please investigate adding another test-suite (or updating the old one) so that people on other platforms (i.e., people who are running a port of 'mprime' rather than the original 'mprime' itself, or maybe even people who have *changed* the code for a non-Intel chip) could run that test-suite and be reasonably sure that their hardware/software combo *is* working properly. How much CPU power are we going to require? Would enough tests to keep 5 volunteers busy for 24 hours suffice? Let's assume that new versions of 'mprime' will take more than three months to create. Then what is being validated by a QA suite is the ability to run productively for 100+ days. Surely 24 hours is *not* too much overhead, if confidence is gained. mikus Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
RE: Mersenne: preventive measures
From: George Woltman Now for some good news Prime95 v19 is under way. It involves rewriting ALL the FFT code! So this QA project is quite timely. What's new in v19? It should support FFT lengths from 32 up to 4M with PFA lengths (3*power-of-two and 5*power-of-two) supported. It has a slightly modified memory model that should be more efficient in using the Pentium's TLB (translation look-aside buffers) cache for larger FFT sizes. A little less memory traffic for some FFT lengths. P-1 factoring support. What isn't coded yet: Save files for P-1 and ECM factoring. A O(n log n) GCD to make P-1 and ECM factoring on larger exponents feasible. A more memory efficient but slower stage 2 for large exponents. Several FFT sizes are not coded yet. Obviously, don't expect v19 anytime soon! Here's a teaser: A 128K FFT is 1.5% faster, a 512K FFT is 5% faster. Oh, and by the way, the re-engineered assembly code will be easily usable in other large integer programs. George...is it too late to request features for the new version? I had done some thinking on it, and wouldn't it be great if there were some sort of "live update" feature, where it could upgrade itself when new versions come out. That's pie in the sky and I remember discussing previously how that wouldn't work for everyone - security issues, bandwidth issues, etc. but perhaps if it were an option. At the very least, I think that there should be an "alert" or other notification of some sort when a new version comes out, rather than relying on emails being sent. The problems with version 17 should give a good example of how that would help. A problem is found with a version, or simply a new faster version is out, so the next time Prime contacts Primenet, it sees some flag set and pops up a box on the screen telling the user about the new version. And a seperate option for how often to check for "messages" besides the number of days between checking in at primenet to update expected completion dates. Also, do you plan to optimize the assembly code in any way for the new types of CPU's out? AMD's K6-3, Pentium III, etc. It would certainly "seem" that some slight tweaking could be done to squeeze out a few extra percent of improvement, but I could only guess at that. Maybe just recompiling the assembly in a compiler that is PIII/K63 aware would take advantage of the processor type, and then just include each compilation in the program with the appropriate branches into the code depending on the CPU type actually being used, just as you have now for PPro/PII, Pentium, etc. One other thing that is, perhaps more pie in the sky, but central configuration for a team. What I mean is, for all my computers, I generally have them set the same in terms of days between check ins, minutes between retries, etc. If I ever need to change some setting, I have to go to each machine (over the network at least) and change each instance. I thought it'd be nice if there were a feature where you could set some configuration to point to a local network share that contains the latest "master" copy of the prime.ini file. Each time the program starts, it would check the master for any changes, or continue with the existing INI file if the master isn't reachable or if no changes were found. Or maybe have it check it on a regular, adjustable schedule. Oh yes, I thought of one more thing. Currently, things like affinity and the service names for NTPrime are located in the PRIME.INI file. Since those are more peculiar to the instance running, I thought that perhaps those options would be better suited in the local.ini file. Reason being, I have several quad processor machines and I have to modify not only local.ini to set the "computerid" but also prime.ini for each instance to set a unique service name and affinity. Wouldn't it be better to have just a single, unchanged prime.ini for each one and only have a unique local.ini that has all the changeable info in it? That makes the idea of a centralized prime.ini that much better/easier. Thats all. For now. :-) Aaron Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: preventive measures
Aaron Blosser wrote: From: George Woltman Now for some good news Prime95 v19 is under way. It involves rewriting ALL the FFT code! Hmm, I know it would take a few resources, but a windows look and feel, instead of typed lines, with a little more info on progress etc. Simple charts, just for the fun, in case there is nothing else useful to be done. Henk Stokhorst Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
