DPAD new TeAmMates 26.02.04

[amdxborg]

a Very big welcome BnT & ScottSwingleComputers and happy crunching!!!

 

[Zbox]

aye, welcome

 

[Confused]

Welcome!


Garry

 

[BlackMountainCow]

Hey BnT & ScottSwingleComputers , welcome to TeAm DPAD!! :beer::beer:

If u got any questions, just follow the DPAD link in my sig and read everything u want to know on our DPAD Guide!

 

[Overkiller]

welcome and enjoy your stay!

 

[sswingle]

I have a couple questions...

When does the client decide to send in results. Muon Monitor says I have 75 results to send, but when I click manual send, it tells me that program manualsend.exe was not found.

Am I thinking correctly that results.txt have not been sent to the server, while results.dat have?

Second question, I have send in 500 something results, BnT has send in 150, but is ahead of me in standings.

Thanks!

Edit, one of my other machines is holding onto 80 results. Haven't checked the 3rd...

 

[BofRA]

Thanks for the welcome. I will jump up here in a few days once I combine my two accounts

Testing going well on the work fleet. I should know by tomorrow if I am switching my work fleet over once SETI ends

 

[Zbox]

Originally posted by: ScottSwingleComputers
I have a couple questions...

When does the client decide to send in results. Muon Monitor says I have 75 results to send, but when I click manual send, it tells me that program manualsend.exe was not found.

Am I thinking correctly that results.txt have not been sent to the server, while results.dat have?

Second question, I have send in 500 something results, BnT has send in 150, but is ahead of me in standings.

Thanks!

Edit, one of my other machines is holding onto 80 results. Haven't checked the 3rd...

You are correct; results.dat info has been sent and results.txt info is pending submission. By default the client autosends your results when the results.txt file reaches 100KB in size.

The reason why BnT is ahead of you is because he has higher Mpts. The number of Mpts per result is variable, see this taken from the sample results file:

9.871286 (1502.3 Mpts) [v4.33a] <SolenoidsTo15cm> #time=41299;
0.337175 (168.4 Mpts) [v4.33a] <SolenoidsTo15cm> #time=41436;

Both are valid results, but the number of times the particle was shifted forward a timestep is much greater in the first example. Obviously the first result takes longer to compute due to 1.5 billion shifts versus the 168 million shifts in the second result.

I am actually experiencing similar output to you right now (lower Mpts per result). This is due to a bug in v4.33a requiring checksums when importing the sample results file into your actual results file. Because the samples no longer contain checksums, the samples won't be imported and the client has to learn on its own.

And that is not necessarily a bad thing Starting from scratch could lead to new and more effecient breeds... Sure you'll have lower Mpts per result for the time being, but keep plugging away and your client is going to work it's way up.

A new client is expected to be released tomorrow that will resolve the current issue with the sample file not being utilized.

-z

 

[sswingle]

Ok, so that would explain why my 2600 XP is giving me MUCH better results than the Athlon 800 is.