Team sieve for Kosta C198

[VBCurtis]

We've reached Q=20M, with 37.7M relations found. Yield is now above 2.0 average, and the last 8.7MQ got us 19.5M relations for a yield of 2.2ish since my update yesterday. If yield stays put, that's ~160M relations from Q=2-80M. Yield on ggnfs at 700M was around 1.1, so we're saving a Q-range of ~140M by doing this CADO effort.

The job has been posted to the 15e queue, but is a ways down the list; I think we'll finish this CADO effort before the ggnfs relations are ready from 15e.

[VBCurtis]

Today's update:
Q=34.2M, 72.3M relations found.
The server got stuck for a few minutes, and then processed ~40 workunits in a single burst. No idea what goes on in the database, but at least I didn't need to restart it this time!

[EdH]

Originally Posted by VBCurtis

Today's update:
Q=34.2M, 72.3M relations found.
The server got stuck for a few minutes, and then processed ~40 workunits in a single burst. No idea what goes on in the database, but at least I didn't need to restart it this time!

My machines had trouble uploading WUs for two periods, yesterday: the first at around 5PM Eastern and the second at around 9PM Eastern. Examples from one of my machines show uploads that usually take about two seconds, taking as long as 23 minutes and 48 seconds:

upload example 1:
start - - 17:03:32
complete- 17:21:10


upload example 2:
start - - 17:32:01
complete- 17:55:49


upload example 3:
start - - 21:42:07
complete- 21:51:27

[EdH]

Curiosity:

All WUs appear to be the same size (2000). I have two i5's that do not hyperthread, so they are running -t 4. I have several i7's that do hyperthread, so they are running -t 8. All have at least 8GB RAM. Timewise, the two i5's are just about keeping up with the i7's in completing their WUs.

The i5's are running at about 3200 MHz, while the i7's are running at about 3400 MHz.

The only thing I see in the i5's favor, is that they have SSDs. Is there that much drive activity to account for these observations? Or, is it something to do with hyperthreading overhead?

[VBCurtis]

The only relevant data I've taken is running 6 threads on a 6-core, and then 12. The 12-threaded job was about 20% faster than the 6 threaded job.
I've no idea why a faster i7 would take as long as the i5, unless the i5 is a newer generation with newer instructions.

[EdH]

Originally Posted by VBCurtis

The only relevant data I've taken is running 6 threads on a 6-core, and then 12. The 12-threaded job was about 20% faster than the 6 threaded job.
I've no idea why a faster i7 would take as long as the i5, unless the i5 is a newer generation with newer instructions.

That may very well be the difference. The i5's are much newer than the i7's.

BTW, as I write this, all of my machines are complaining:

2020-05-03 20:07:55,928 - ERROR:root:Upload failed, URL error: <urlopen error [Errno 111] Connection refused>
2020-05-03 20:07:55,928 - ERROR:root:Waiting 10.0 seconds before retrying (I have been waiting since 1930.0 seconds)

and:

INFO:root:spin=44 is_wu=True blog=0
INFO:root:Downloading http://TheMachine.dyn.ucr.edu:44455/cgi-bin/getwu?clientid=eFarm.20 to download/WU.eFarm.20117763498 (cafile = None)
ERROR:root:Download failed, URL error: <urlopen error [Errno 111] Connection refused>

[VBCurtis]

Yea, CADO quit; when I tried to restart it, I got the error message that we hit the max failed workunits of 100. Your machines killed us!

I set the new max to 1000, which should last us the duration of this effort. The server is back up.

[EdH]

Originally Posted by VBCurtis

Yea, CADO quit; when I tried to restart it, I got the error message that we hit the max failed workunits of 100. Your machines killed us!

I set the new max to 1000, which should last us the duration of this effort. The server is back up.

Apologies!

But, mine shouldn't be failing that much now, unless it's possibly due to "tasks.wutimeout = 3600 # one hour." My slower machines are taking less than 30 minutes to complete, other than not being able to report.

I probably used up some of the "failed" quota in the beginning, but I have all the scripts doing a good job of gracefully ending after a submission, now. That means the curfewed ones don't leave anything unfinished. I did have a couple machines with the "condition most_full" failure - one had several. I installed a brand new CADO-NFS on that one and haven't seen the error anymore.

[VBCurtis]

Update: Q=49.2M, 111.2M total relations. Average yield: 111.2/47.2 = 2.36.

Yield since last update (Q=34.2M): 38.9M / 15M = 2.59. At the current yield, we'll get ~75M more relations for a total approaching 190M relations. That leaves ~850M for nfs@home to sieve.

We're running just over 5MQ a day, and I just added 10 threads. If Ed continues his support, we'll finish Monday the 11th.

[EdH]

Originally Posted by VBCurtis

Update: Q=49.2M, 111.2M total relations. Average yield: 111.2/47.2 = 2.36.

Yield since last update (Q=34.2M): 38.9M / 15M = 2.59. At the current yield, we'll get ~75M more relations for a total approaching 190M relations. That leaves ~850M for nfs@home to sieve.

We're running just over 5MQ a day, and I just added 10 threads. If Ed continues his support, we'll finish Monday the 11th.

I expect to see this through and even just added the machine that finished the c178 HCN today.

[axn]

Server unreachable for 40 minutes. Problem at my end or server?