Update 1602930 1615782 1622988 1643976 1735032 1749144 1819920 1836408
Update 1870116 1873956 1890756 1909800 1914318 1921092 1941636 1946760

Drop 1414194 (2^3*3, ECMed C117)

Update 1456104

Update 1574574 1834488 1853910 1713100 1533048 1881684
Drop 1886736

Update 1638700 1535316 1709424 1510992 1717680 1722120
Update 1493082 1536576 1532964 1523016 1597830 1726506
Update 1536144 1459180 1464400

The next bunch of sequences I reserve in the comming weeks for yafu@home will be 1.4e6 - 1.5e6. It would be good if most of them are up to a C110.

Take 1528680

[QUOTE=yoyo;484251]The next bunch of sequences I reserve in the comming weeks for yafu@home will be 1.4e6 - 1.5e6. It would be good if most of them are up to a C110.[/QUOTE]

I'm confused ... I would have thought yafu@home was really, really good at doing the early work on sequences, and dropped off once individual GNFS jobs started taking tens of hours. I would have expected yafu@home's mission statement to be 'take sequences up to C120 from wherever they started'

Taking 158592

[QUOTE=fivemack;484268]I'm confused ... I would have thought yafu@home was really, really good at doing the early work on sequences, and dropped off once individual GNFS jobs started taking tens of hours. I would have expected yafu@home's mission statement to be 'take sequences up to C120 from wherever they started'[/QUOTE]

I increased the mission, since there are more volunteers with much power full machines. So the current missions are:
a) sequences < 11e4 run up to C144
b) sequences > 1e6 run up to C134

Taking 1582896

Reserving 534564.

[QUOTE=yoyo;484290]I increased the mission, since there are more volunteers with much power full machines. So the current missions are:
a) sequences < 11e4 run up to C144
b) sequences > 1e6 run up to C134[/QUOTE]

Egads!

[code]INFO mfaliquot.application.reservations:108: mass reservee yafu@home: add 5611 seqs, drop 94[/code]

That means yafu@home has 55% of the entire 0 - 2e6 range reserved!

Also, as may be noted by sorting on the priority column, this is putting significant new strain on the "reserved sequences are updated every 14 days" rule. I would prefer to let it play out over the next day or two and see how sustainable this rule is longterm with the newly enlargened count of reserved sequences. If it turns out not to be so, I'll reconsider my earlier decision to try and avoid special-casing yafu@home as relates to update priority. (Though, truthfully, I expect it is sustainable. We'll see in a day or two.)

Drop 1582896

[QUOTE=Dubslow;484326]That means yafu@home has 55% of the entire 0 - 2e6 range reserved![/QUOTE]
And there are only 899 unreserved sequences below 1M.

[QUOTE=Dubslow;484326]Egads!

[code]INFO mfaliquot.application.reservations:108: mass reservee yafu@home: add 5611 seqs, drop 94[/code]

That means yafu@home has 55% of the entire 0 - 2e6 range reserved!

Also, as may be noted by sorting on the priority column, this is putting significant new strain on the "reserved sequences are updated every 14 days" rule. I would prefer to let it play out over the next day or two and see how sustainable this rule is longterm with the newly enlargened count of reserved sequences. If it turns out not to be so, I'll reconsider my earlier decision to try and avoid special-casing yafu@home as relates to update priority. (Though, truthfully, I expect it is sustainable. We'll see in a day or two.)[/QUOTE]

Yes, my reservation script was running amok. But once a composite is done and the sequence is not according the mission above, the workgenerator will release the sequence. This will have the advantage, that also downdrivers are released ;-)

Taking 1423470 1952368 1978410 1957392

Taking 1974882

Reserving 201978.

Taking 1597800

Taking 957540 1960560 1977668 1971136 1979580

[QUOTE=yoyo;484347]But once a composite is done and the sequence is not according the mission above, the workgenerator will release the sequence. This will have the advantage, that also downdrivers are released ;-)[/QUOTE]

I'll say! :w00t:

Taking 1981266 623580

[QUOTE=yoyo;484251]The next bunch of sequences I reserve in the comming weeks for yafu@home will be 1.4e6 - 1.5e6. It would be good if most of them are up to a C110.[/QUOTE]

[QUOTE=yoyo;484290]I increased the mission, since there are more volunteers with much power full machines. So the current missions are:
a) sequences < 11e4 run up to C144
b) sequences > 1e6 run up to C134[/QUOTE]

[QUOTE=yoyo;484347]Yes, my reservation script was running amok. But once a composite is done and the sequence is not according the mission above, the workgenerator will release the sequence. This will have the advantage, that also downdrivers are released ;-)[/QUOTE]

You seem to contradict yourself. Can you please clarify your mission? The second post seems to imply that:

1. You will run [B][I]all[/I][/B] sequences < 110e3 to C144.

