Dialup with command line version works well

dsouza123 · 2003-10-11, 02:08

Hopefully this post will not offend anyone, but I would like to say it anyway.

After reading about this project it was implied that using a dialup connection would not work and those with dialup were not needed. I was still interested so I tried.
The GUI version DOESN'T work with dialup, so that part is correct.
The command line version runs very well on dialup.
The assignments usually started at 1 unit and would increase in size as completed assignments were returned.
On the Athlon 1.2 Ghz that I have, doing 1 unit takes a minute or so at most with a moderate CPU load from other programs.

It does require putting a stop.txt file in a certain directory to cause the program to stop gracefully. I wrote a program to do this and posted it and the source code for any who wanted/needed it in the programming form, (also a program to delete the stop.txt).
It also helps creating a desktop shortcut or a menu shortcut to make it easier to use, otherwise it involves going to a command prompt and running batch files. I use Windows so what is involved in other OSes is beyond my experience.

I understand it requires more effort to use the command line version and there is less feedback compared to a GUI, which has lots of indicators and stats, but the C L does contribute valuable work.

If dialup was listed as an OK option with the warning/caveat it only works for the command line version there would be far more people participating.

Again this may be controversial and posting this may make me person non grata in this forum but I feel that not including many people because they lack a high speed connection removes potential contribution to this very interesting distributed project.

Please do not take this a personal critisism of anyone just my opinion and desire to help the project.

Thank You

D Souza

xilman · 2003-10-11, 09:20

Quote:

Originally posted by dsouza123
Hopefully this post will not offend anyone, but I would like to say it anyway.

It certainly doesn't offend me, nor should it offend anyone else. I'm pleased you posted because it makes visible a misconception that I didn't know anyone had and was certainly not intended on our part.

Quote:

After reading about this project it was implied that using a dialup connection would not work and those with dialup were not needed. I was still interested so I tried.

That implication was not intended. I'll try to explain more clearly.

The command line client assumes that you have network connectivity to a server. It doesn't care in the slightest whether the network is a dial-up line. All it wants is to be able to send and receive HTTP protocol messages to and from a server.

Our advice against using the nfsnetclient on a dial-up connected system comes from two concerns: intermittent connectivity and bandwidth usage.

Many people in the world have to pay real money for each phone call and for each second of connectivity. Many people also have only one phone line which has to be shared with other uses. A program that calls a server every hour or so and uploads anything up to a megabyte a day could well be both unpopular and expensive. We really don't want anyone to discover that the hard way.

As you've found by experiment, the client works fine as long as you don't mind your phone line being tied up in this manner and as long as you don't mind incurring any charges from the telco.

Quote:

The GUI version DOESN'T work with dialup, so that part is correct.

This bit concerns me. I can't see any reason why the GUI should not work and, unless and until Jeff comes up with a plausible explanation, I'm going to treat it as a bug report. Thanks for letting us know. Perhaps you could give us more information (off-forum may be better) so we can debug how and why it didn't work. I'll get Jeff to contact you.

Quote:

It does require putting a stop.txt file in a certain directory to cause the program to stop gracefully.

Indeed. It's documented ;-) Creating a file called processors/p0/stop.txt with any contents at all, or none for that matter, will make the client shutdown gracefully. It will also not start sieving again until the file is removed, which may be useful in some circumstances, such as where an automated program tries to start the client every so often during the day and the owner of the machine would prefer the siever not to run for a period

Quote:

If dialup was listed as an OK option with the warning/caveat it only works for the command line version there would be far more people participating.

Good idea. We should do that. Thanks.

Quote:

Please do not take this a personal critisism of anyone just my opinion and desire to help the project.

Certainly not! Quite the reverse. Thanks for letting us know, so that we can clear up any misunderstandings.

Paul

Jeff Gilchrist · 2003-10-11, 12:43

Quote:

Originally posted by dsouza123
After reading about this project it was implied that using a dialup connection would not work and those with dialup were not needed. I was still interested so I tried.
The GUI version DOESN'T work with dialup, so that part is correct.
The command line version runs very well on dialup.

Hi Dsouza,

I'm wondering if you could give me more information about how the GUI does not work with dialup? The GUI is actually just a monitoring/control program but does not have any NFS/sieving/network functionality built-in. It will launch the command line version and then monitor its output files to let the user know what is going on. But the command line version is still running in the background and actually doing all the work.

If the command line version works with dialup (as we already know does), the GUI shouldn't be any different. Can you explain what is not working when you use the GUI? What OS are you running on and which version of the GUI are you using?

Lets try and get to the bottom of this. Unfortunately I don't have dialup access at all to test this out (haven't used a modem at home for 6 years now).

Thanks,
Jeff.

dsouza123 · 2003-10-11, 13:41

