posted April 21, 2000 23:42         

Regards,

Steve

IP: Logged

posted April 22, 2000 05:54         

Amaze your friends. Tell them about www.art-museum.org !

IP: Logged

posted April 22, 2000 08:28         

also, user-defined arbitrary names for all input and output files.

also, the ability to take advantage of multiple processors.

i want this because i don't like my current 4 installations of the client --i want to have just one, started as a service 4 times (each with a different config file,) using 4 different sets of input/output files.

hmm. . . it would be nice if the gui were smart enough to show all the status and message files from those four instances, either all at once or user-selectable.

hmm. . . even if it used smp, i still think that being able to specify the config on the command line would be useful.

i haven't used it much yet, so i can't really comment beyond that. . . maybe i'll come up with something else later. ^_^

------------------
otaku of distributed computing unite! join team 198 if you're an anime fan!

IP: Logged

posted April 22, 2000 11:23         

Hi

I would be happy about a more reliable flushing and some graphical mode of what is being computed.. something "entertaining".
Of course it would be necessary to have the possibility to turn it of.
Besides you could improve the clients look.
The old one looked quite boring, you know?
ok thx a lot for reading,
bye Tchou~~

IP: Logged

posted April 22, 2000 12:15         

------------------

IP: Logged

posted April 22, 2000 12:19         

SMP support, that's all I ask

IP: Logged

posted April 22, 2000 15:22         

IP: Logged

posted April 22, 2000 17:16         

Some sort of automatic backup of the buffer so you don't loose all your work if/when your OS decides to crash...I just lost ~1500 blocks because of that

------------------
http://home.worldonline.dk/~isl25946

IP: Logged

posted April 22, 2000 18:48         

Don't worry; you don't have to write when Windows crashes .

Thanks!

Ken

[This message has been edited by Ken_g6 (edited April 24, 2000).]

IP: Logged

posted April 22, 2000 20:22         

All I'd ask is better parity between client... i.e. across systems, surely the Linux client and the NT should be comparable.. both had next to no services running, and both in ram... but the NT client is approx 20k rays/s faster..

Colin

IP: Logged

posted April 22, 2000 20:44         

1. Make the client configurable to detect a DUN connection and fetch/flush whenever possible during the time that connection is open.

2. Make it so fetching/flushing works reliably so you don't have to spend an eternity babysitting the client to make sure it flushes.

Aside from those, set up a method for more than one client to share in/out buffers over a network (without resorting to the "proxy") or else make it far easier to "sneakernet" the buffer files (i.e. don't have to shut down all clients, move files, then restart 'em all)

Anything else is just glitz for me, but the whole issue of flushing work is really starting to drive me "round the bend" with this client. :P

-Brian

------------------
circular reasoning n: see reasoning, circular

IP: Logged

posted April 22, 2000 22:11         

Regards,

Steve

IP: Logged

posted April 22, 2000 23:45         

[This message has been edited by Joe O (edited April 29, 2000).]

IP: Logged

posted April 23, 2000 12:27         

does the gamma flux client actually fetch, or doesn't it? i saw a couple of posts saying it doesn't and one that implied it, but everyone here seems to think it does.

and actually, i think i agree with colin. . . i have the client running on comparable processors under both nt and linux, and the nt client seems a bit faster. . . i'd ascribed it to a better memory architecture on the nt system. the linux version, on a _totally_ unloaded system, does about 3800 rays/second/processor. the nt version, on a slightly loaded system, does between 3500 and 4200 depending on the load.

chris

IP: Logged

posted April 23, 2000 04:56         

lifftchi,
The client doesn't fetch. It generates random blocks.

------------------
http://home.worldonline.dk/~isl25946

IP: Logged

posted April 23, 2000 06:05         

IP: Logged

posted April 23, 2000 07:30         

but no password! as long as computing cycles are being returned, it doesn't matter who they're really coming from. our stats should be out in the open, too.

