Well, I would like to know for example if it would make sense to use a X79 based motherboard. It has a quad channel memory instead of a dual channel memory. Does anyone have one?

I see serious differences between systems with identical processors. That may be just different memory speeds. If a 2,0 Ghz Xeon can outpace an ordinary quad core running at 2,4 Ghz by such a wide margin, I would like to know which component contributes what to the final results.

[QUOTE=chalsall;364130]Incorrect. Memory bandwidth can be very important.[/QUOTE]

Oh no no I didn't mean that. I thought this discussion was about the bits moving between components (i.e. between the RAM and CPU). I know full well the importance of the RAM bandwidth (I need 20% faster RAM to unbottleneck myself, as a matter of fact)

[QUOTE=TheMawn;364133]Oh no no I didn't mean that. I thought this discussion was about the bits moving between components (i.e. between the RAM and CPU). I know full well the importance of the RAM bandwidth (I need 20% faster RAM to unbottleneck myself, as a matter of fact)[/QUOTE]

??

This is about that, what else? RAM moving within RAM? :razz:

I donno. The connections between the RAM and the CPU? Like the actual electrical signals moving across the board? To be fair I didn't exactly understand what the question meant.

Now I'm confused too :razz:. Memory bandwidth is the memory moved from RAM to CPU, CPU to RAM, (chipset, HDD, blah blah)

Please tell me if I'm wrong, I'm not exactly the most knowing in this area.

Memory bandwidth is when bits move inside of my computers.
Blah blah blah is when bits move inside of your computers.
No matter from which component to which..

[QUOTE=kracker;364145]??

This is about that, what else? RAM moving within RAM? :razz:[/QUOTE]

I think he's meaning latency between RAM and CPU (not the bandwidth), id est the fact that the signal can only travel at c (which is not an issue) and not the actual amount of data that can be transmitted in any given time.

Memory bandwidth is the total data throughput of the connection between ram and the cpu.
On a fast cpu it is possible to saturate this with only 3 cores. In this case four 3 Ghz cores would run as fast as four 4 Ghz cores because the memory bandwidth can only handle 12 Ghz of throughput in total.
The cpu caches have much higher bandwidth than ram but are usually way too small.
In the haswells there are a few chips with suffix R that have 128MB of eDRAM built into them as L4 cache. This has very high bandwidth but is not large enough for the tests done by GIMPS currently(for 4 tests at least). LLR tests could benefit massively as they are in general smaller and will fit in it.
Latency doesn't really matter that much for GIMPS because of the way it is optimized.

[QUOTE=henryzz;364362]Latency doesn't really matter that much for GIMPS because of the way it is optimized.[/QUOTE]

Happy to be corrected, but what I have found (empirically) is having each processor leverage on their individual immediate memory caches whenever possible is optimal.

[QUOTE=chalsall;364364]Happy to be corrected, but what I have found (empirically) is having each processor leverage on their individual immediate memory caches whenever possible is optimal.[/QUOTE]
The difference between cache and ram might be worthwhile but the difference between 9-9-9-27 and 8-8-8-24 isn't very big.

Hey Chris, I have some issues with you! :razz:

