Guest? .... Heck no! .... I could host! :-)
Me, I am 'old' and can certainly be reliably annoying .... :-)
[on-topic]
I've just dug up a reference to a Java ( ie. cross-platform ) interface for process and thread timings, so if it's worthy I'll get back.
[/on-topic]
Cheers, Mike.
[edit] [ and another thing .... :-) ] The 'hide inactive icons' choice for the TaskBar is a classic oxymoron ....
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
The 'co-operative' expectation of Windows 3.x quickly became an utter joke too - the MS recommendation at the time was for third party applications to politely release/yield their own thread to others - like that ever happened, much!! :-)
Mac OS 9 and under was the same way. Some processes would indeed defer to user activity and go into the background, but others couldn’t be budged.
For anyone using the data gathering shell script that I published earlier in this thread, you might like to know that I'm releasing a new version with some additional features. The new version is V3.3 and it is obtainable here. I've been requested to make a version that is non-interactive and therefore suitable to be run by cron. I figured that the easiest way to do this would be by a command line flag which would turn off all the questions and answers in the normal interactive version. In the process of doing this, I added a couple of extra command line flags to allow things like particular hosts to be specified without having to rely on the Host IDs stored in a file.
The script now recognises the following command line flags which have the behaviour documented below. The flag letters are -n, -m, -h which stand for "non-interactive", "mindays" and "HostID" respectively. All flags require a numerical argument which is part of the flag, ie no intervening space between the flag and its argument.
* -n0 -> non-interactivity is zero - ie the script is fully interactive just as previously. This is the default.
* -n1 -> partially non-interactive - ie no questions will be asked but certain status information will be printed to stdout during program execution.
* -n2 -> fully non-interactive - ie no questions and no stdout output. The completed tasks data is silently added to the various results files for the hosts being monitored.
* -mxxx -> this is the "mindays" value which is the delay in days before a host's data is considered out-of-date. It has the syntax of the "find" command's -mtime flag as documented by the "find" manpage. You need to read this manpage carefully as the behaviour is quite quirky. The default value is +1 which is equivalent to using a flag of -m+1.
* -hnnnnnn -> collect results for this Host ID. You can collect for multiple hosts simply by having multiple -h flags with one ID per flag. If you don't specify any host IDs the program will look for all your IDs stored in the hostids file - ie this was the previous automatic behaviour.
If you run the program without any arguments, you should get exactly the previous behaviour with the ability to add new hosts and have them stored in the hostids file for future use. If you use it non-interactively and specify hosts as flag arguments, those hosts will not be checked against or stored in the hostids file. There is nothing to stop you adding hosts manually to the hostids file at any time if you wish. The interactive program just made it easy to seed the file with a bunch of hosts in the first place.
I hope someone may find the program useful. The new features seem to work OK but I haven't tested it much yet. Please report any problems here.
I've made another improvement to my shell script for gathering E@H Results data particularly for anyone running it as a cron job. This new version is V3.4 and is obtainable here. The script is now a bit more intelligent about its working directory and you can set this with a new -wdir command line flag. Previously, the script expected that the user would start it in the appropriate working directory and that the files it needed or created would be there in that particular working directory. So to run it under cron, the command would have had to have been something like
cd /home/joe/some/dir ; ./grabdata_V3.3.sh ....
whereas now, if the directory where the script is stored is in your path, you can just
grabdata_V3.4.sh -w~/some/dir ....
The script now still assumes (unless specifically told otherwise) that its working directory is where you decide to start it but it also has the ability to be told about the working directory through the -wdir command line flag, where "dir" is a valid working directory. The syntax of "dir" is such that you can specify the directory in a number of ways, eg,
* /home/joe/some/dir - ie a full pathname
* ~/some/dir - ie a pathname relative to the users home directory
* some/dir - ie a sub-directory of where the script is started
* ~/Ein* - ie use wildcards - this would work if there was just one subdir starting Ein... in your home directory.
Once again, there should be no space between the flag and its argument, ie -w~/Ein* would be legal but -w ~/Ein* wouldn't be.
Ok, here's the first try of a reference workunit to measure the performanece of Apps: refwu.zip.
It is a current h1_1005.00_S5R3 workunit with a modified skygrid file that covers the whole sky in 31 points.
It is meant to work on MacOS and Linux (for now), hopefully someone better than me in scripting on Windows could write a batch file similar along the lines of the shell script "run.sh", I'll be happy to include it in the archive.
The script takes the application executable as its first (and only) argument. It requires either curl or wget to be present on the system and downloads additional data files from the Einstein@home server (if not already present) before running the App.
Depending on the App version and the system the run-time should be about half an hour.
Ok, here's the first try of a reference workunit to measure the performanece of Apps: refwu.zip.
It is a current h1_1005.00_S5R3 workunit with a modified skygrid file that covers the whole sky in 31 points.
It is meant to work on MacOS and Linux (for now), hopefully someone better than me in scripting on Windows could write a batch file similar along the lines of the shell script "run.sh", I'll be happy to include it in the archive.
The script takes the application executable as its first (and only) argument. It requires either curl or wget to be present on the system and downloads additional data files from the Einstein@home server (if not already present) before running the App.
Depending on the App version and the system the run-time should be about half an hour.
Have a try and post your comments here.
BM
I unzipped it in the ~BOINC/projects/ein* directory and made it run. But it made an error message "cannot fnd binary to execute".
The script takes the application executable as its first (and only) argument. It requires either curl or wget to be present on the system and downloads additional data files from the Einstein@home server (if not already present) before running the App.
I unzipped it in the ~BOINC/projects/ein* directory and made it run. But it made an error message "cannot fnd binary to execute".
You probably need to tell it which App you want to test.
Try something like
./run.sh ./einstein_S5R3_4.49_i686-pc-linux-gnu_1
BTW: with "switching" Apps calling the switcher doesn't work right away, you'll need to call the actual App.
BTW: with "switching" Apps calling the switcher doesn't work right away, you'll need to call the actual App.
BM
This is the result with *linux-gnu_1
real 11m42.814s
user 11m34.615s
sys 0m3,040s
Tullio
Looks like a rather fast machine. Can you post the details?
Actually the time only makes sense to compare Apps e.g. on the same machine. Could you run this with the generic App (*linux-gnu_0), and possibly with the SSE2 App?
LOL... Agreed! Maybe we
)
LOL...
Agreed!
Maybe we can get a guest spot on 'Cranky Geeks' or 'TWiT'! :-D
Apps that give a choice....
WinZip 8
Adobe Reader 6.....
Gee, I guess that means old and reliable, or new and annoying are you're only real choices today! ;-)
Alinator
RE: LOL...Alinator Gues
)
Guest? .... Heck no! .... I could host! :-)
Me, I am 'old' and can certainly be reliably annoying .... :-)
[on-topic]
I've just dug up a reference to a Java ( ie. cross-platform ) interface for process and thread timings, so if it's worthy I'll get back.
[/on-topic]
Cheers, Mike.
[edit] [ and another thing .... :-) ] The 'hide inactive icons' choice for the TaskBar is a classic oxymoron ....
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: The 'co-operative'
)
Mac OS 9 and under was the same way. Some processes would indeed defer to user activity and go into the background, but others couldn’t be budged.
For anyone using the data
)
For anyone using the data gathering shell script that I published earlier in this thread, you might like to know that I'm releasing a new version with some additional features. The new version is V3.3 and it is obtainable here. I've been requested to make a version that is non-interactive and therefore suitable to be run by cron. I figured that the easiest way to do this would be by a command line flag which would turn off all the questions and answers in the normal interactive version. In the process of doing this, I added a couple of extra command line flags to allow things like particular hosts to be specified without having to rely on the Host IDs stored in a file.
The script now recognises the following command line flags which have the behaviour documented below. The flag letters are -n, -m, -h which stand for "non-interactive", "mindays" and "HostID" respectively. All flags require a numerical argument which is part of the flag, ie no intervening space between the flag and its argument.
* -n1 -> partially non-interactive - ie no questions will be asked but certain status information will be printed to stdout during program execution.
* -n2 -> fully non-interactive - ie no questions and no stdout output. The completed tasks data is silently added to the various results files for the hosts being monitored.
* -mxxx -> this is the "mindays" value which is the delay in days before a host's data is considered out-of-date. It has the syntax of the "find" command's -mtime flag as documented by the "find" manpage. You need to read this manpage carefully as the behaviour is quite quirky. The default value is +1 which is equivalent to using a flag of -m+1.
* -hnnnnnn -> collect results for this Host ID. You can collect for multiple hosts simply by having multiple -h flags with one ID per flag. If you don't specify any host IDs the program will look for all your IDs stored in the hostids file - ie this was the previous automatic behaviour.
If you run the program without any arguments, you should get exactly the previous behaviour with the ability to add new hosts and have them stored in the hostids file for future use. If you use it non-interactively and specify hosts as flag arguments, those hosts will not be checked against or stored in the hostids file. There is nothing to stop you adding hosts manually to the hostids file at any time if you wish. The interactive program just made it easy to seed the file with a bunch of hosts in the first place.
I hope someone may find the program useful. The new features seem to work OK but I haven't tested it much yet. Please report any problems here.
Cheers,
Gary.
I've made another improvement
)
I've made another improvement to my shell script for gathering E@H Results data particularly for anyone running it as a cron job. This new version is V3.4 and is obtainable here. The script is now a bit more intelligent about its working directory and you can set this with a new -wdir command line flag. Previously, the script expected that the user would start it in the appropriate working directory and that the files it needed or created would be there in that particular working directory. So to run it under cron, the command would have had to have been something like
cd /home/joe/some/dir ; ./grabdata_V3.3.sh ....whereas now, if the directory where the script is stored is in your path, you can justgrabdata_V3.4.sh -w~/some/dir ....The script now still assumes (unless specifically told otherwise) that its working directory is where you decide to start it but it also has the ability to be told about the working directory through the -wdir command line flag, where "dir" is a valid working directory. The syntax of "dir" is such that you can specify the directory in a number of ways, eg,
* ~/some/dir - ie a pathname relative to the users home directory
* some/dir - ie a sub-directory of where the script is started
* ~/Ein* - ie use wildcards - this would work if there was just one subdir starting Ein... in your home directory.
Once again, there should be no space between the flag and its argument, ie -w~/Ein* would be legal but -w ~/Ein* wouldn't be.
Hope this might be useful for anyone interested.
Cheers,
Gary.
Ok, here's the first try of a
)
Ok, here's the first try of a reference workunit to measure the performanece of Apps: refwu.zip.
It is a current h1_1005.00_S5R3 workunit with a modified skygrid file that covers the whole sky in 31 points.
It is meant to work on MacOS and Linux (for now), hopefully someone better than me in scripting on Windows could write a batch file similar along the lines of the shell script "run.sh", I'll be happy to include it in the archive.
The script takes the application executable as its first (and only) argument. It requires either curl or wget to be present on the system and downloads additional data files from the Einstein@home server (if not already present) before running the App.
Depending on the App version and the system the run-time should be about half an hour.
Have a try and post your comments here.
BM
BM
RE: Ok, here's the first
)
I unzipped it in the ~BOINC/projects/ein* directory and made it run. But it made an error message "cannot fnd binary to execute".
RE: RE: The script takes
)
You probably need to tell it which App you want to test.
Try something like
BTW: with "switching" Apps calling the switcher doesn't work right away, you'll need to call the actual App.
BM
BM
RE: Try something
)
This is the result with *linux-gnu_1
real 11m42.814s
user 11m34.615s
sys 0m3,040s
Tullio
RE: RE: Try something
)
Looks like a rather fast machine. Can you post the details?
Actually the time only makes sense to compare Apps e.g. on the same machine. Could you run this with the generic App (*linux-gnu_0), and possibly with the SSE2 App?
BM
BM