2. You will run [B][I]all[/I][/B] sequences > 1e6 to C134.

Is that correct? If so that leaves very little for the rest of us except a bunch of sequences > 110e3 and < 1e6 that are almost all tested to a size of > 140.

In the first post you stated you were only reserving 1.4e6-1.5e6. That seems reasonable enough but is completely different from your second post.

In the third post you state that you will be releasing downdrivers at some point if they no longer meet the "mission" but you did not state which mission (There appears to be two of them.) or at what point you were referring to.

I am lost. More questions:

1. Exactly what sequences are you reserving?
2. What is the criteria that you are using to reserve them? Do they have to have a size of > 110?
3. What criteria will cause you to drop them? When they are at size < 110?

Please enlighten me. Thanks.

Part of the puzzle is that yafu@home keeps multiple "tiers" of numbers available for various kinds of client computers (since it does no workunit=single composite progress saving or sharing, meaning a composite is factored all on one computer). Some clients have hardware that can do C140s in a reasonable time, some don't. That's why the table was extended to 2e6 in the first place, because collective progress was squeezing out the smaller clients who can't do C140s. At any rate, the upshot is that reservations are split among those two tiers. That middle quote of yours is I think very-long-term goals, for which the first quote is an intermediate short term goal for the smaller client tier, and is, I think, the current "release" target per the third quote (even though it says "mission", which was only previously used in the second quote). (Not sure what the specifics of the higher tier are, but it's fairly analogously similar to the smaller tier's intermediate rules I'm sure.)

OK quote one is the near-term reservation and quote two is the long-term goal. Is that correct?

I still don't get this whole releasing of downdrivers. So are they saying that they will not work on sequences that are below a certain size? In other words release the downdriver if it has gotten to too small of a size? If so what size? Was he implying 110?

I have noticed how slowly Yoyo seems to progress on sequences with a size of < 100; most of which are downdrivers. Perhaps they could release anything size < 100. Then we would have a ton of downdrivers to work on. :-)

This is just my gut feeling and I have no knowledge of yoyo's intentions. If he has too many "small number" sequences, then his server will become overflowed with many send/receive request because the numbers are being factored way too fast to keep up.

[QUOTE=gd_barnes;484492]OK quote one is the near-term reservation and quote two is the long-term goal. Is that correct?[/quote]

My best interpretation. Can't truly say if it's correct or not.

[QUOTE=gd_barnes;484492]
I still don't get this whole releasing of downdrivers. So are they saying that they will not work on sequences that are below a certain size? In other words release the downdriver if it has gotten to too small of a size? If so what size? Was he implying 110?
[/QUOTE]


Err.. actually I'm not sure what that means any more. Probably something about composite size versus sequence size, so even if it has recently developed a downdriver it may still have composites over the limit. At any rate I know the scripts have released several downdrivers already -- Batalov gobbled them up quickly.

OK let them release all the sequences with size < 100. :smile:

To make it clear.

Long term goal:
a) run all sequences < 1e6 to C144
b) run all sequences > 1e6 to C134

Short term currently I reserved:
for a) sequences < 110e3
for b) sequences between 1e6 and 1.4e6
When my queues runs low I will reserve a further bunch of sequences
for a) maybe up to 150e3
for b) up to 1.5e6 as mentioned earlier.

Independent of this I have currently reserved sequences outside of this range because of 2 reasons:
a) my reserve script was doing wrong and reserved too much, as mentioned here some days ago
b) at the beginning, as we enlarged the blue page to 2e6, I reserved just sequences with smallest size, means also sequences outside above ranges. It was blamed in this forum, that I catch all small sizes. So, I changed to above missions and keep the remaining open for others.
Some of those sequences I still own. Those will be released and those might be downdriver.

Drop 1809480 (2^2*7, ECMed C122)
Drop 1844040 (2*3*ECMed C116)

Taking 1506648 1606554

Taking 1546272

Update 1679436 1828680 1795536 1711638
Reserving 1946946 1989288 1877280

[QUOTE=yoyo;484517]
Long term goal:
a) run all sequences < 1e6 to C144
b) run all sequences > 1e6 to C134
[/QUOTE]

Can we assume these sequences has some ECM work before releasing?

reserving 1073310

[QUOTE=unconnected;484535]Can we assume these sequences has some ECM work before releasing?[/QUOTE]

No.
Composites are sent to hundred of volunteers fully automatic and they run always a complete yafu factorization. If composite gets too large the sequence will e released.

Statistics about yafu@home are here [url]https://boincstats.com/en/stats/121/project/detail[/url].
You can see that currently 2900 hosts are active (I assume active means they returned at least one factorization in the last 60 days).

Wow, that's a substantial computer power! I realized now why you are reserving so many sequences :smile:

Reserving 1740432

Reserving 746856 1950660

