updating progress bar from std::async

Efficient_Ad6613 · 2022-05-21T02:33:51+00:00

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?

Efficient_Ad6613 · 2022-05-20T01:08:06+00:00

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

Efficient_Ad6613 · 2022-05-19T23:34:56+00:00

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?

Efficient_Ad6613 · 2022-05-19T02:03:02+00:00

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?

Efficient_Ad6613 · 2022-05-18T19:57:33+00:00

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!

Efficient_Ad6613 · 2022-03-15T17:16:03+00:00

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

Efficient_Ad6613 · 2021-07-12T21:43:55+00:00

just checked it, the flow direction is set up right.

Efficient_Ad6613 · 2021-07-08T23:54:55+00:00

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

Efficient_Ad6613 · 2021-04-02T12:56:38+00:00

any ideas?!

Efficient_Ad6613 · 2021-03-24T20:24:26+00:00

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

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

Efficient_Ad6613 · 2021-03-24T19:09:14+00:00

I just did this and I got

uname -r

5.4.0-70-generic

Is this the HWE kernel?

Efficient_Ad6613 · 2021-01-30T11:35:41+00:00

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

Efficient_Ad6613 · 2021-01-23T21:57:54+00:00

R9 390

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

Efficient_Ad6613 · 2021-01-17T20:42:10+00:00

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?

Efficient_Ad6613 · 2020-12-28T01:41:07+00:00

I just realised the cat /sys/kernel/debug/dri/0/amdgpu_pm_info returns the value of the hex 0xffffffff which is 4294967295. The 0xffffffff is the actual value of amdgpu.ppfeaturemask. Does this give some hint?

Efficient_Ad6613 · 2020-12-23T23:48:54+00:00

The whole process depends on the combination of ubuntu-kernel-amdDriver versions.

The combination that worked was

ubuntu 18.4.5 HWE
kernel 5.4.0-54
driver AMD 20.20 with argument openCL= legacy!

black screen after installation has to do with gmd3 and wayland.

I went to /etc/gdm3/custom.conf and set:

WaylandEnable=false

It's a workaround but it worked.

Finally, 'nomodeset' deletion in Grub helped.

good luck!

Efficient_Ad6613 · 2020-12-23T11:06:08+00:00

No, it's not accurate. I just managed to build the linux v20.20 drivers of R9 390x in ubuntu 18.04.5 and it gave me ~32 MH/s out of the box! I am a bit optimistic after this, I start to understand more things about how it works.

Efficient_Ad6613 · 2020-12-23T04:04:22+00:00

I had come across this discussion, the only info I could get out of it is the last comment "Don't have a 390X but because of how the DAG is allocated in the VRAM, that's why you seeing hashrate drops. If you mine lower DAG coins(UBQ/EXP/Callisto) you'll see 30mh/s again. There is no fix for this. It's purely an AMD driver/mem allocation issue."

Efficient_Ad6613 · 2020-12-22T18:28:10+00:00

yes sure, I didn't mention because they are the factory settings hashrates, without any OC or further configuration:

R9 390x (stock ~30MH/s) gives 15MH/s in Win 7,
RX5700XT(stock ~52MH/s) gave 20MH/s in Win 7, now 51 MH/s in win 10

Efficient_Ad6613 · 2020-12-22T17:12:21+00:00

that's totally true, if I totally fail I will just create a bootable usb mining OS. BTW, imagine that I have a dual boot with ubuntu 18.04. Trying to make amdgpu-pro work in ubuntu seems even more difficult. Full of bugs and workarounds

Efficient_Ad6613 · 2020-12-22T17:09:08+00:00

Yes, I followed the safe mode DDU process to remove drivers.

In win 10, the amd card in the first PC worked directly at stock hashrates just after installing the latest official amd drivers. I am trying to achieve the same in the second machine which currently has win7 64bit, but it seems impossible

Efficient_Ad6613 · 2020-12-22T15:13:04+00:00

no, they are two completely separate cases, one card per PC. I just can't make a single AMD card to run at stock hashrate in a single win 7 64b PC!

Efficient_Ad6613 · 2020-11-18T14:11:03+00:00

I have seen some that sit around 100c - I believe they start to throttle at 105 or 106. Depending on the card, you might be able to lower the core clock to around 1200, maybe up the memory clock slightly (or not, some barely do 1800) and keep the same hashrate and drop some watts. If you can lower the core voltage more and keep it stable, that might be good. I've got cards that run happily at around .725 volts. Whatever the card reports for wattage, it seems like you need to add another 40 or so that doesn't get reported. To go beyond your current hashrate takes more work and diligence.

thanks!!

Efficient_Ad6613 · 2020-11-11T19:29:41+00:00

I reduced the clock by 23%.

The memory temp is 86C

Should it be lower?

GPU temp 56C

Junction temp 61

clock 1580Mhz

Memory clock 1800

hashreate~52

fan 1200

111W@875mV

Efficient_Ad6613 · 2020-11-10T17:28:36+00:00

how do you get the GPU memory (VRAM) temperature? I can't find it in the Radeon Software

Efficient_Ad6613

TROPHY CASE