First, there is no 37M available from GPU72 for DC, as we discussed before. I had to take a couple of them directly from PrimeNet to give some work to do to my card. Remember, some FFT with power of 2 which works for 37M expos is about 30% more efficient on GCN cards (which we discussed in the clLucas' thread). Now I switched that card to DCTF so you don't need to take any action, jut let you know. The 37M expos reserved for DC magically disappeared from gpu72 assignemnt page.

Second, last of the exponents from the batch was a mismatch, [URL="http://www.mersenne.org/report_exponent/?exp_lo=37000291&exp_hi=&B1=Get+status"]37000291[/URL], so I did a TC to his majesty and turned out my DC was good and original residue was bad (unless there is a bug in clLucas, because both DC and TC were done with the same software, on the same card, and they matched - edit: I am still keeping the residues till problem solved). So, if someone else is reserving this expo for GPU work, they will work in vain. Therfore I am thinking that the exponent is a very good candidate for your R7 systems, if any of them is free...

Before someone else grabs it...

If it's ok, I grabbed it to test a newer system I have... :smile:

If it please your majesty... a few 38M exponents as well?:smile:

[QUOTE=kracker;364396]If it please your majesty... a few 38M exponents as well?:smile:[/QUOTE]

Please don't even make that joke (and I understand and appreciate that it was a joke).

If anything, I am your servant. You are not a subject... :wink:

Let me see what I can do....

[QUOTE=LaurV;364385]Second, last of the exponents from the batch was a mismatch, [URL="http://www.mersenne.org/report_exponent/?exp_lo=37000291&exp_hi=&B1=Get+status"]37000291[/URL]...[/QUOTE]
[URL="http://www.mersenne.org/report_exponent/?exp_lo=37000291&exp_hi=10000&B1=Get+status"]Done[/URL]

We switched few of our cores to assignments directly from PrimeNet until GPU72 decides to give us the assignment types we requested, i.e. DC, and not P-1, see a former discussion about a rebel core which didn't want to get the right type of assignments from gpu72, now the plague spreaded to other cores too, therefore we killed the proxy and hung its groins on the gate...:smile: for everybody to see that we killed it. We are going to finish the (wrong type of) assignments we got, but we will not request other through the Gpu72 proxy for a while, from those cores.

Just to let you know.

OTOH, we are doing now TF to 71 for all (30-33M) exponents we got for DC. We can do 53 of those things in the same time we do one DC, so if we find a factor, this DC is cleared (and deleted from our list) and we save/gain some time. We already found a factor for [URL="http://www.mersenne.org/report_exponent/?exp_lo=31388729&exp_hi=&B1=Get+status"]31388729[/URL], (nice one, starts with 1234...., unreported yet, it will be reported automatically when its time come by the batch, in aout one hour). This credit also does not go to Gpu72 (i.e. will not be seen on those nice graphics, but it can be seen on Gimps), as we didn't get the TF assignments from there. Sorry. We can't do better for now, till the problem is solved.

[QUOTE=LaurV;364834]
OTOH, we are doing now TF to 71 for all (30-33M) exponents we got for DC. We can do 53 of those things in the same time we do one DC, so if we find a factor, this DC is cleared (and deleted from our list) and we save/gain some time. [/QUOTE]

This does not make sense if all those 30-33M are already TFed to 70 bits. Assuming you are using the same hardware, by doing TF to 71 you clear 53/71 exponents in the same time you do a DC. So how exactly are you saving/gaining time?

[QUOTE=garo;364837]This does not make sense if all those 30-33M are already TFed to 70 bits.[/QUOTE]

Every DC candidate below [URL="https://www.gpu72.com/reports/current_level/"]33M is already TFed to at least 70 "bits".[/URL] Every available DC candidate in the 33M range is TFed to at least 71 bits.

[QUOTE=garo;364837]This does not make sense if all those 30-33M are already TFed to 70 bits. Assuming you are using the same hardware, by doing TF to 71 you clear 53/71 exponents in the same time you do a DC. So how exactly are you saving/gaining time?[/QUOTE]

Well, it depends on your luck :D. In fact your chances are lower, considering that some P-1 was also done on the range (like 53 in about 90, and not 71). But I am a lucky guy, see below.

You do not "clear" 53 exponents in this time. You [B][U]try[/U][/B] to clear them, that is why is called [U]trial[/U] factoring. You may be lucky and find factors [U]faster[/U] then it would take you to do a complete DC, therefore "clearing" those exponents for which you found factors. You also might be unlucky, and find no factor, in this case the DC LL tests still will have to run for all of them, so you [U]wasted[/U] the time spent to do TF.

You may also stop immediately after you found a factor, therefore the rest of the time is "saved".

Now put into the equation the number of TF you can run in the same time you could do a DC (yes, on the same GPU hardware, don't count the CPU), and the probability to find a factor for exponents you got, and you will have a system which you can solve and see how much TF you need to do, to "gain". Factor your luck inside :razz:

Concrete: I found 2 factors (the one mentioned before, and 31420847 factored few minutes after) in 6 hours, going through the 27 exponents I had assigned last night (with a single gtx580, it takes 23 minutes and 19 seconds to do a 31M from 70 to 71). To do two full DC tests on the same card it would take 50 hours. So, I "gained/saved" 44 hours of work to clean those 2 exponents.

Of course, it is like trading Forex, you are not always so lucky, but probabilistically I am on plus side, that is why I am still doing it.

What was your question, again? :razz:

[QUOTE=LaurV;364867]Well, it depends on your luck :D. In fact your chances are lower, considering that some P-1 was also done on the range (like 53 in about 90, and not 71). But I am a lucky guy, see below.
<snip>

Of course, it is like trading Forex, you are not always so lucky, but probabilistically I am on plus side, that is why I am still doing it.

What was your question, again? :razz:[/QUOTE]

Right! Let us work against probability on a maths project. Nice one.

[QUOTE=LaurV;364867]

You also might be unlucky, and find no factor, in this case the DC LL tests still will have to run for all of them, so you [U]wasted[/U] the time spent to do TF.

[/QUOTE]

Wasted? Not necessarily. You've just doubled the depth the exponents have been TF'd to, which (if there is ever a reason or desire to prove one or more factors for these exponents) gives a higher ground to search from. Plus, it allows the GPU to do what it is best at (TF) instead of work that is better fitted for CPUs.

[QUOTE=kracker;342139]It would be nice, if there was a graph for Dc and LL, along with P-1 in the monthly, weekly graphs, etc.:smile:[/QUOTE]

Sorry [URL="https://www.gpu72.com/graphs/lldc/year/"]this new graph[/URL] took seven months longer than promised (ironically, only took an hour to implement; needed to get away from "real work" for a little while)...

At the bottom of all the [URL="https://www.gpu72.com/reports/overall/graph/month/"]overall graphs pages[/URL].

[QUOTE=chalsall;365432]Sorry [URL="https://www.gpu72.com/graphs/lldc/year/"]this new graph[/URL] took seven months longer than promised (ironically, only took an hour to implement; needed to get away from "real work" for a little while)...

At the bottom of all the [URL="https://www.gpu72.com/reports/overall/graph/month/"]overall graphs pages[/URL].[/QUOTE]

Thank you! :smile: :bow:

EDIT: And I know you're the main in DC on that graph... :razz:

I just hit a dry spell; none of the 100 DC TF exponents I just finished testing a single factor between 68 and 71 bits. It seems luck wasn't on my side this time. :sad:

[QUOTE=chalsall;365432]Sorry [URL="https://www.gpu72.com/graphs/lldc/year/"]this new graph[/URL] took seven months longer than promised (ironically, only took an hour to implement; needed to get away from "real work" for a little while)...

At the bottom of all the [URL="https://www.gpu72.com/reports/overall/graph/month/"]overall graphs pages[/URL].[/QUOTE]

What ranges are those graphs for? Pulling data ~weekly from the Classic GIMPS status page[SIZE="2"][SUP]TM[/SUP][/SIZE], I have been seeing changes of ~100-150 per day for the TwoLL column and ~190->115 in the OneLL column.

The attached graph has the rate of change in #/day on the left, P90 years on right. The data are taken ~168 hours (plus minus 8 hours) apart.

[QUOTE=ixfd64;365450]I just hit a dry spell; none of the 100 DC TF exponents I just finished testing a single factor between 68 and 71 bits. It seems luck wasn't on my side this time. :sad:[/QUOTE]

This is quite a statistical anomalie, isn't it? Should have found 4.

Could it be that P1 found most of them?

[QUOTE=petrw1;365470]This is quite a statistical anomalie, isn't it? Should have found 4.

Could it be that P1 found most of them?[/QUOTE]
It happens quite often: I have a boxxen doing 65->66 bits for 317-319M range, 1 factor out of 308 reported thus far, found after 249 unsuccessful attempts. I "should" have a good 4.7, but remember- probability has no memory...

[QUOTE=ixfd64;365450]I just hit a dry spell; none of the 100 DC TF exponents I just finished testing a single factor between 68 and 71 bits. It seems luck wasn't on my side this time. :sad:[/QUOTE]

Using LaurV's logic you are unlucky so you should stop doing any TF.:davieddy: While you have been unlucky the chance of not finding a single factor in 300 trials is ~1.3% if no P-1 is done and ~5% if P-1 is done. So it does happen once in a while.

[QUOTE=garo;365495]Using LaurV's logic you are unlucky [/QUOTE]
no, it is just that the Luck is in my area now, and I did efforts to tie him on the tree in front of my window. I will release him now, so other poor guys can find some factors too, and so we won't lose them from the project... :smile:

If you want to find a lot of factors, head over to [URL="http://www.mersenne.ca/"]James' site[/URL] and do some trial factoring > 1000M. You will find a factor about every minute...though no credit is given for work less than 2[SUP]70[/SUP]

What is the odds for ten consecutive factorisations? I had the pleasure of experience it once when running the smallest unreserved candidates in 87M... :fusion:

[CODE]Manual testing 87159607 F 2013-10-31 01:23 0.0 118248780529848276167 0.2861
Manual testing 87159043 F 2013-10-31 01:23 0.0 79623647161085679929 0.1883
Manual testing 87158009 F 2013-10-31 01:23 0.0 116601936487970901887 0.2826
Manual testing 87152669 F 2013-10-31 01:23 0.0 93398301198481141913 0.2278
Manual testing 87147239 F 2013-10-31 01:23 0.0 121514141280299682623 0.2929
Manual testing 87146783 F 2013-10-31 01:23 0.0 106194288573916474753 0.2595
Manual testing 87098653 F 2013-10-31 01:23 0.0 131304203500302387847 0.3122
Manual testing 87084973 F 2013-10-31 01:23 0.0 87337664541318196823 0.2113
Manual testing 87081901 F 2013-10-31 01:23 0.0 87871100901379849463 0.2128
Manual testing 87077693 F 2013-10-31 01:23 0.0 116960802185084904127 0.2837[/CODE]My only explanation is that someone must have saved the factorizations for one massive submission or missed them all together. They must have timed out just before I grabbed them.

Ps, I know the probabbility, somewhere close to 0.015^10 = 0.58*10^-20 so someone set me up or <deity> has a sick sense of humor.

Göran

The "phenomenon" is quite common, and it happens to any of us who do TF in bunch, at least is happening to me every time when I submit :smile:. It is due to the fact that - when you submit a long list of factorization results - the server (PrimeNet) is "sorting" the list, taking the NF results first, then it goes again through the list taking the F results second. Therefore, if you have 100 factors in your list, they will appear "consecutively" in your results report, but the exponents themselves are *[B]not[/B]* consecutive (look and see!). So, no magic.

This also means if you submit in too large a batch, the server will time out before it reaches your factors found. If you're not careful, you might go into your results file and delete everything above the last processed entry... deleting all your factors found in the process.

TheMawn, that probably explains it, I got the tail end of factors from someone that accidentally deleted a bunch of factors after a timeout during reporting.:bow:

The ten factors I found was from the ten candidates I ran in 87M, it isn't a result of primenet sorting the results. I just used the result report to find the factors again, my log files are long gone.

Göran

Well, they are all in 67 bits, so, [URL="http://www.mersenne.org/report_exponent/?exp_lo=87077693&exp_hi=87159607&B1=Get+status"]from here[/URL], it is not difficult to see who the unlucky guy was [SPOILER] Freaks32, last year in March [/SPOILER]. You also did plenty of 66 and 67 there, too, before, hehe.

[QUOTE=TheMawn;365594]This also means if you submit in too large a batch, the server will time out before it reaches your factors found. If you're not careful, you might go into your results file and delete everything above the last processed entry... deleting all your factors found in the process.[/QUOTE]
Right. In this case (not all factors digested by the server), you should *[B]not delete anything[/B]* and just retry submission. Processing "no need" results is about 5-10 times faster for the server (this is not a WAG! it can be easily seen experimentally, and the explanation is probably related to the fact that in case of "no need" result, the DB is read and the error 40 is generated, but in case on "ok" result, the DB must be changed also, which takes longer) so it will go further in your list. Every time you report, you will get a couple of "error 40" or so, but it will go deeper in your list, about double the first pass. In 3, 4, 5 trials you can send whole bunches. Faster if you do not try to send during peak times when the reports are generated. I did this daily, before the Misfit era (and before having my own scripts, which I scrapped for Misfit), when I used to manually report the results. I used to send the same reports few times, until I could see the factors on screen, at the end of the report. Then only, I was deleting the files.

My own method is to break the results file into smaller chunks using copypasta. During my last 400M 65 to 68 spree, I would break the files into chunks of roughly 80 KB with an absolute maximum of 100 KB and only once in a while I would get a timeout. About 3 files per GPU per day.

I would argue that the "result not needed" files get processed more than ten times faster. However, everything else I did was the same. Make sure that the factors at the bottom of the page showed up properly, then delete the small file chunk.

For completeness, I re-checked the server for exponents below 68 in the range I did and I found five or six, which were probably reserved when I grabbed the work.

[QUOTE=TheMawn;365736]My own method [B][U]is[/U][/B] ... [/QUOTE]
"is"? Not "was"? Do you mean you don't use Misfit yet? Linux? hehe...

Chris Halsall

A factor was found for M44036591 between 70:71 it just has not been reported due to ongoing glitch, so your spider may decide to reallocate it.

Just flagging it up so you can take it out to save it being trial factored again ...

[QUOTE=LaurV;365744]"is"? Not "was"? Do you mean you don't use Misfit yet? Linux? hehe...[/QUOTE]

MISFIT FTW! :smile:

[QUOTE=bayanne;365812]A factor was found for M44036591 between 70:71 it just has not been reported due to ongoing glitch, so your spider may decide to reallocate it.

Just flagging it up so you can take it out to save it being trial factored again ...[/QUOTE]

Thanks for the heads up, but not to worry -- Primenet started accepting "Factor Found" results again.

Also, so you know, TF assignments are now very rarely automatically recycled -- the system will patiently wait for the assigned work to be finished. (I, on the other hand, am not as patient :wink:, and will often PM or e-mail the assignee asking for them to complete (or release) assignments which have been out for more than two months.)

By the way, how is the DC-TF effort going? With the primenet summary page looking a lot better, I see a big lot of "assigned" TF work. Are there charts yet to show us how the progress is, or if any 70 bits exponents are being released?

It's going, it's going. I am putting 1.5THzDays/Day into it. I may double it soon, if it does not get too hot here (Thai summer starts around March; the hottest month of the year is April). Other people do even better, i.e. they are putting more THzDays into the effort. We can keep the advance. We have the resources. The only thing we are missing right now, is the motivation... err... em.. we are not so convinced that the effort is worth (where is davieddy? :razz:). If you read my older posts, I mean to TF the 33M to 71, we have one chance in ~71 to find a factor for the exponents which are not P-1, but one in ~100 to get a factor for the exponents with P-1 done to the usual B1/B2 limits. And if you check [URL="http://www.gpu72.com/reports/factor_percentage/"]these tables[/URL] (the second one), you see I am right with the calculus. We only get one factor in a hundred trials, or 1% success rate. Now, a good GPU do about 65-75 of those per day, but it need one full day (~25 hours) to run the DC test. So, technically we are slower, about 30-40% [U]behind the schedule[/U] by continuing to TF the 33-34M to 71. We may be better doing TF to 70 only, and then do DCLL, especially for the exponents with P-1 done. [URL="http://www.mersenne.ca/cudalucas.php?model=12"]James' graphs[/URL] [edit: btw, they [B]still don't work! [/B](they show a white screen) someone should [B][U]check[/U][/B] those google charts! see my former posts] do not take into the account the fact that P-1 was done, but only if it is first time LL, or DCLL).

