![]() |
|
|
#1 |
|
"Ed Hall"
Dec 2009
Adirondack Mtns
381710 Posts |
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? |
|
|
|
|
|
#2 |
|
"Frank <^>"
Dec 2004
CDP Janesville
1000010010102 Posts |
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?) |
|
|
|
|
|
#3 | |
|
"Ed Hall"
Dec 2009
Adirondack Mtns
11·347 Posts |
Quote:
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. |
|
|
|
|
![]() |
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 |