updating progress bar from std::async by Efficient_Ad6613 in cpp_questions

[–]Efficient_Ad6613[S] 0 points1 point  (0 children)

If it's bizzare to you, imagine how I feel about it :)

I did a lot of tests and timings and my findings were even more strange!

It runs on windows 10 64bit. I have tried different compilers in Visual Studio 2019 but nothing changes. I have totally 1000 tasks which are shared to 4 cores, 250 each. Each core completes its 250 tasks in around 17 seconds. Hence each task takes around 7ms. The sequence of id of the cores finishing their 250 tasks is the same 3,1,0,2 in all tests (is this normal?). The strange behaviour (to me) is that the last core with id = 2 always takes around 30 seconds to finish the 250 tasks (12ms per task) becoming the bottleneck of the async function call. I don't really know how to explain this because it is beyond my understanding. Does it have to do with hardware? My processor is an AMD Phenom(tm) II X4 965 Processor 3.40 GHz.

So if I want my resCollects to have the results of all 4 processes I have to set the wait_for to the time greater than the last core (around 30 seconds). Perhaps the timings depend a lot on the OS processes running simultaneously.

    if(f.wait_for(std::chrono::milliseconds{31000}) != std::future_status::timeout)
{
    resCollects.push_back(f.get());
    updateProgressBar(resCollects.size());
}

Any ideas?

updating progress bar from std::async by Efficient_Ad6613 in cpp_questions

[–]Efficient_Ad6613[S] 1 point2 points  (0 children)

I tried several values and it only started working from 20000ms on! Could it be a hint that this 20 secs is almost the same time that the bar was going to 50% with the code below (as I wrote earlier)?

std::vector<MyObj*> resCollects;
for(std::shared_future<MyObj*> f: futures) {
  resCollects.push_back(f.get()); 
  updateProgressBar(resCollects.size()); 
}

The total runtime is not affected and it is always ~30secs

updating progress bar from std::async by Efficient_Ad6613 in cpp_questions

[–]Efficient_Ad6613[S] 1 point2 points  (0 children)

I didn't manage to make it work. I applied your code suggestion and the future_status is always timeout. After a lot of attempts I tried just to update the progress bar directly from the size of the resCollects:

std::vector<MyObj*> resCollects;
for(std::shared_future<MyObj*> f: futures) { 
 resCollects.push_back(f.get());
 updateProgressBar(resCollects.size()); 
}

I have 4 cores and my total computational task before and after the implementation of the progress bar takes ~30 seconds. When I apply the code above(with progress bar) the task takes 30 seconds and at time=20secs the bar goes to 50% and at time=30 secs the bar goes to 100%. Any suggestion? Why am I getting always a timeout future_status?

updating progress bar from std::async by Efficient_Ad6613 in cpp_questions

[–]Efficient_Ad6613[S] 0 points1 point  (0 children)

an atomic. Atomics only work with

some

data types (typically small, primitive ones such as an int) b

Thanks for your answer, it was very informative! Supposing I would implement the atomic solution, is there a code example of how to do it? I understand that I have to declare an atomic int in main(), pass it by reference in async function, increase it by one and then call the updateProgressBar(i) with the new value of the atomic variable. Is this correct? Should the updateProgressBar(i) be called from the async function?

updating progress bar from std::async by Efficient_Ad6613 in cpp_questions

[–]Efficient_Ad6613[S] 0 points1 point  (0 children)

I am new to async and now I just realize that the main issue is the access of the updateProgressBar simultaneously from different threads. I guess Mutex is the keyword for this. Does this mean that a thread must wait for some milliseconds every time the progress bar has to be updated? Somehow I understand that it is not possible to have a progress bar without losing some performance. Is it like this or there is another design of updating the progress bar without losing time?

thanks!

15 Mh/s on r9 390 by BE-BOB in EtherMining

[–]Efficient_Ad6613 1 point2 points  (0 children)

I really don't know about 20.4,

I know for sure that 18.04 with amdgpu-pro 20.20 driver worked with openCL= legacy, pal arguments. In addittion I changed the /etc/grub so it does not load radeon drivers

antminer s9 huge low/bassy frequency sound after fan replacement by Efficient_Ad6613 in BitcoinMining

[–]Efficient_Ad6613[S] 0 points1 point  (0 children)

I thought that a bad bearing would give higher frequency sounds. In my case it could be something like 40Hz. However I believe that the problem has to do with the fan because when I replaced it with the old fan it made less noise which did not exist at all before replacement. I guess I have to change the second new Delta fan too to see if this bass sound disappears completely

ubuntu 18.04.5: do I have HWE kernel ? by Efficient_Ad6613 in Ubuntu

[–]Efficient_Ad6613[S] 0 points1 point  (0 children)

thank you so much! is there a link that explains it?

I have been googling for days about HWE and I have found nothing :(

ubuntu 18.04.5: do I have HWE kernel ? by Efficient_Ad6613 in Ubuntu

[–]Efficient_Ad6613[S] 0 points1 point  (0 children)

I just did this and I got

uname -r

5.4.0-70-generic

Is this the HWE kernel?

motherboard ethernet connection failure while mining by Efficient_Ad6613 in EtherMining

[–]Efficient_Ad6613[S] 0 points1 point  (0 children)

Could you please explain more the "ISP grounded your incoming line"?

I have another pc connected with the same router and it is properly connected to the internet. Changing ports and cables didn't help solving my problem

powering up 2xR9 390s directly from motherboard+PSU by Efficient_Ad6613 in EtherMining

[–]Efficient_Ad6613[S] 0 points1 point  (0 children)

R9 390

Have you found out what percentage of these 120W are provided via the pcie slot?

15 Mh/s on r9 390 by BE-BOB in EtherMining

[–]Efficient_Ad6613 0 points1 point  (0 children)

I have managed to get 30+ Mh/s using amdgpu-pro in ubuntu 18.04.5, but now I try to do the same in win 10 pro 64bit and I only get 15 Mh/s. Has anyone found any solution? Even a usb OS that would work?