Of course, finding factors is cool, and irrevocable clears the exponents. So people prefer to invest a bit more in factoring right now. We still cleared more than we could DCLL since we started DCTF last week, by a very narrow margin, but as I said, we might have been lucky :razz:

We will maintain the status quo for a while, at least till the heat hits or till chalsall gets [URL="http://www.anglos.cz/download/ital2malta.mp3"]pissed on us[/URL].

Hmmm I never thought about P-1 having already been done on these exponents. Is it possible the bounds weren't optimal, given that memory was more scarce back when the 30M was being LL'ed for the first time?

Many times it was not done properly.

However, dubslow and I once did P-1 on the same exponent. He found a Brent-Suyama factor which I did not find with different memory settings. I ran it again with his same settings and found it... so what is 'properly'?

[QUOTE=TheMawn;366330]By the way, how is the DC-TF effort going? With the primenet summary page looking a lot better, I see a big lot of "assigned" TF work. Are there charts yet to show us how the progress is, or if any 70 bits exponents are being released?[/QUOTE]

The DC-TF work is going well. :smile:

We are not releasing back to Primenet anything above 33M TF'ed to below 71 for any of the three assignment classes. As far as "charts", comparing the [URL="http://mersenne.org/primenet/"]Primenet assignment summary[/URL] with the [URL="https://www.gpu72.com/reports/current_level/"]GPU72 Current Trial Factoring Depth[/URL] report should give you a good idea of our situation.