This is from a reply I wrote from August 26 2003, after getting an email asking about my configuration because I have a R instead of a M id.

I am using Windows 98 SE, an Athlon 1.2 Ghz and 512 MB of RAM on a dialup connection. ( For completeness there is a 10/100 ethernet card and a firewire card in the PC that aren't connected to any networks, I don't think it has any connection with the GUI crashing though. )

"
I tried the GUI but it crashed alot, it would stop responding, wouldn't minimize, would freeze in place ( couldn't move), the display would get overwritten, showed the wrong CPU clock speed ( 1271 when machine was 1171 ), repeated, quick ( once a second ) attempts to contact the NFSNET server including repeated DNS requests.
I don't remember if it was on requesting an assignment or on submitting results.
( If it was submitting then it just sent a single line sieve. )
"

The GUI doesn't have a version tab when doing properties on the .exe so I am not sure, but probably version 1.0 .

Typing nfsgui.ini this is the output

C:\NFSNET>type nfsgui.ini
v1.0
RefreshRate 060
StartOption 1
GUITotalTime 694
AutoStart 0
AutoStop 1
AutoBattery 0
ServiceInstalled 0
AutoWriteBench 0
UseWindowsColour 0
RunClientFor 1
RunClientForInterval 01
Log 0
LogInterval 010
StartTray 0
NFSnetClientPath .\
NFSnetProcPath .\processors\p0\
TitleBar Athlon

And typing benchmark.txt

C:\NFSNET>type benchmark.txt
------------------------------------------------------------
NFSnet Windows nfsGUI v1.0 Benchmark

Sample Size : 0 lines over 315 seconds.
Project : 2_757M

Lines Per Minute: 0
Lines Per Hour : 0
Lines Per Day : 0

OS : Windows 98 MHz: 1271
CPU: AuthenticAMD AMD Athlon(tm) Processor
------------------------------------------------------------

It is from August 9th 2003 after spend a few hours trying to get the GUI to work with no success, I tried the command line client which worked well from the first attempt. I have not retried the GUI since.

Small caveat on the command line,
The only ease of use issue with the command line version is needing a stop.txt file in the ./processors/p0 directory/folder ( which is fully documented ) but it is very minor, first done manually then I wrote batch files then regular Windows programs to manage it, the programs are posted so others can use/modify them. I am mentioning this in case someone tries the command line but missed the part on how to stop the program gracefully.

Jeff Gilchrist · 2003-10-11, 19:25

Quote:

Originally posted by dsouza123
I tried the GUI but it crashed alot, it would stop responding, wouldn't minimize, would freeze in place ( couldn't move), the display would get overwritten, showed the wrong CPU clock speed ( 1271 when machine was 1171 ), repeated, quick ( once a second ) attempts to contact the NFSNET server including repeated DNS requests.

The GUI doesn't have a version tab when doing properties on the .exe so I am not sure, but probably version 1.0.

I don't think this would have anything to do with you being a dialup user vs permanent Internet connection. The GUI takes information from the Windows registry about your processor speed so it pulls out whatever Windows inserted when you installed it.

As for the version number, when you load the GUI, it says right at the top "Number Field Sieve GUI vx.xxx" so that is how you would tell the version number of what you have. I have made a new version of the GUI since the one that was released on the nfsnet web site but since the other software hasn't been updated it hasn't been released yet. The latest released version says v1.0 RC1 which does fix some issues, is that the one you currently have?

Other people have reported some of the issues with the GUI you list above but so far I have not been able to reproduce them on my machine which makes it difficult to find out exactly what is wrong. Hopefully we can get all these issues resolved. If you would like, I can send you the latest build of the GUI to see if that solves any of your problems.

Regards,
Jeff.

dsouza123 · 2003-10-12, 03:00

I scanned the nfsGUI.exe with BinText, it has the string v1.0 RC1 embedded.
Just tried the GUI didn't change any existing settings or click any buttons ( except refresh a few times ), it ran fine, no crashes, maybe it just needed the command line version to have run by itself succesfully to get all the settings and files set correctly.

The command line was hidden this time, when I tried it before (in August) I clicked to have the command line visible and tried the config.

Used the GUI again, just used config to change refresh time, then exitted, then ran the GUI again did an assignment with no problems.

Thanks for the help and feedback, I wouldn't have tried the GUI again if you hadn't said it was just a monitoring program. Would have just thought it was buggy/unstable and stayed with the command line version. I am glad it is working OK now.