Update 887118 1780350 1943424 1585800 126000 1999500 1655904 493374 1999644
Update 142302 1635576 236400 1743624 1420464 1537038 1414944

Drop 887118 1943424 1999500 493374 1999644 142302 1635576 236400 1743624
Drop 1420464 1537038 1414944

Drop 1667820

Taking 1965024 683628

[QUOTE=unconnected;484535]Can we assume these sequences has some ECM work before releasing?[/QUOTE]
Agree, it should be nice, at least for those escaping into the upper side (for the lower/mid sides the ECM doesn't take longer, and a new asignee will do it again anyhow). Aliqueit has the "-d" and "-c" and "-b" switches that cooperate very well to achieve this goal (however I don't know if yoyo's boinc-ify uses aliqueit).

[QUOTE=yoyo;484561]No.
Composites are sent to hundred of volunteers fully automatic and they run always a complete yafu factorization. If composite gets too large the sequence will e released.

Statistics about yafu@home are here [URL]https://boincstats.com/en/stats/121/project/detail[/URL].
You can see that currently 2900 hosts are active (I assume active means they returned at least one factorization in the last 60 days).[/QUOTE]
The window was opened yesterday and the reply incomplete, I didn't refresh before posting the above. yafu can only do ecm, and it can use -e switch to skip the ECM phase, and if you use something similar to aliqueit to pass them composites, then you can use -c switch in it to tell yafu "do only ecm if the composite is larger than xxx digits". Otherwise a lot of time will be lost because everybody will have to switch to re-do ecm for all composites, because we will have no way to know which composites come from yoyo@home and which come from other "crumblers". These other "crumblers" (me included) have the habit to well-ecm composites and only abandon a sequence if a composite is large enough and it passes a certain ecm kicks and punches....

Again, no.
You can do this if you handle each composite individually. As I stated, I do a mass handling and the workflow is, that a composite is send to a volunteer to factorize it and send the factors back and the factors are reported to factordb. This is done many thousands times per day and fully automated.
To handle "some" composites different a complete new automated workflow has to be implemented.
That is not so easy as you do it by handling each composite individually.

Would it be possible to run the yafu binary on yafu@home in ecm only mode with an upper limit one time before releasing the sequence once the composite is found to be too large? That would somehow simulate the aliqueit -c option where some level of ecm is done before ending the sequence.

I checked the yafu docfile.txt but couldn't find an option to just do ecm up to a certain level and then quit. Yafu@home uses the yafu binary not aliqueit.

One could think of a more elaborate setup where a large cofactor is handed over to yoyo@home (which has a standalone ecm capability) which then reports back to yafu if a factor was found or not and yafu can then either continue or release the sequence. As yoyo already wrote this is not trivial to implement and automate when dealing with two BOINC projects. I recently had the idea of implementing a [URL="https://en.wikipedia.org/wiki/Blackboard_system"]blackboard system[/URL] for this where yoyo@home and yafu@home act as knowledge sources and a central blackboard stores and controls the sequences and composites.

Drop 1735956 1426920 1548258 1602930 1602396 1780350 126000 1585800

Update 1842768 1659720 1685208
Take 1551396 1506312

Take 1778400

Drop 1299168 1427496

[QUOTE=ChristianB;484656]
I checked the yafu docfile.txt but couldn't find an option to just do ecm up to a certain level and then quit. [/QUOTE]

This is exactly what you want. From docfile:

[code]-pretest [num] Use this switch with factor() for ECM pretesting of the input number.
Optionally provide an integer value specifing the maximum level of
pretesting to do (up to "num" digits, or a t-level of "num")

[/code]I use it this way to crack some composite numbers in automatic mode.
[CODE]./yafu "factor(@)" -threads 8 -batchfile list -pretest 25 -of out.txt[/CODE]

And exactly the way aliqueit is calling yafu if you use combination of "-c" "-d" "-b" switches. My aliqueit command line is usually (example):

aliqueit -p -y -c 145 -d 150 1664496

or, for <7-digits starters:

aliqueit -p -y -c 150 -d 160 -b 731424

the "-b" switch exits when both former conditions are true. This will call yafu in such a way that it will go to nfs only if after ecm, the conditions are not fulfilled. For the last line, if a composite with more than 150 digits survives ecm and the size of the sequence is over 160, yafu/aliqueit will quit, and the remaining composite is well ecm'd (as well as the yafu.ini says, which in my case is .33)

I'm taking 1995288! Suck on that Batalov! :razz:

Taking 1974840 739032 672294

[QUOTE=Dubslow;484682]I'm taking 1995288! Suck on that Batalov! :razz:[/QUOTE]

The reward for my diligence was barely 4 digits of size decrease before a fat D4 landed in my face. :yucky:

:pb:
'Diligence'?
Uncalled-for rudeness, I think the words you were looking for.

And with this mouth you kiss your mother? ;-)