Executive summary: we've got a comfortable buffer, and are building on this. I'd like to spend another week or so doing what we're doing, and then we can start to back off on the DC-TF'ing, and move most of our resources back to LL-TF'ing.

(Except you LaurV!!! We've got a deal!!! :razz: :wink:)

[QUOTE=LaurV;366337]And if you check [URL="http://www.gpu72.com/reports/factor_percentage/"]these tables[/URL] (the second one), you see I am right with the calculus. We only get one factor in a hundred trials, or 1% success rate. Now, a good GPU do about 65-75 of those per day, but it need one full day (~25 hours) to run the DC test. So, technically we are slower, about 30-40% [U]behind the schedule[/U] by continuing to TF the 33-34M to 71.[/QUOTE]

Well, technically, the empirical success rate for TF'ing to 71 has been 1.052% (13,302 tests; one candidate eliminated for every 95 runs) in 33M, and 1.143% in 34M (although only 2,449 tests (small sample set) but one every 87.5 runs).

And, keep in mind that LL'ing gets more expensive the larger the candidate, the TF'ing get's less expensive. So, while I might agree with you that we might be just at the borderline (or even behind) going to 71 in all of 33M, doing so in 34M and above is almost certainly profitable.

(Disclaimer -- this is just my gut feeling, I haven't done an extensive analysis on this, as it will also be a function of each card's "Compute Capacity" and throughput for TF'ing vs. LL'ing. And, frankly, it's just easier making the depth transition be based on 1M ranges.)

[QUOTE=LaurV;366337]I am putting 1.5THzDays/Day into it. I may double it soon, if it does not get too hot here (Thai summer starts around March; the hottest month of the year is April).[/QUOTE]

Happy to trade another couple of my CPUs if you're willing to bring another 1.5THzD/D into DC-TF'ing (via MISFIT "Let GPU72 Decide", of course).

Just let me know.... :smile:

[QUOTE=chalsall;366375][URL="https://www.gpu72.com/reports/current_level/"]GPU72 Current Trial Factoring Depth[/URL] [/QUOTE]

Is the first darker yellow cell of a row the ideal TF limit?

[QUOTE=TheMawn;366380]Is the first darker yellow cell of a row the ideal TF limit?[/QUOTE]

Yes.

And thanks for (indirectly) pointing out that perhaps I should have language explaining this in the "Note:" section at the bottom of the page.

Also note that for the LL ranges 54M to 57M, and 60M to 73M, there are several thousand candidates held-and-issued by Primenet not yet fully appropriately TF'ed.

This is because things changed about a year ago when "GPU Sieving", and additional GPU fire-power, came on-line. We're now "dropping back down" and capturing these (when possible) when the candidates become available, to "clean up".

Announcing End of Service for Low DC and LL assignments from GPU72.
 

Hey all. Just a heads up...

With the new assignment rules enforced by Primenet, the "hack" which GPU72 used to transfer low DC and LL assignments to an "Anonymous" account which could then be taken over by the GPU72 user no longer works. I have thus disabled the spiders attempting the transfers.

Therefore, our supply of low DC and LL candidates will dwindle quickly. I will disable the manual assignment pages for these two work-types over the weekend, with an explanatory message. Low P-1 assignments will still be available, as will (of course) TF'ing work.

For those using the GPU72 Proxy for DC or LL work, you won't need to remove the proxy line in prime.txt (but you can if you want to). It will simply pass all requests onto Primenet for fulfillment, and then both Primenet and GPU72 will be aware of your assignments (and you'll get the "pretty graphs" on GPU72 for such work).

For those who want the lowest available candidates, you will need to go to [url]http://www.mersenne.org/thresholds/[/url] and commit to being a serious player in order to get the lowest available candidates.

For the record, I consider this change on Primenet to be a very positive move; by George in particular, and the GIMPS community as a whole. The low DC and LL assignments from GPU72 were quite a bit of a hack, and often caused me grief and cost me time. Having this now appropriately managed by Primenet makes a great deal more sense.

Any comments or questions, as always, are very welcome.

[QUOTE=TheMawn;366380]Is the first darker yellow cell of a row the ideal TF limit?[/QUOTE]
Let's say that the yellow cells are where we release the exponents back to PrimeNet for LL. Using the "ideal" term is debatable, as we already explained. Davieddie will be all on our heads... heheh...

[QUOTE=chalsall;366376]And, keep in mind that LL'ing gets more expensive the larger the candidate, the TF'ing get's less expensive. So, while I might agree with you that we might be just at the borderline (or even behind) going to 71 in all of 33M, doing so in 34M and above is almost certainly profitable.[/QUOTE]

[QUOTE=TheMawn;366352]Hmmm I never thought about P-1 having already been done on these exponents. Is it possible the bounds weren't optimal, given that memory was more scarce back when the 30M was being LL'ed for the first time?[/QUOTE]

[U]To clarify:[/U]

[B]All [U]DC exponents[/U] had P-1 done[/B], with (very) few exceptions which constitute errors or omissions from the server or the worker in charge with the first LL. It makes no sense to do first time LL (at the time when it was done, years ago, but now also!) without doing proper TF and P-1 first. See the [URL="http://www.mersenne.org/various/math.php"]gimps/math[/URL] page. Otherwise you may lose months (few year ago, a 33M LL took months to run on an average computer) for an expo which could be easily factored in few minutes, with some luck.

So, the [U]first time LL[/U] was only ran [B]after the TF[/B] (enough TF or not, this is arguable, at that time the GPU were not available) [B]and after the P-1[/B] (enough or not, again arguable) [B]was done.[/B] The DC exponents all had one LL done, that is why they are [U]DC[/U] (to be [U]D[/U]ouble [U]C[/U]hecked, i.e. they were checked once, now that checking process has to be verified) exponents, and not LL exponents. Is not about size, you can see in the two tables rows with the same range of exponents. Like 45M, is both in the "DC" table, and "LL" table. So, the DC exponents, they (almost) all had the P-1 done. For those of them where a factor existed in (say) 70 to 71 bits or so, the P-1 had ([SIZE=1]some chances[/SIZE]) to find the factor (we don't talk about probability of smoothness now). So, those were eliminated already from the list. Extending TF to 71, you can only find factors which were [U]not enough smooth[/U] to be found by P-1.

Therefore, here you have about 1 in a hundred chance. Or say, a bit better than 1%, as Chris pointed out. If you can run >90 TF assignments or more, to 71 bits, in your hardware, in the same amount of time you would need to do [U]ONE LL test using the same hardware[/U], than you are better doing TF. If you find a factor in 90 runs, you save time. Otherwise, if you can't do 90-100 runs, or more, then you lose time. You will clear the exponents faster if you do directly DCLL, in this last case. Of course, you will not get billions of TF credit. If you care. And you will find no factors. If you care. But you will help the project more, doing directly DCLL, and additional, you may find some missed prime, and get famous! :razz: (and rich, if George will still pay the bonus for it).

Choice is yours.

[U][B]For LL front[/B][/U], the things are different. Those exponents (in the first table at the given link) did not have a LL test yet. Regardless of their size. So, if you do LLTF and find a factor, you save TWO LL tests (the first one, and the DC) [U]and[/U] some P-1 time. Also, because no P-1 was done. And because of that, you have about 1 in 71 chances to find a factor. So, if your hardware can run 71 TF assignments or more, in the same amount of time that the same hardware would need to do [U]TWO LL tests[/U] then you better do TF (we ignore P-1 here, is insignificant).

As the time to TF doubles with every bit, but we talk now about saving a double amount of LL, we can then go one bit higher, for the same range of the exponents.

Careful, we are only comparing the same range of the exponents.

As Chris pointed (and we totally agree here, our argument was only about the 33M range, which is at the limit), [B]if the exponents get higher[/B], the TF to the [U]same bit level[/U] gets (~linearly) faster, but the LL gets (>quadratically) slower. For example, if you double the exponent, like from 30M to 60M, then the TF to 70 bits will take half of the time (the speed doubles, for 60M exponents), but the LL test of 60M will take 4 times the amount of time of a LL test of 30M, because each iteration takes (about) double of the time (with all FFT optimizations, we take the best case here), and you have to do a double number of iterations (60M instead of 30M).

Doing TF to higher bits requires (about) doubling the time (for the same exponent) for each bit level, because you have to test a double amount of factor candidates. There are two times more numbers from 2^6 to 2^7, than there are from 2^5 to 2^6.

So, we did TF our 30M exponent to 70 bits, now we can afford to TF our 60M exponent higher: one bit (to 71) to compensate the TF speed getting doubled. This will take the same amount of time (i.e. 30M to 70, and 60M to 71). Then, another 2 bits (to 73) to compensate for the LL test getting 4 times slower. This will get 4 times the initial time. But the LL test is also 4 times longer.

This should explain for everybody. More basic than this I can't explain.

The only lost end is related to P-1 part. For many people is unclear what P-1 is doing. This for the next post...

[QUOTE=LaurV;366407]Let's say that the yellow cells are where we release the exponents back to PrimeNet for LL. Using the "ideal" term is debatable, as we already explained. Davieddie will be all on our heads... heheh...[/QUOTE]

Excellent point; an important distinction.

Many thanks for the detailed explanation, LaurV. Such things are very helpful for the mathematically limited, such as me.

Time to transition back to (mostly) LL-TF'ing...
 

Hey all.

OK, as it looks like the offset for "slow and/or unknown" machines for [URL="http://www.mersenneforum.org/showthread.php?p=366434"]LL'ing is going to be 100,000 or so[/URL], I think it would be prudent if we prepared an appropriate buffer for this transition.

So, for those who switched to DC-TF'ing, thank you [B]very[/B] much for your work! If you're willing, please finish your current DC-TF assignments, and then go back to LL-TF'ing. With LaurV and myself (and sometimes Jerry) continuing to work this range, we should be good.

Also, so everyone knows, "What Makes Sense" and "Let GPU72 Decide"'s "Low" value for LL-TF'ing has been set to 66.5M temporarily. But, as always, people are free to do whatever ranges tickle their fancy.

Thanks everyone!!! :smile:

[QUOTE=chalsall;366435]Also, so everyone knows, "What Makes Sense" and "Let GPU72 Decide"'s "Low" value for LL-TF'ing has been set to 66.5M temporarily. [/QUOTE]

66.[B]2[/B]M, you mean?

[QUOTE=chalsall;366385]For those who want the lowest available candidates, you will need to go to [url]http://www.mersenne.org/thresholds/[/url] and commit to being a serious player in order to get the lowest available candidates.[/QUOTE]

So everyone knows, the GPU72 Proxy now passes all requests for DC work onto Primenet for fulfillment, but still tracks the assignments. I have also returned to Primenet the 163 low candidates not yet assigned to workers.

I will do the same thing for LL requests once the new LL assignment rules are activated on Primenet, or when the last low LL candidates have been exhausted (we currently hold 46).

Remember that if you want the lowest available candidates you need to commit to timely completion on the above linked Thresholds page, and set your "Days of Work" as defined on said page.

[QUOTE=axn;366473]66.[B]2[/B]M, you mean?[/QUOTE]

Yes... After George exposed the cut-off point for Category 4 assignments (currently 66,156,830) I adjusted the "Low" value to be 66.2M instead.

[QUOTE=chalsall;366516]... or when the last low LL candidates have been exhausted (we currently hold 46).[/QUOTE]
Could you give me some of them? Say, 15? (getassignments/ll does not work anymore, as you may know ...).

Though I understand why this step has been taken, I can't say I like it. I cannot use your proxy, so these will be my last LL tests that GPU72 will see.

[QUOTE=Bdot;366580]Though I understand why this step has been taken, I can't say I like it. I cannot use your proxy, so these will be my last LL tests that GPU72 will see.[/QUOTE]

OK, what I've done is increased your "Trust" level so you can access the reservations page on GPU72 again. If anyone else wants some, just let me know here or via PM. We only have 46 left.

And sorry for this, but it was largely out of my control. GPU72 was no longer able to transfer candidates to "Anon", and thus people couldn't take control of them.

One thing I could do is add a form (for those who can't use the Proxy) where they could inform GPU72 of the candidates they've been assigned by Primenet for LL'ing and/or DC'ing. Would this help at all?

Thank you for the "upgrade", I filled my pockets.

And yes, such a form could help keep the history ... if it's not too much effort?

I use gpu72's proxy for all my computers... Is/will there be a change?

[QUOTE=kracker;366593]I use gpu72's proxy for all my computers... Is/will there be a change?[/QUOTE]

Nope, no change from your perspective; everything will be automatically handled.

"Behind the scenes", the difference will be that Primenet will now be in control of deciding how "trustworthy" your machines are, and thus what [URL="http://www.mersenne.org/thresholds/"]category of assignments[/URL] you'll be issued.

One thing you (and everyone) should do is go to this page, and "commit" to doing assignments in a timely manner. Also, pay particular attention to the "days of work to queue" clause in the "agreement". For example, to get any available DC candidates which are in the bottom 1,500, your DoWtQ must be 10 or less.

Chris: Is there no way for GPU72 to request LL's and get whatever makes sense just like the Prime95 client does? Just fool Primenet into thinking that "GPU72" is a computer running a client and have GPU distribute everything just as it has been? Why does GPU72 need to run through an anonymous user?

As far as I can tell, GPU72 appears to be reliable and has a steady enough throughput (i.e. a really good one). Keep however many (ten?) of the smallest available exponents on hand at any one time and request more when they are taken.

[QUOTE=TheMawn;366629]Chris: Is there no way for GPU72 to request LL's and get whatever makes sense just like the Prime95 client does? Just fool Primenet into thinking that "GPU72" is a computer running a client and have GPU distribute everything just as it has been? Why does GPU72 need to run through an anonymous user?

As far as I can tell, GPU72 appears to be reliable and has a steady enough throughput (i.e. a really good one). Keep however many (ten?) of the smallest available exponents on hand at any one time and request more when they are taken.[/QUOTE]

[URL="https://www.gpu72.com/graphs/lldc/month/"]https://www.gpu72.com/graphs/lldc/month/
[/URL]
You'll need more than 10 :razz:

Those are almost all cpu through gpu72, I think.

[QUOTE=TheMawn;366629]Chris: Is there no way for GPU72 to request LL's and get whatever makes sense just like the Prime95 client does?[/QUOTE]

Trust me, I know this. And have been using this technique for years. :smile:

[QUOTE=TheMawn;366629]Why does GPU72 need to run through an anonymous user?[/QUOTE]

The only way a user can take over an assignment (and report progress) is if it was originally assigned to "Anon". This is no longer possible for anything but "Category 4" candidates, and thus the whole "Low Candidates from GPU72" offering is being discontinued.

As I said above, I consider this a positive move -- it really was quite a hack, and sometimes a pain in the butt (when it was abused by "hoarders"). It makes much more sense for Primenet to regulate the assignments.

[QUOTE=LaurV;366337]... [URL="http://www.mersenne.ca/cudalucas.php?model=12"]James' graphs[/URL] [edit: btw, they [B]still don't work! [/B](they show a white screen) someone should [B][U]check[/U][/B] those google charts! see my former posts] do not take into the account the fact that P-1 was done, but only if it is first time LL, or DCLL).[/QUOTE]Charts have been checked, and severely reprimanded for not working, and they seem to be behaving better now.

[QUOTE=chalsall;366659]The only way a user can take over an assignment (and report progress) is if it was originally assigned to "Anon".[/QUOTE]

Yes, but why?

[QUOTE=TheMawn;366692]Yes, but why?[/QUOTE]

An Engineer should always understand the "why" without having to ask the question, assuming the question has already been answered (as it has, in this case, many times).

[QUOTE=TheMawn;366692]Yes, but why?[/QUOTE]
Simple: once a key is associated with a name, it stays with that name. Imagine I can easily hack your key (which is true in this particular case, me and you :P) and then you find a prime. I mean, you find THE prime, the one which bring glory and EFF money. Try stopping me to claim that [U][B]I [/B][/U]found it! :razz:

[QUOTE=LaurV;366716]Simple: once a key is associated with a name, it stays with that name. Imagine I can easily hack your key (which is true in this particular case, me and you :P) and then you find a prime. I mean, you find THE prime, the one which bring glory and EFF money. Try stopping me to claim that [U][B]I [/B][/U]found it! :razz:[/QUOTE]
This won't be a problem for GPU72 assignments. That being said, I move that we poach Curtis Cooper's assignments, since he has likely reserved the next 7 Mersenne primes :razz:

[SPOILER]Note: Please do not poach, it is terrible for the wildlife. Only government sanctioned hunts should take place to protect the [STRIKE]rhino population[/STRIKE] integrity of the search. [/SPOILER]

[QUOTE=c10ck3r;366722]This won't be a problem for GPU72 assignments. That being said, I move that we poach Curtis Cooper's assignments, since he has likely reserved the next 7 Mersenne primes :razz:

[SPOILER]Note: Please do not poach, it is terrible for the wildlife. Only government sanctioned hunts should take place to protect the [STRIKE]rhino population[/STRIKE] integrity of the search. [/SPOILER][/QUOTE]

[spoiler]What if I like my eggs poached? They always taste better when they're stolen.[/spoiler]

[QUOTE=c10ck3r;366722]This won't be a problem for GPU72 assignments.[/QUOTE]
Sure, but the restriction was not for gpu72 assignments. In fact, nobody cares what the reason was :D it was like that, that you can not transfer already claimed assignments to other persons. When you reserve some work, you get a key, which is associated with some anon user. First time when P95 connects to the server, the key is associated with you, and that's it. To transfer it to other person, you must "unreserve" and the other guy must be [U]lucky[/U] to grab it in the same time. If you reserve work by P95, than the key is directly associated with you, if you gave the user name to P95 (in the "Test/Primenet menu box). Assignment keys can not be transferred. We are ok with this.

[QUOTE=LaurV;366716]Simple: once a key is associated with a name, it stays with that name.[/QUOTE]

Thanks, LaurV.

[QUOTE=LaurV;366727]Sure, but the restriction was not for gpu72 assignments. In fact, nobody cares what the reason was :D it was like that, that you can not transfer already claimed assignments to other persons. When you reserve some work, you get a key, which is associated with some anon user. First time when P95 connects to the server, the key is associated with you, and that's it. To transfer it to other person, you must "unreserve" and the other guy must be [U]lucky[/U] to grab it in the same time. If you reserve work by P95, than the key is directly associated with you, if you gave the user name to P95 (in the "Test/Primenet menu box). Assignment keys can not be transferred. We are ok with this.[/QUOTE]
You missed the joke; the joke being that only Curtis Cooper is assigned primes for LL.

[QUOTE=c10ck3r;366794]You missed the joke; the joke being that only Curtis Cooper is assigned primes for LL.[/QUOTE]
Ha! I totally missed that! :redface: I mean I have read the text, but I took it as some complaint for the fact that the guy is actually hoarding exponents (which he [U]did[/U] in the past, and still doing occasionally, I never liked the guys who only do LL, it looks to me very selfish, kinda Davieddie, but with more computing power, expecting other people to do your dirty work, like TF and P-1, and using the university's electricity/money - you can see I am full of envy too :razz:)

Rather than start a new thread for a bug report, I'll just note it here:

GPU72 does a bait-and-switch when selecting LLTF WMS assignment. It shows a 66.5M assignment in the preview, then gives out something else altogether as the actual assignment.

[QUOTE=axn;367364]Rather than start a new thread for a bug report, I'll just note it here:

GPU72 does a bait-and-switch when selecting LLTF WMS assignment. It shows a 66.5M assignment in the preview, then gives out something else altogether as the actual assignment.[/QUOTE]

I have found that it gives me what I select, even though the example exponents shown do not match what I have requested ...

[QUOTE=axn;367364]Rather than start a new thread for a bug report, I'll just note it here:

GPU72 does a bait-and-switch when selecting LLTF WMS assignment. It shows a 66.5M assignment in the preview, then gives out something else altogether as the actual assignment.[/QUOTE]

Too bad it's not April 1st :)

[QUOTE=axn;367364]Rather than start a new thread for a bug report, I'll just note it here:

GPU72 does a bait-and-switch when selecting LLTF WMS assignment. It shows a 66.5M assignment in the preview, then gives out something else altogether as the actual assignment.[/QUOTE]

I can verify this. I was shown a preview for 66M 71->74 (it should be to 73M anyway according to the new rules) and was given a 60M 73->74.

[QUOTE=garo;367383]I can verify this. I was shown a preview for 66M 71->74 (it should be to 73M anyway according to the new rules) and was given a 60M 73->74.[/QUOTE]

I can also attest to this particular behavior.

I too am getting 60M 73 to 74. Is this really the most optimal use of our resources at this time? I feel like releasing 60M at 73 is much less of a bad thing than releasing unfactored no P-1 69M.

Let GPU72 decide is giving me 66M 71—>73

The thing axn reported, I could verify it too, it is not an April Fool joke. You request some exponents, you see them in the sample window, then you "take" them, and you are given a (very) different range/type of expos. Yeah, I know it says that what you see may change if someone else takes work meantime, but the change was huge, and moreover, the shown expos were still available after I took the assignment. The assigned expos were still ok for me, so I queued them. But if you are really unhappy in that case, then you can use "[U]unassign all of these[/U]" button.

Normally I don't care, I let misfit and gpu72 decide. Therefore it does not matter too much. Very seldom I do "experiments" and need few expos manually assigned in different ranges.

[QUOTE=axn;367364]Rather than start a new thread for a bug report, I'll just note it here:

GPU72 does a bait-and-switch when selecting LLTF WMS assignment. It shows a 66.5M assignment in the preview, then gives out something else altogether as the actual assignment.[/QUOTE]

Thanks for the bug report. And sorry guys; not intentional. Yet another SPE -- I updated the preview code, but didn't update the actual assignment code. (Yes, it's different code; I really need to refactor that (and sleep more)....)

I have been trying to get exponents from 320m and up, but without success.
Anyone else had the same problem?

[QUOTE=bayanne;367713]I have been trying to get exponents from 320m and up, but without success.
Anyone else had the same problem?[/QUOTE]
A change happened recently. Try putting in 320,000,000 as your minimum exponent. Set your bit level and number of exponents or GHz-days. Then select "lowest exponent". That last step did not used to be required. It is now, for the higher exponents, like those in the 332M range.

[QUOTE=bayanne;367713]I have been trying to get exponents from 320m and up, but without success.
Anyone else had the same problem?[/QUOTE]

Not to tell you what to do and what not to do, but just know that the 320M range is almost the least interesting one you could pick. 100 million digits starts in 332M. 320M is not 100 million digits so if you ever invested a serious amount of work into that you wouldn't be finding a 100 million digit prime which is sort of the next thing.

On the other hand, you probably do have your reasons for looking at that range but in case you wanted 100 million digits, I just wanted to let you know.

[QUOTE=Uncwilly;367752]A change happened recently. Try putting in 320,000,000 as your minimum exponent. Set your bit level and number of exponents or GHz-days. Then select "lowest exponent". That last step did not used to be required. It is now, for the higher exponents, like those in the 332M range.[/QUOTE]

Worked fine, many thanks :smile:

What has happened to the "Production Heuristics" part of the "View Assignments" page? The headers are still there, just no info. :huh:

[QUOTE=kladner;368724]What has happened to the "Production Heuristics" part of the "View Assignments" page? The headers are still there, just no info. :huh:[/QUOTE]

Sorry... Yet another SPE...

I made a quick-and-dirty change to help another user yesterday with an issue, but didn't do the appropriate regression tests (I'm /very/ busy at the moment). Corrected.

