PrimeGrid
Please visit donation page to help the project cover running costs for this month

Toggle Menu

Join PrimeGrid

Returning Participants

Community

Leader Boards

Results

Other

drummers-lowrise
1) Message boards : Generalized Fermat Prime Search : GFN-16 MEGA Prime Search starts March, 14, 2019 (Message 129857)
Posted 22 hours ago by dukebg
Is the server down? I'm getting connection timeouts since about 15:01 EEST (12:01 UTC) and some online tools show it down too.

I've been working on the server for the past six hours without any problems. No timeouts and my ssh sessions have been fine.

I was talking about the Private GFN Server.
2) Message boards : Number crunching : app_config XML generator (Message 129852)
Posted 23 hours ago by dukebg
What you're asking already exists in a form of a spreadsheet mady by TimT.

https://docs.google.com/spreadsheets/d/1I-CrG89rhFgS2x5_pGn8pyI6vVl7Y_Qn02vEm41ScLY
3) Message boards : Seventeen or Bust : The SoB Double Check has begun (Message 129851)
Posted 23 hours ago by dukebg
What does mean yellow row in 67607 item on SoB statistics page:

https://www.primegrid.com/stats_sob_llr.php

There are currently no tasks in progress for that k. All of the remaining DC work is for other k's. Why that is was discussed above (this was the PG's k and we only had to double-check SoB's work on it below PG's ranges). The 362 workunits you see in the "waiting" column are the normal non-DC work starting around n = 31 625 811.
4) Message boards : Generalized Fermat Prime Search : GFN-16 MEGA Prime Search starts March, 14, 2019 (Message 129850)
Posted 23 hours ago by dukebg
Is the server down? I'm getting connection timeouts since about 15:01 EEST (12:01 UTC) and some online tools show it down too.
5) Message boards : Number crunching : Miscounting CPUs needed (Message 129687)
Posted 5 days ago by dukebg
boinc's cpu scheduling doesn't deal with actual cpu % usage. Wrapper is supposed to use pretty much 0, it is just a wrapper, it doesn't do calculations itself. boinc doesn't "count" the actually launched processes in any way, it calculates for itself what tasks are active and how many resources boinc expects them to use.

I don't know why in your case boinc thinks that running another task would bring it above allowed 3 cpus. But still, an advice is to raise the allowed CPUs % slightly. 58%, maybe.
6) Message boards : Problems and Help : "Can't acquire lockfile" error (Message 129179)
Posted 21 days ago by dukebg
You don't have to worry, it's a rare BOINC bug (but no matter how rare, it does happen time after time to people based on how many people run how many tasks) where in some race conditions there would be a conflict between trying to start a task and a completed task being reported in the same slot (file system folder).

There's a better description of this bug somewhere on forums... Stream definitely posted about it somewhere. And to assure you, "finish file present too long" happens in other BOINC projects too.

Either way, I'm pretty confident you don't have to worry.
7) Message boards : Seventeen or Bust : The SoB Double Check has begun (Message 129124)
Posted 25 days ago by dukebg
Ah, thank you for clearing that up!

I just randomly saw it today and thought to myself "wasn't that the primegrid K? i remember it being discussed that it doesn't have DC work left". There is your post further up from January with the line "So from this point on, the double check has no more 67607 candidates."

So, corollary "has no more unsent 67607 [work]". 29 054 291 is just the last straggler of those in-progress all these months.
8) Message boards : Seventeen or Bust : The SoB Double Check has begun (Message 129120)
Posted 25 days ago by dukebg
That last k=67607 candidate is now gone. It had to have been in one of the sieves when we were putting together the doublecheck data. But, it's not in the latest PrimeGrid sieve and I was able to find a factor for it.

(just in case, replying to a ~3.5 month old message)
I see an in-progress unit for k=67607 in the stats page, n = 29 054 291. Did it reappear somehow? Or is it just there to have data to join/display in the table?
9) Message boards : Number crunching : Badges - Full Sets! (Message 129095)
Posted 26 days ago by dukebg
Avert thine eyes or be blinded, I have finally reached all active projects gold!

(with the exception of SoB and GFN-21 challenges pushing me way to much further; from now on I can with easy conscience only focus on projects I personally like most – SoB/ESP/PSP most likely)
10) Message boards : Generalized Fermat Prime Search : GFN-16 MEGA Prime Search starts March, 14, 2019 (Message 128995)
Posted 31 days ago by dukebg
The POST requests are generally often split by various libraries into 2+ separate TCP packets – the header and the body (the body is often multiple packets itself when the request is big). I've found that out myself at work about few months ago when the task I was doing required maximizing throughput of a high amount of parallel stream messaging (done with POSTs). The messages were very short, just like 20 bytes of data posted, the headers were much bigger themselves.

This is also highly connected to implementations of the Nagle's algorithm (see wikipedia if needed). If I recall correctly, in my case throughput was much better when disabling nagle algorithm – while it was on (by default in dotnet framework implementation of httpclient) each POST was two packets as described, with it off it was a single packet.

This of course is very unlikely to help the problem since nagling is about throughput, not the ability to send packets at all. But it's an insight about how there's probably this separation of packets into headers and bodies.

P.S. Yeah, and the reason why throughput in my case was higher with single packets was because the client would wait for the web server to answer to the first packet while the webserver waits some tiny amount of time expecting the continuation before sending the ACK to the first (this is also related to Expect100Continue stuff) – that tiny amount is negligible when you're sending a single request, but not when trying to optimize throughput.


Next 10 posts
[Return to PrimeGrid main page]
DNS Powered by DNSEXIT.COM
Copyright © 2005 - 2019 Rytis Slatkevičius (contact) and PrimeGrid community. Server load 1.05, 1.33, 1.40
Generated 27 May 2019 | 13:33:47 UTC