oh, and the next version of the stats pages should have a better way to browse for teams! (i just did it by entering 26 letters, one at a time, in the search form. . . there has to be a better way. . . but i didn't find it! ^_^ baka baka. )

hmm. . . i like the way the gui is implemented. (echoing commands to a text file, reading in status and message files, etc.) since i like that, and i like having the progress meter update 1% at a time, i'm inclined to not mind the frequent logging.

but actually, um. . . i just looked at the GFClient.log file. . . it does get truncated eventually, right?!?!?!? i don't want to have to deal with it limitlessly increasing in size. ^_^ (kinda brings to mind that scene from akira --ObAnimeReference)

and yes, i do sit and watch the gui occasionally. . . it's almost like zen meditation. . . free your mind of worldly thoughts. . . watch the rays. . . another percent. . . another block. . . where does the time go?

;;^_^ my life must be very boring, ne?

chris

[This message has been edited by lifftchi (edited April 24, 2000).]

IP: Logged

posted April 23, 2000 09:14         

If you want linux to be as fast as windows, tell the linux community to make a damned compiler which has at least a partial clue about CPU optimization. It's the same code base as windows for the cores, yet you see the huge speed difference..... The linux compilers just can't hold a candle to MSVC, which is really sad, cause MSVC isn't close to great.

Steve

IP: Logged

posted April 23, 2000 13:59         

Colin

IP: Logged

posted April 23, 2000 14:16         

Thx,
AJ

IP: Logged

posted April 23, 2000 14:17         

Vicente

------------------
http://www.myservice.com/hotline >

IP: Logged

posted April 23, 2000 15:51         

Win 32 client:

Please, please, please!
Drop the file polling as the communication process between the client and the GUI (status, commands & messages files).
Use WM_COPYDATA or a pipe (or something similar). This will make the GUI much more responsive.
It will make homebrewn GUI development more difficult, but I have rather a limited choice of fast GUI's than a bunch of slow ones.

Linux command line client:

* Let the client search for it's ini file in this order:
- located in the same dir as client
- dir from which the client was started (is now the only place where the client searches)
- maybe in /etc ?

* Restrict the textoutput of the client to the screen, print date/time when the client start a new block

* Command line options:
-verbose: for people who would like to see the current text output (prints every %)
-c configfile : location of the configfile

* SMP

Linux proxy:

* I have a non-permanent internet connection and would like to flush/fetch manually (this is possible with the win32 proxy).

* 10% CPU usage while waiting for an incomming connection?

* Does it really have to print a statusmessage to the screen every second?

Pulsar

My dutch is better than my english.

IP: Logged

posted April 23, 2000 23:02         

------------------
Shoe Lace.
------
Bad spellers of the world UNTIE!
Australia Dcypher.net Mirror (host/maintainer)

IP: Logged

posted April 24, 2000 02:12         

Colin, I am already using a ramdisk. I have been expounding its advantages for months. But it's just not convenient in many cases, for example, in a case with 16 megs of RAM. I'm afraid the client may have caused one computer's hard drive to crash from too much exercise.

And with a ramdisk, the client can't automatically write to disk when shut down. Oh, yes, need to add that...

Steve, on the speed issue, I remember once using a compiler called gcc2. Is it faster? Maybe it's the standard edition by now. Anyway, failing that, how do you feel about cutting and pasting some assembly code?

Ken

[This message has been edited by Ken_g6 (edited April 24, 2000).]

IP: Logged

posted April 24, 2000 03:59         

chris

IP: Logged

posted April 24, 2000 16:40         

So with gamma flux i just copy the outbuffer to a machine with a modem but with a client needing input buffers this would be to much work.

And something else: While transfering data via modem the core doesnt run. And thats about ten minutes every day of lost cpu cycles.

Michael.

IP: Logged

posted April 25, 2000 18:04         

cordes]~$ netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State