[QUOTE=chalsall;368771]Sorry... Yet another SPE...

I made a quick-and-dirty change to help another user yesterday with an issue, but didn't do the appropriate regression tests (I'm /very/ busy at the moment). Corrected.[/QUOTE]

Thanks, Chris. It was a very minor SPE. I hope your "busy-ness" is having good results. Thanks again for all you do. :tu:

Hey Chris, can you check what's wrong with 31689991? It is being reported every hour or so, getting GPU72 credit, in spite of the fact that PrimeNet does not accept it. I mean, I like to see 5000 GHzDays of DC for me done within today, but kracker might get angry about :razz:

Now, honestly, I should keep half of that credit, because I signaled the bug... Huh? Do we share it? :razz:

OTOH, [URL="http://www.mersenne.org/report_top_500_custom/?team_flag=0&type=1004&rank_lo=39&rank_hi=40&start_date=2000-01-01&end_date=&B1=Get+Report"]hey buddy, do you feel the heat[/URL]? :razz: (no, this is serious, it does not include the bogus credit from GPU72! I am right behind of you, coming fast!)

[QUOTE=LaurV;369410]Hey Chris, can you check what's wrong with 31689991? It is being reported every hour or so, getting GPU72 credit, in spite of the fact that PrimeNet does not accept it. I mean, I like to see 5000 GHzDays of DC for me done within today...[/QUOTE]

