mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > Aliquot Sequences

Reply
 
Thread Tools
Old 2010-12-27, 17:21   #1
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

368910 Posts
Default Duplication of work: local vs. db

I have noticed that on occasion the db will get ahead of my machines for a few indices for aliquot sequences. This occurs when my automatic submit, updates the db while the machine is working on a smaller cofactor, such as a c84. The c84 hits the db and gets placed in the "Composite numbers without known factors" list. It then gets processed by the db/workers and advances the sequence - sometimes, several lines past where my machine is, due to processing the c84 at a slower speed locally, while the db is ECMing the next lines. This results in duplicated effort.

I suppose the simplest solution would be to submit updates on a less frequent basis, although I prefer keeping the db as up-to-date as possible with my progress. A more complex solution would be to somehow determine if the db would work the composite and let it, picking up the new info from the db after the work. Although seeming to "sound" faster, this would lend to the question of what to do with the machine while it waits.

For myself, I am leaning toward a routine that inhibits submitting to the db on the regular schedule, if the current factoring involves a composite smaller than 95. As time permits, I will probably add that code to AliWin and my linux program that I run alongside Aliqueit on my Ubuntu machines.

Thoughts?
EdH is offline   Reply With Quote
Old 2010-12-31, 01:11   #2
schickel
 
schickel's Avatar
 
"Frank <^>"
Dec 2004
CDP Janesville

2·1,061 Posts
Default

I would say the "don't submit if co-factor is less that <some number of digits>" would be the easiest. I very rarely have this problem, as all my work is >100 digits unless I am working a downdriver. But since I do everything locally anyway, even with the downdriver I don't have that problem because I generally only upload after losing the downdriver. Not that I've had many opportunities to have that problem lately anyway....

(Or something like that....re-reading that paragraph, I managed to twist it into a pretzel, didn't I?)
schickel is offline   Reply With Quote
Old 2010-12-31, 04:30   #3
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

E6916 Posts
Default

Quote:
Originally Posted by schickel View Post
... I very rarely have this problem, as all my work is >100 digits unless I am working a downdriver...
I wasn't referring to the new composites, which are mostly >100. I was referring to submitting a partial index such as:

composite<102> = p1 * p2 * p3 * c86

My instance of Aliqueit invokes SIQS and starts gathering relations for a couple hours. During the first few minutes, the c86 makes the top of the shortest unsolved composite list and gets factored by much faster machines than mine. The db then does its ECMing and moves several lines further than where I'm "stuck" gathering relations that really aren't needed any longer.

But, I probably just stumbled on a couple and they are really more rare than my two would suggest. Also a couple hours now and then of duplicate effort probably isn't as big a waste as other activities I do with these machines.

Agree, though, that the simple solution to what may not even be a real problem, is just to hold back submissions. It would be better in the bigger picture not to add that little extra to the db, anyway.
EdH is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Duplication of Effort for Smaller Aliquot Sequences EdH Aliquot Sequences 3 2018-04-17 13:31
Quote from a local paper. ishkibibble Science & Technology 0 2012-12-22 02:53
2801^79-1; thoughts on duplication sampling fivemack Factoring 0 2010-04-15 22:23
rc.local in SuSE linux? patrik Linux 3 2006-09-25 14:00
Affinity setting in local.ini PageFault Software 1 2006-09-13 16:39

All times are UTC. The time now is 09:01.

Mon Apr 19 09:01:00 UTC 2021 up 11 days, 3:41, 0 users, load averages: 1.32, 1.47, 1.40

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.