[QUOTE=unconnected;484667]This is exactly what you want. From docfile:

[code]-pretest [num] Use this switch with factor() for ECM pretesting of the input number.
Optionally provide an integer value specifing the maximum level of
pretesting to do (up to "num" digits, or a t-level of "num")

[/code]I use it this way to crack some composite numbers in automatic mode.
[CODE]./yafu "factor(@)" -threads 8 -batchfile list -pretest 25 -of out.txt[/CODE][/QUOTE]

But using -pretest with factor() will still factor the number. This is not what we want at yafu@home. If the composite is above the limit for this type of computer there should be no nfs stage only ecm even if that fails to factor the number.

Reserving 1758312

Taking 173460 324072

Drop 1630704 (2^3*3, ECMed C116)
Drop 1546272 (2^4*3, ECMed C113)
Drop 1785088 (2*3, ECMed C116)
Drop 1424760 (2^2*7, ECMed C115)
Drop 1697584 (2^2*3*7*ECMed C115)
Drop 1918080 (2^4*3*5*ECMed C123)
Drop 559368 (2^5*5, C141 cofactor with 4000@3e6 ECM)
Drop 868704 (2^4*3, C146 cofactor with 4000@3e6 ECM)

Take 1596564 1692396

Taking 1932360

Drop 1509198 1513848 1417668 1759368 1756584 1649550 1627548 1503642 1445340 1466496

Update 1627344 1857192 1594044 1423848

Taking 357280 832518 405420 1970220

[QUOTE=ChristianB;484702]But using -pretest with factor() will still factor the number. This is not what we want at yafu@home. If the composite is above the limit for this type of computer there should be no nfs stage only ecm even if that fails to factor the number.[/QUOTE]
Did you try the command? Create a text file, say call it rsa120.num, and paste the RSA120 number inside, don't forget to add cr/lf (my version of yafu still skips the last line in the text if there is no cr/lf after it!), save it in the current folder where yafu is,

[CODE]227010481295437363334259960947493668895875336466084780038173258247009162675779735389791151574049166747880487470296548479

[/CODE]
then call:


[CODE]yafu factor(@) -v -batchfile rsa120.num -pretest[/CODE](note that the number is not needed, and the values in yafu.ini will be used)

Taking 1979692.

Taking 1510992 1536576

Dropping 1408386 1727640 1711872 1713628 1354416 1337544 1789560 1660596 1689618 1605888 1943952 1756864 1660824 1356258 1351932 1315392 1471452 1429988 1416700 1883484 1882728 1417878 1309470 1995288

and update 1254792 and 1487076

Reserving 1852032.

Reserving 1675032.

Update 1740432

Update 1599750 1590696
Reserving 1953816 1955616 530700 558600

Drop 1602396 (2^2*3^2*5*7*ECMed C119)
Drop 1460316 (2^3*3^2*13*ECMed C119)
Drop 1723992 (2^2*3*7, ECMed C121)
Drop 1921092 (2^3*3*7, ECMed C115)
Drop 1548258 (2^3*3, ECMed C116)
Drop 1702360 (2^3*3, ECMed C117)
Drop 1602930 (2^5*3, ECMed C115)

Reserving 707430.

Update 1988190 1441890 1828680
Drop 656616

Update 1979580 1974882 1974840 1758312 1567848 1970220

[QUOTE=LaurV;484827]Did you try the command?[/QUOTE]

I did just now and it works as you say which is not what I expected after reading the description in the docfile.txt. It seems a viable way to pretest composites before yafu releases a sequence.

Drop 1638648 (2^2*3^3*7^2, ECMed C115)
Drop 1486230 (2^2*3*7, ECMed C115)
Drop 1652580 (2^2*3*ECMed C117)
Drop 1593192 (2^2*7, ECMed C119)
Drop 1757088 (2^2*3^3*ECMed C118)
Drop 1927614 (2*3^2*ECMed C114)
Drop 1781940 (2*3*ECMed C115)
Drop 1735956 (2*3, ECMed C112)

Update 1445094 1442952 1839192 1973532 1641840 1726340 1833528 1436760
Update 1799490 1914804 1653420 1810830 1544760 1413036 1660128 1714380
Update 1625610 1821876 1912800 1569660

Reserving 985428

Drop 1927492 (2^4*3*5*31*ECMed C114)
Drop 1506648 (2^3*3, ECMed C120)

Drop 1740432

Reserve 1923460

Taking 885726 1988484

Taking 415080
Update 1536576

Update 1871440 1553382 1624200 1742478 1530378 1737260 1720944 1995120 1715880

Drop 1871440 1470600

Update 1918500 1946946
Drop 1536576

Taking 1456980

Drop 1456980

Drop 1946946
Update 1419084

Drop 1923460

Take 1675248

Taking 667926 1999854 1078896

Taking 1987692