I am getting ZZZZZ that make each My PC's Beg for 3 to 5 min 's for new work
If I start up 900+ clients((6 Per core)) that wait time will jump to 5 to 8 Min's for all members
From what I have seen EoN does not have the Power to supply the needs of it's membership as it stands right now
Adding the power you are suggesting would only I think would Overwhelm the server to the point that no one will be happy with the Project
When I first jumped in EoN at full speed at only 3 per core that is just what happened the wait time went to 10 min per client
Waiting like that to me is a Waste of CPU time and power Not to mention Bandwidth
I think until the Admins upgrade or streamline there there Server load
I will keep it at 1 per node not core
If the EoN's Admins are reading this I hope you can see my points and make improvements to there system
You talk too much, bring them on....
I think Lauren's right. EON is a self-eating watermelon.
If the boys at UT thought they could needed to get more science done than is happening now, they would find a way to streamline the process. An alternative explanation may be that they are, after all, scientists, NOT programmers. It may be beyond their means to even visualize, much less produce a more effective system.
(No, I don't think very highly of scientists, who are not trained as programmers, writing their own code. Look at Proteins @ home for an example.)
If they want my GHz, they know where to find me.
HOME: A physical construct for keeping rain off your computers.
Well the work seems to be flowing Get the WU;s while you CAN
So now how am I doing
I am at 1 client per core now instead of 1 client per Node I was
I am doing 50% of the teams output Is this what you meant by "bring them on"
em99010pepe do you and your DC Mercenaries want to Race to a mill
I Only Have 3 more week of runtime before I have to shut down for a month
Might as well have fun with it
Don't be sure about that.
I have to shutdown (still live with my parents) for a few weeks all my home machines due to high electricity bill.... I might move them to work, still thinking. My problem is that my work contract ends this June and I won't renew it because there's no projects to finance our salaries. Because I want to finish my master degree I'll have access to the lab where I work, and this is my option, and not to move to another unit, in the institution I work, where I have a place to work (two jobs offer). I'll make a pause of 2-3 months to end my master thesis...I think this is a good choice. I can't work and make the thesis at the same time. For the moment I am dedicated to it and I prefer to stay in that way.
Carlos
So what is up with this site Any word from anyone
Will they get there site and stats back up ?????
Anyway gang.... there is a rather simple fix for those who wish to run Eon... GRANTED, there are still the issues at the server, but the clients (and WINDOWS mostly) are the problem.
If someone can turn this into a .reg file for those not willing to risk it..... Here is the WHAT IS WRONG and HOW TO FIX IT (client side).
Windows waits after closing a socket (to eon & others) before opening a new one. Due to the short job time with EON, we trip over both the server AND MOSTLY the client OS... not the client.
So, as referenced above about the 'tweaker' and the setting being put to 30... here is the key info.
start->run->regedit
now navigate your way down to:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Paramters
(left side)...
On the right, you need to create a NEW (or change) a DWORD entry. So, right side 1/2 window, create a new key (or double-click on the existing) name "TcpTimedWaitDelay" of type "DWORD". DO NOT INCLUDE THE QUOTES
if you cycle through sockets REALLY fast, you may want 5-10 (respresenting seconds) after the program closes the socket (.... seeeee windows does a MANDITORY WAIT)... this parameter tells the driver how long to wait -or- use the default value (240-300 sec). Normal folk will want 20-30 seconds... I personally use 30 seconds and am fine..
you may want a shorter delay in closing a socket, perhaps 10 or 15. Adjust accordingly to your needs.
The change(s) take effect ONLY AFTER a reboot. The TCPIP driver reads it at startup only.
This will also effect any BT traffic you might be sharing with a friend.
Windows machines used as project servers usually have about 128 effective sockets before they go nuts.... (ignore that 600-800 crap)... So based on 128.... setting the delay value == 5 seconds ensures all data gets there and the 'ack' is received in the final close.... also, your windows kernel doesn't go nuts having more than the default 128 sockets it allocates.
Enjoy all.... So far, it has helped a few projects very nicely.
And in the words of one that came before me....''' Wash, Rinse, Repeat..... '''..
but here it is. It works on all I have , but not verified on Vista (since it's BSD underneath). Perhaps a Vista owner will augment this and help out the rest, but win/2k HAULS BUTT...
You know you are doing good when a 10 Mbit DSL sustains 1.2 MB/sec download. (yes, synchronous clocked)
C.
PS: YES, I am back... Not sure how long or how much, but at least in limited fashion.
PPS: The 'daring' may use this as a reference
http://publib.boulder.ibm.com/wasce/...g-windows.html
Last edited by Chuck; 09-18-2008 at 02:22 PM. Reason: typo
A FDC in training, fellow supporter of Firefox.
Proudly crunching with AMD & ATI power.
If you want The Best you must forget the Rest
>>>>>>>>>and join Free-DC<<<<<<<<<<<
I see the Dutch Power Cows are making a move they will be at our back in 22,138.80 Days
They exceeded our output by 55 points so far for to day
I guess I need to get more Q's back online
Better move my Cyrix 166 MHz to eOn.
A FDC in training, fellow supporter of Firefox.
Proudly crunching with AMD & ATI power.
If you want The Best you must forget the Rest
>>>>>>>>>and join Free-DC<<<<<<<<<<<