Hmmm....

This might very well be a SPE. Either on my part, or by someone responsible for Primenet.

I see what you are reporting from the database records, but since GPU72 no longer assigns any DC nor LL candidates for LL work, I'm going to tentatively suggest that this is Primenet issuing assignments which it shouldn't. The fact that each AID is different (and is in UPPER case only, rather than GPU72's lower case only) supports this argument.

George / Scott / James... Thoughts?

[CODE]mysql> select Exponent,User,Status,Assigned,Completed,AID from Assigned where Exponent=31689991 and WorkType=3;
+----------+----------------------------------+--------+---------------------+---------------------+----------------------------------+
| Exponent | User | Status | Assigned | Completed | AID |
+----------+----------------------------------+--------+---------------------+---------------------+----------------------------------+
| 31689991 | 2423ae6e8f696d5e7d1447de91ca35a6 | 1 | 2014-03-17 18:16:47 | 2014-03-19 07:32:29 | B9CEB39665A4E5934C4F567C1BC918E0 |
| 31689991 | 2423ae6e8f696d5e7d1447de91ca35a6 | 1 | 2014-03-19 07:38:00 | 2014-03-19 07:53:43 | 738C791F34B38722E4850B36BE6DB2C8 |
| 31689991 | 2423ae6e8f696d5e7d1447de91ca35a6 | 1 | 2014-03-19 08:38:38 | 2014-03-19 10:37:40 | 0BDD3D808939B5C44358BB85DDD89F32 |
| 31689991 | 2423ae6e8f696d5e7d1447de91ca35a6 | 1 | 2014-03-19 10:39:30 | 2014-03-19 11:30:56 | 46DDA1184AF584AF2869E7861B21296B |
| 31689991 | 2423ae6e8f696d5e7d1447de91ca35a6 | 1 | 2014-03-19 11:43:14 | 2014-03-19 11:57:02 | DF7A8995AFF8086B031B57AEAE7B8291 |
| 31689991 | 2423ae6e8f696d5e7d1447de91ca35a6 | 1 | 2014-03-19 12:43:46 | 2014-03-19 12:59:43 | 25EB8E8591EC5804109087D1A57C627E |
| 31689991 | 2423ae6e8f696d5e7d1447de91ca35a6 | 1 | 2014-03-19 13:44:19 | 2014-03-19 13:51:28 | 8EAB2068DD7466D2E83FD8B771E3432A |
| 31689991 | 2423ae6e8f696d5e7d1447de91ca35a6 | 1 | 2014-03-19 14:44:58 | 2014-03-19 14:52:23 | 282FA0F4259219E2B983C87AA1EA8FC2 |
| 31689991 | 2423ae6e8f696d5e7d1447de91ca35a6 | 1 | 2014-03-19 15:33:39 | 2014-03-19 15:59:24 | 5B813040FC8330DF87DED877B38CDDA1 |
| 31689991 | d8a75f85f90457298bd3c366a8de2410 | 0 | 2014-03-19 16:12:19 | 2014-03-21 18:55:59 | 535968738BCE8DFB6CC3DC21B8D171EB |
+----------+----------------------------------+--------+---------------------+---------------------+----------------------------------+
10 rows in set (0.00 sec)[/CODE]

P.S. I'm /seriously/ busy at the moment. No code changes will be implemented unless mission critical.

[QUOTE=LaurV;369410]Hey Chris, can you check what's wrong with 31689991? It is being reported every hour or so, getting GPU72 credit, in spite of the fact that PrimeNet does not accept it. I mean, I like to see 5000 GHzDays of DC for me done within today, but kracker might get angry about :razz:

Now, honestly, I should keep half of that credit, because I signaled the bug... Huh? Do we share it? :razz:

OTOH, [URL="http://www.mersenne.org/report_top_500_custom/?team_flag=0&type=1004&rank_lo=39&rank_hi=40&start_date=2000-01-01&end_date=&B1=Get+Report"]hey buddy, do you feel the heat[/URL]? :razz: (no, this is serious, it does not include the bogus credit from GPU72! I am right behind of you, coming fast!)[/QUOTE]

Nope, you mean chalsall passing me, not you. Next!

:razz:

[QUOTE=kracker;369433]Nope, you mean chalsall passing me, not you. Next![/QUOTE]

If you two don't stop fighting I'm going to shut this server down.

I'm serious. I have better things to do with my time.