| log in |
|
1)
Message boards :
News :
A bad day happened
(Message 9546)
Posted 16 Jan 2024 by KEP Thanks for the status :) It was a really bad day, it simply can't be worded differently, since you here many weeks after, can't walk and the arm is still not fully recovered. Missing something - I hope is training to get back in shape, not something litterally missing from your body, limbs or bones? :) You truly are strong. Hope that someone comes and take care for you. It is good that you give a status from time to time, so that everyone knows if you have to cut back or gets less resposive, compared to your usual speedy replys :) Let's hope this year will bring you back to your best and as close as possible to the minutes before your day turned bad. Good way to celebrate that is to have a lot of proven bases :) Take care and stay strong :) |
|
2)
Message boards :
News :
A bad day happened
(Message 9544)
Posted 16 Jan 2024 by KEP Sorry to hear that Reb, is really nothing going a bit better? I understand the knee and maybe the joints in the arm, they are tricky if hurt bad - but the arm, is that not grown back to its ordinary pieces? Good luck at OP, I truly hopes the best for you. You are a great contribution to CRUS and a great person, thank you for that :) |
|
3)
Message boards :
News :
A bad day happened
(Message 9174)
Posted 19 Oct 2023 by KEP Back to home today with a lot of restrictions now but the first backup was made. Will do more later for smaller backups, this one was large. Hope also for more TF work today, need some time. Glad to see that you are actually improving. Glad to read that too. Remember, however dedicated you may be, you are truly dedicated, do not do this work on any kind of expence of the restrictions. We all need you to be around for a lot of time. When that is said, if one has a home, feel comfy there, then home sweet home and hopefully a more speedy recovery. Now at least the germs in hospital is not a risk :) Take care and safe. |
|
4)
Message boards :
News :
A bad day happened
(Message 9160)
Posted 15 Oct 2023 by KEP Now you can see the helpless if you cant do anything. Yes, that shows in such kind of situations. Personally the loneliness I have ended up in, because woman has far too much influence on their way of living, too much disrespect towards life and men in general, will eventually bring me in the exact same situation of dependens of a society that has not shown due timing to make sure that warm hands is there to nurse one, when one gets to old to manage and provide for oneself. That day I really fear to see. Sounds like you almost broke all that could be broken in arms and legs? |
|
5)
Message boards :
News :
A bad day happened
(Message 9156)
Posted 15 Oct 2023 by KEP I'm schocked, to read this Reb. Glad that you are alive, despite it sounds like something really went very bad. It is most important that you get well, that is always more important than managing this kind of work. You do a great job, but health always tops anykind of job. Stay strong and live long and well. |
|
6)
Message boards :
News :
Downtime on Friday
(Message 8497)
Posted 3 Dec 2022 by KEP according to: http://acronymsandslang.com/meaning-of/technology-IT/TIM.html Bluestang most likely refers to: Thermal Interface Material (I think what we call thermal paste or products similar to thermal paste) |
|
7)
Message boards :
Number crunching :
TF
(Message 8351)
Posted 6 Aug 2022 by KEP Can primes be found running TF only or do I need to opt in CPU tanks? TF can not find primes, at least not noteworthy primes. So if you want to find primes, you have to opt in CPU tanks :) |
|
8)
Message boards :
News :
New work for TF added
(Message 8208)
Posted 5 May 2022 by KEP Any idea how low calculation times will get for the current work 73 – 74 M? Current runtime is sitting around 3 minutes for a RTX 2070. Giving 3000 credits Thanks in advance If it takes around 180 seconds on a RTX 2070 for n=360M - wich appears to be the beginning of this batch - it will take approximately 174 seconds at n=372M. In case you need to know in the future, the formula is as follows: (nMin / nMax) x seconds to complete nMin test Take care. |
|
9)
Message boards :
Number crunching :
Trial Factoring
(Message 7700)
Posted 28 Jun 2021 by KEP So does that mean that we move onto the 73-74 bit range next? If so, does that have a large effect on TF as a project? The impact of trial factoring from 73 bit to 74 bit, will mean following: Tasks to factor: 16,865,230 Likeliness of factor: 1.435 percent (maybe little higher) First time tests saved by factoring: 242,016 tests. The impact is as you can see very high. A 12 core 2.3 GHz Xeon (not modern at all) uses about 48 CPU days per test at n=100M. It then uses 192 days at n=200M. It then uses 768 days at n=400M. It then uses 3,072 days at n=800M. From n=100M to n=200M tests saved 16,232 (1,947,840 CPU days saved) From n=200M to n=400M tests saved 51,851 (24,888,480 CPU days saved) From n=400M to n=800M tests saved 116,577 (223,827,840 CPU days saved) So the impact is a whooping 250,664,160 saved CPU days of testing, on a 12 core 2.3 GHz Xeon and by all means very huge and meaningfull. Thanks for asking the question :) Take care. |
|
10)
Message boards :
Number crunching :
Lower rewards?
(Message 7223)
Posted 10 Jan 2021 by KEP Hi - I crunch TF, normally the credit is 1700 per task. Hi Gary, welcome to the project :) As Reb mentions, as n increase the runtime decreases. If you at n=100M runs a task in 1 minute, then at n=200M you will complete a task for the same bit level in 30 seconds. At n=1000M wich is around maximum n, you will only need about 6 seconds for completing a task for the same bitlevel. One thing to note, is that not only should credit decrease, as n grows, but there is also a "lot" of free credit, because if you find a factor, the WU completes instantly and your GPU continues to the next task. |
|
11)
Message boards :
Number crunching :
SRBase has been chosen for Formula Boinc Sprint
(Message 6846)
Posted 23 Oct 2020 by KEP With every increased 100M range the runtime is 1/2 Small correction :) If at n=125M testing time is 60 seconds then at n=250M testing time is 30 seconds and at n=500M testing time is 15 seconds and at n=1000M testing time is 7.5 seconds IT is CORRECT that testing time goes down as n increases due to fewer possible factors per 1 bit. Cool that SRBase was chosen for a challenge. It is already noticeble the increased count of users. Let's hope that some users stay behind once the sprint is over and help push the conjectures aswell the trial factoring effort. Trial factoring really really really needs help, due to some high end users focusing on primetesting and litterally testing hundreds each day (them alone). |
|
12)
Message boards :
News :
New work for TF added
(Message 6568)
Posted 7 Jun 2020 by KEP Where do you find your discovered factors? You unfortunantly can't see that information. It would be unreasonably to ask for Reb, to show factors found and by who - not just because the information (to my knowledge) is not saved in a way that makes it possible to say wich user found wich factor. Also, currently SRBase is finding about 6-8 thousand factors a day, so can you imagine the data needed to display the information about factor finder. You can however get a rough estimate how many factors you have found, by multiplying your completed tasks with 0.01436 - that will give you an approximate amount of factors found by you :) |
|
13)
Message boards :
Number crunching :
Trial Factoring
(Message 6556)
Posted 4 Jun 2020 by KEP Don't forget that hardware improves and better GPUs will come here. ;) It sure does :) No doubt, once GTR 2080 TI becomes standard for low cost GPUs then we start talking :) Let's hope the 3xxx indeed are powerhorses by themself :) |
|
14)
Message boards :
Number crunching :
Trial Factoring
(Message 6552)
Posted 1 Jun 2020 by KEP Seems these WUs (again, at least on Nvidia GPUs) do all of their computations on the GPU. They sure also should. Mfaktc, didn't use to use 0% CPU, but eventually someone upgraded the mfaktc app and the app went from using both CPU and GPU to only using GPU. It appears though, that some CPU is still used, when looking at the completion data on workunits completed. Those running more than 1 WU per GPU may wanna test each time we jump a bit level. Runtime, aswell as speed of computation may change, when a bit is jumped. My old GPU was very efficient up to 75 bit, after that it slowed down dramatically, aswell it slowed down if running more than 1 test at a time on the GPU. |
|
15)
Message boards :
Number crunching :
Trial Factoring
(Message 6550)
Posted 1 Jun 2020 by KEP Thank you very much for the idea ! Cool :) I reckon this applys to other GPU models too. Maybe even my OLD noisy AMD :) Hope this goes to the FAQ :) |
|
16)
Message boards :
Number crunching :
Trial Factoring
(Message 6548)
Posted 1 Jun 2020 by KEP While I don't personally do it (I keep all of my computers visible and what you see there is 100% accurate), some crunchers do this in order to have more work in queue in case of a site outage. Another reason some do it because they have limited internet connection times, so they connect when they are able and get as much work as they need to continue crunching until the next time they can connect. Those who participate in the various team competitions (Formula BOINC, BOINC Pentathlon, etc.) do it for bunkering purposes. I'm sure there are other reasons, as well. Okay, thank you for your answer :) ... It was a bit of a bummer, that we did not have the ressources that I thought, but I do see that there is a lot of good reasons for that behaviour. How did you manage to run 2 WU per GPU? Have you tested that you are not inefficient compared to running 1 WU per GPU? |
|
17)
Message boards :
Number crunching :
Trial Factoring
(Message 6542)
Posted 31 May 2020 by KEP You can trick the server by saying you have x amount of GPU’s or CPU’s. You are too naive. If we had 2700 GPU how many wus would we all be doing per day? Make the calculations. And exactly what is the purpose of doing so? Why not just accept the amount that the server send out? Doing the last request would actually make it possible to calculate the real ressources we have - now in stead of a very huge production we only have a very huge cue of work waiting to be processed. Maybe a setting on the server could/should be made to render that possibility IMPOSSIBLE - is that possible Reb? A note on my third question is that the server has proven reliable enough to sustain the users with enough work even if they have only 20 workunits cued per host. |
|
18)
Message boards :
Number crunching :
Trial Factoring
(Message 6529)
Posted 31 May 2020 by KEP Thanks everyone for your feedback :) I can see that, we are now having more than 2700 GPUs at work and a good deal of them are high end users. If we can maintain this firepower, going all the way to 74 bit by the end of the year is indeed feasible and going all the way to 76 bit next year is feasible. With that kind of work being completed at the moment, it is best to go like Rebirther prefers and go breadth first - that will give those with slow GPUs a chance to adapt to the near future, where everything with a factor below 75 bit is cleared. Personally I'm amazed at the firepower that a 2080 has, especially the 2080 TI. By the end of this bit level, some users are going to have a completion time of approximately 10 seconds per test :) Thank you everyone for contributing, it sure does help GIMPs a lot and by going breadth first, we actually contribute to every users, and not just those users searching at the wavefront :) |
|
19)
Message boards :
Number crunching :
Trial Factoring
(Message 6518)
Posted 29 May 2020 by KEP n my opinion we should test for the lower n range from 72 bits to 73 bits to get a feeling of the timings needed, we have almost 470k units in there. This will help in short term GIMPS project but I do understand we should get fast wus available to the community, like the ones we are doing now, which will only be useful to GIMPS in 20-30 years time. It’s a threshold. If you at n=200M use 42.5 minutes in average to go from 72-73 bit, it means, that at n=120M (likely starting point) you would spend ~70.8 minutes going from 72-73 bit. That could be too much for someone. A GTR 2080 will spend on doing the same n/bit range (if 50x faster), ~1m25 seconds. Looks like Rebirthers approach is correct and that running breadth first is the best suited for all users. Last time we jumped to 77-78 bits, a lot of the slow GPUs vanished. Going breadth first, may actually be the proper way of keeping our momentum. Thanks for your feedbacks, now let's see if we can actually clear all exponents to 72 bit, before the end of the year (maybe 73 bit if enough highend users comes to our aide) :) |
|
20)
Message boards :
Number crunching :
Trial Factoring
(Message 6515)
Posted 28 May 2020 by KEP Maybe for higher ranges instead of going to 71 bits from 70 just go straight to 72 or 73 instead. You will have to make some trials for timings. How would people here in general feel about doing lower n, breadth first to max bit ie n>96.83M to n<=120M to 78 bit? I know it eventually is a huge increase in testing time, but does it really make a difference for you as a user when it comes to supporting this project or not? I'm asking, because if we really want to benefit and boost this project, running that suggested n range, to 78 bit, is the way to move forward. I know it will steal some of the low hanging fruits. What does each user prefer in terms of short or long running tasks? I reckon Rebirther is the one who takes the final decision, but it is seriously as little as changing one setting in the .ini file and then everything from work creation to validation will work the same, even if we decide to run multiple bits per workunit. The offer Rebirther, that I gave in a private message, still stands, when it comes to creating the next bit range, if you wont go all remaining bits up to 78, but breadth first and increase by 1 bit per workunit - all we have to do, is to agree with George that we can reserve and keep everything in that range untill we reach 78 bit. Has the new way of showing progress, made it possible to have a mix of bits? I understand the need to go breadth first, but we also have to use our ressources to best help Primenet and as mentioned in private message, going breadth first, but completing the range n>96.83M to n<=120M to 78 bit, one bit at a time, wont be difficult and I will no doubt help you do it flawlessly :) Everyone with an oppinion or enlightment, please let me hear what you think, preferably from both slow and fast GPU users :) |