tcp        1      0 Cordes.Phys.Dal.Ca:1265 cogeco-28-12.cgoca:4356 CLOSE_WAIT
tcp        1      0 Cordes.Phys.Dal.Ca:4687 PC-Boo2.SOS.McMast:4356 CLOSE_WAIT
tcp        1      0 Cordes.Phys.Dal.Ca:3889 cogeco-28-12.cgoca:4356 CLOSE_WAIT
tcp        1      0 Cordes.Phys.Dal.Ca:3028 PC-Boo2.SOS.McMast:4356 CLOSE_WAIT
tcp        1      0 Cordes.Phys.Dal.Ca:2236 cogeco-28-12.cgoca:4356 CLOSE_WAIT
tcp        1      0 Cordes.Phys.Dal.Ca:1460 PC-Boo2.SOS.McMast:4356 CLOSE_WAIT
tcp        1      0 Cordes.Phys.Dal.Ca:4626 PC-Boo2.SOS.McMast:4356 CLOSE_WAIT
tcp        1      0 Cordes.Phys.Dal.Ca:4030 PC-Boo2.SOS.McMast:4356 CLOSE_WAIT

#!/bin/bash

cd ~peter/GFClient | | exit 1

while true;
do
        nice -19 ./gf_client >> stdout.log 2>stderr.log < /dev/null
        foo=$?
        echo $(date): $foo >> control.log
done

an excerpt from control.log:

Sat Apr 22 08:26:35 ADT 2000: 139
Sun Apr 23 03:08:01 ADT 2000: 139
Sun Apr 23 03:37:44 ADT 2000: 139
Sun Apr 23 20:48:53 ADT 2000: 139
Mon Apr 24 06:30:36 ADT 2000: 139
Mon Apr 24 23:44:18 ADT 2000: 139
Tue Apr 25 10:20:30 ADT 2000: 139