2003-10-11, 02:08	#1
dsouza123 Sep 2002 1226₈ Posts	Dialup with command line version works well Hopefully this post will not offend anyone, but I would like to say it anyway. After reading about this project it was implied that using a dialup connection would not work and those with dialup were not needed. I was still interested so I tried. The GUI version DOESN'T work with dialup, so that part is correct. The command line version runs very well on dialup. The assignments usually started at 1 unit and would increase in size as completed assignments were returned. On the Athlon 1.2 Ghz that I have, doing 1 unit takes a minute or so at most with a moderate CPU load from other programs. It does require putting a stop.txt file in a certain directory to cause the program to stop gracefully. I wrote a program to do this and posted it and the source code for any who wanted/needed it in the programming form, (also a program to delete the stop.txt). It also helps creating a desktop shortcut or a menu shortcut to make it easier to use, otherwise it involves going to a command prompt and running batch files. I use Windows so what is involved in other OSes is beyond my experience. I understand it requires more effort to use the command line version and there is less feedback compared to a GUI, which has lots of indicators and stats, but the C L does contribute valuable work. If dialup was listed as an OK option with the warning/caveat it only works for the command line version there would be far more people participating. Again this may be controversial and posting this may make me person non grata in this forum but I feel that not including many people because they lack a high speed connection removes potential contribution to this very interesting distributed project. Please do not take this a personal critisism of anyone just my opinion and desire to help the project. Thank You D Souza

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Mail from command line	pepi37	Linux	4	2015-07-16 22:06
Windows command line	mu5tan6	Software	14	2015-03-20 17:21
command line switch	wongnog	Information & Answers	1	2008-07-20 11:29
NewPGen from the command line	monst	Software	19	2008-01-31 07:07
MultiSieve from the command line (on Windows)	monst	Software	7	2007-12-18 02:37

2003-10-11, 13:41	#4
dsouza123 Sep 2002 2·331 Posts	This is from a reply I wrote from August 26 2003, after getting an email asking about my configuration because I have a R instead of a M id. I am using Windows 98 SE, an Athlon 1.2 Ghz and 512 MB of RAM on a dialup connection. ( For completeness there is a 10/100 ethernet card and a firewire card in the PC that aren't connected to any networks, I don't think it has any connection with the GUI crashing though. ) " I tried the GUI but it crashed alot, it would stop responding, wouldn't minimize, would freeze in place ( couldn't move), the display would get overwritten, showed the wrong CPU clock speed ( 1271 when machine was 1171 ), repeated, quick ( once a second ) attempts to contact the NFSNET server including repeated DNS requests. I don't remember if it was on requesting an assignment or on submitting results. ( If it was submitting then it just sent a single line sieve. ) " The GUI doesn't have a version tab when doing properties on the .exe so I am not sure, but probably version 1.0 . Typing nfsgui.ini this is the output C:\NFSNET>type nfsgui.ini v1.0 RefreshRate 060 StartOption 1 GUITotalTime 694 AutoStart 0 AutoStop 1 AutoBattery 0 ServiceInstalled 0 AutoWriteBench 0 UseWindowsColour 0 RunClientFor 1 RunClientForInterval 01 Log 0 LogInterval 010 StartTray 0 NFSnetClientPath .\ NFSnetProcPath .\processors\p0\ TitleBar Athlon And typing benchmark.txt C:\NFSNET>type benchmark.txt ------------------------------------------------------------ NFSnet Windows nfsGUI v1.0 Benchmark Sample Size : 0 lines over 315 seconds. Project : 2_757M Lines Per Minute: 0 Lines Per Hour : 0 Lines Per Day : 0 OS : Windows 98 MHz: 1271 CPU: AuthenticAMD AMD Athlon(tm) Processor ------------------------------------------------------------ It is from August 9th 2003 after spend a few hours trying to get the GUI to work with no success, I tried the command line client which worked well from the first attempt. I have not retried the GUI since. Small caveat on the command line, The only ease of use issue with the command line version is needing a stop.txt file in the ./processors/p0 directory/folder ( which is fully documented ) but it is very minor, first done manually then I wrote batch files then regular Windows programs to manage it, the programs are posted so others can use/modify them. I am mentioning this in case someone tries the command line but missed the part on how to stop the program gracefully.

2003-10-12, 03:00	#6
dsouza123 Sep 2002 2×331 Posts	I scanned the nfsGUI.exe with BinText, it has the string v1.0 RC1 embedded. Just tried the GUI didn't change any existing settings or click any buttons ( except refresh a few times ), it ran fine, no crashes, maybe it just needed the command line version to have run by itself succesfully to get all the settings and files set correctly. The command line was hidden this time, when I tried it before (in August) I clicked to have the command line visible and tried the config. Used the GUI again, just used config to change refresh time, then exitted, then ran the GUI again did an assignment with no problems. Thanks for the help and feedback, I wouldn't have tried the GUI again if you hadn't said it was just a monitoring program. Would have just thought it was buggy/unstable and stayed with the command line version. I am glad it is working OK now.