other things: A dynamically linked binary would be nice. I don't care if you have to hide it behind some warning messages to scare off people who don't know what glibc 2.0.x and glibc 2.1.x are, just make it available somehow. (or even better, make the network fetcher-flusher a separate binary and provide source for that. The network code doesn't need to be loaded all the time when you're just crunching, so you can have it fork and exec a buffer update process when it's getting close to wanting more (so hopefully the buffer will be refilled by the time it actually wants more data! (I guess this doesn't apply so much to gamma flux, because the client generates its own data, but the cruncher would not block on socket io when it could be crunching

and another thing: how about a port to SPARC Solaris? Since you say you're using a C compiler, I assume most/all of it is written in C, so it should be easily portable between Linux and Solaris. I've got distributed.net running on ~20 UltraSPARC workstations in the CS department at school, but I would really like to see them running gamma flux, since UltraSPARCs are much better at floating point than they are at integer calculations, relative to an x86. (especially for RC5, where x86s and PPCs have a rotate instruction that comes in handy. SPARCs suck at RC5 Also, I'm a physics+cs student, so I would really like to see some useful science come out of this! If there are upcoming projects that need a lot of network bandwidth, the SPARCStations would be perfect, as they are all connected to switched 10baseT (soon to be 100baseT) ethernet, and Dal's got connections to a bunch of backbones, including a GigaPOP on CA*Net3 (80 Gbit/s fully optical network Obviously, I can't use _all_ the bandwidth,
but overnight I think I would be allowed to do network-intensive stuff. I think that if you need to find people with lots of bandwidth to throw around, your best bet would be to port your client to lots of Unix flavours. There are probably a higher proportion of Unix machines with high speed ( >cable modem or DSL) access than in the world in general. (most people with Unix machines (other than Linux or *BSD on x86 or PowerPC) don't have them behind a dialup modem Also, for FPU intensive jobs, many of the RISC architectures that traditionally run Unix (e.g. DEC Alpha, IBM POWER) have quite good floating point performance (especially the Alpha Porting to Unix will let you harness more of the university computing power, especially if your projects continue to be of the worth-while variety, like gamma flux, which is the type of project that might interest university academics more than something silly like brute forcing an encryption scheme that is so easy to parallelize it really is funny.
(as opposed to elliptic curve encryption, where, unlike CSC (and DES and RC5), you _can't_ just break it into x number of packets and wait for someone to test the right packet.)

Anyway, hopefully you'll take this into consideration. I'm waiting for that SPARC port

BTW, you mentioned something about gcc sucking. Did you try compiling with -mpentium -march=pentium -mcpu=pentium -fomit-frame-pointer -malign-double -O6 -funroll-all-loops, or some combination of that? (those magic incantations often help, but not always. Benchmark to make sure. That reminds me of another thing: I would like it if the client's rays/sec values were calculated with realtime seconds, instead of with CPU seconds. (i.e. the rate doesn't go down even when the system is loaded, because it still gets the same amount of work done with the same amount of clock cycles (ignoring caching effects).) Anyway, you might also want to try -march=i686 -march=k6, or some other things. There is also Pentium GCC, which sometimes outputs wrong code (!), but often produces faster executables. The wrong code usually leads to crashes in things like the X server, but for a number crunching program you might see wrong data. As long as you make sure it's working right, you should be fine, because there
probably isn't a lot of code to check to make sure it's getting the right numbers. (of course, it might round differently if it makes some different optimizations...) Anyway: http://www.goof.com/pcg /

Yet another thing: It would really be great if source code for at least the cruncher was available, because then people with more free time than you have could hand code a core that took advantage of 3Dnow!, or KNI, AltiVec, or even just hand-tuned the code to keep the CPUs pipes full (especially important on Pentium-class chips). That could solve the compiler problem (of course, you might want to start with compiler output, but then again, taking a fresh think about how to implement it in assembly without having the compiler's choice leading you in a not-necessarily-optimal direction. If you don't want to do that, then compile the cruncher with MSVC if it is faster, and link that object file into the Linux binary instead of the GCC one (unless the magic words made gcc give better optimized code . Some utilities in binutils could probably help you do this, unless MSVC is too brain damaged for this to be possible! BTW, if you've got C++ code, you should try using -fno-exceptions -fno-rtti
(unless you use those language features!)

#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@llama.nslug. , ns.ca)

"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BCE

IP: Logged

posted April 25, 2000 20:55         

but anyway, it would be nice if that problem were fixed. but don't depend on me for bug reports on it. ^_^

this has been a 'me too' post.

chris

IP: Logged

posted April 25, 2000 21:17         

Osiris and I looked at doing that with the CSC core (being hand-coded asm) and only achieved partitial success. mainly because the objects files are different (.obj vs .elf or something, it was a while ago) and not entirely compatible.

that and the fact the gcc doesn't like todo "true" inline assembly, like MSVC does, can make these client a pain to code.

*tink**tink* (my 2 cents)

------------------
Shoe Lace.
------
Bad spellers of the world UNTIE!
Australia Dcypher.net Mirror (host/maintainer)

IP: Logged

posted April 29, 2000 14:10         

IP: Logged

posted April 29, 2000 21:18         

The problem is the network layer. The Version 1 client network layer is unusable (and, as we are aware, still has issues) for the Sparc platform.

The Version 2 layer will be portable and should be much more robust as well. It's one of our many priorities (256 entries deep) to get out 2.0 Sparc clients as soon as feasible to harness that power.

Currently Steve is completing the network layer, but I'd be foolish to commit on an ETA without taking control of his water supply to make it happen

IP: Logged

posted April 30, 2000 16:26         

2)The ability to detect dial-up connection and then automatically fetch/flush.

Thanks for the hard work.

IP: Logged

posted April 30, 2000 22:30         

Check sums for Buffer files or sumthing to protect them more.

IP: Logged