[QUOTE=Viliam Furik;556130]I checked the link. It seems that they only ship to some European countries.[/QUOTE]
[B]Yes to the 16 most important European countries, but only to entrepreneurs. Private individuals can only order within Germany.[/B]

[QUOTE=moebius;556137][SIZE="1"][/SIZE]
[B][SIZE="1"]Yes to the 16 most important European countries, but only to entrepreneurs. Private individuals can only order within Germany.[/SIZE][/B][/QUOTE]There are people on this forum with poor vision that have to use screen magnifiers or use other tools to be able to read the forum. Others read the forum on their phone. Please don't post small text as your default. Do this in consideration for others.

[QUOTE=Uncwilly;556141]There are people on this forum with [U][B]poor vision[/B][/U] that have to use screen magnifiers or use other tools to be able to read the forum. Others read the forum on their phone. Please don't post small text as your default. Do this in consideration for others.[/QUOTE]

My other tool is a 4-inch diameter magnifying glass. Thankfully, Firefox has a zoom feature which I keep set to 120%.

I virtually had my head handed to me for mentioning this several months back by a few individuals who I will not name. I will simply say that I have a very long memory, and leave it go at that. [U]Karma exists[/U]!

Ok, I guess it was the old version v6.11-278-ga39cc1a I was still using, because it is slightly faster than the newest one (311 µs vs 322 µs at 3M FFT on V100). It
seems this old version have a different FFT crossover point.

But that version did do 350+ successful TC in 50M-53M, and it still gives correct results if I force 3M FFT. But I guess I better switch to the new version.

[CODE]2020-09-05 15:51:04 config: -use ORIG_SLOWTRIG,CARRY32,NO_T2_SHUFFLE,OUT_WG=64,OUT_SIZEX=8,OUT_SPACING=4,IN_WG=128,IN_SIZEX=16,IN_SPACING=4
2020-09-05 15:51:04 config: -use STATS
2020-09-05 15:51:04 device 0, unique id ''
2020-09-05 15:51:04 Tesla V100-SXM2-16GB-0 54101381 FFT: 2.75M 256:11:512 (18.76 bpw)
2020-09-05 15:51:04 Tesla V100-SXM2-16GB-0 Expected maximum carry32: 511C0000
2020-09-05 15:51:04 Tesla V100-SXM2-16GB-0 NO_T2_SHUFFLE not used
2020-09-05 15:51:04 Tesla V100-SXM2-16GB-0 OpenCL args "-DEXP=54101381u -DWIDTH=256u -DSMALL_HEIGHT=512u -DMIDDLE=11u -DWEIGHT_STEP=0x1.2df227890f2f2p+0 -DIWEIGHT_STEP=0x1.b2174acb8edb3p-1 -DWEIGHT_BIGSTEP=0x1.ae89f995ad3adp+0 -DIWEIGHT_BIGSTEP=0x1.306fe0a31b715p-1 -DPM1=0 -DMM_CHAIN=2u -DMM2_CHAIN=3u -DCARRY32=1 -DIN_SIZEX=16 -DIN_SPACING=4 -DIN_WG=128 -DNO_T2_SHUFFLE=1 -DORIG_SLOWTRIG=1 -DOUT_SIZEX=8 -DOUT_SPACING=4 -DOUT_WG=64 -DSTATS=1 -cl-fast-relaxed-math -cl-std=CL2.0 "
2020-09-05 15:51:08 Tesla V100-SXM2-16GB-0

2020-09-05 15:51:08 Tesla V100-SXM2-16GB-0 OpenCL compilation in 3.85 s
2020-09-05 15:51:08 Tesla V100-SXM2-16GB-0 54101381 LL 0 loaded: 0000000000000004
2020-09-05 15:51:38 Tesla V100-SXM2-16GB-0 Roundoff: N=100000, mean 0.290692, SD 0.018230, CV 0.062711, max 0.437387, z 11.5 (pErr 99.999508%)
2020-09-05 15:51:38 Tesla V100-SXM2-16GB-0 54101381 LL 100000 0.18%; 296 us/it; ETA 0d 04:26; 98857a05e8c1d7ca
2020-09-05 15:52:07 Tesla V100-SXM2-16GB-0 Roundoff: N=100000, mean 0.290730, SD 0.017680, CV 0.060812, max 0.433674, z 11.8 (pErr 99.957106%)
2020-09-05 15:52:07 Tesla V100-SXM2-16GB-0 54101381 LL 200000 0.37%; 296 us/it; ETA 0d 04:26; 92591a2844762ceb
2020-09-05 15:52:37 Tesla V100-SXM2-16GB-0 Roundoff: N=100000, mean 0.290681, SD 0.017714, CV 0.060941, max 0.448847, z 11.8 (pErr 99.965018%)
2020-09-05 15:52:37 Tesla V100-SXM2-16GB-0 54101381 LL 300000 0.55%; 296 us/it; ETA 0d 04:26; 02f62a87c5bde161
2020-09-05 15:53:06 Tesla V100-SXM2-16GB-0 Roundoff: N=100000, mean 0.290703, SD 0.017701, CV 0.060890, max 0.442235, z 11.8 (pErr 99.962138%)
2020-09-05 15:53:06 Tesla V100-SXM2-16GB-0 54101381 LL 400000 0.74%; 296 us/it; ETA 0d 04:25; de0885175f96345b[/CODE]

upload.py stuck
 

I'm seeing ./tools/upload.py consistently getting stuck around 97%-98% on multiple machines. Is this a known issue?

Mine has often been stuck at 96%. When I try later to upload it again, it says it was already uploaded, and the certificate has already been approved.

[QUOTE=mathwiz;556286]I'm seeing ./tools/upload.py consistently getting stuck around 97%-98% on multiple machines. Is this a known issue?[/QUOTE]

I may have found the problem on the server side. We were getting timeouts at 300 seconds due to a locking issue.

[QUOTE=moebius;556093]available again by chance[URL="https://www.mindfactory.de/product_info.php/16GB-XFX-Radeon-VII-Aktiv-PCIe-3-0-x16--Retail-_1296273.html"]https://www.mindfactory.de/product_info.php/16GB-XFX-Radeon-VII-Aktiv-PCIe-3-0-x16--Retail-_1296273.html[/URL][/QUOTE]
[B]now no longer available, you have to be quick nowaday[/B]s

Error on load
 

[CODE]2020-09-09 17:57:48 config: -device 1
2020-09-09 17:57:48 config: -proof 8
2020-09-09 17:57:48 config: -nospin
2020-09-09 17:57:48 config: -jacobi 500000
2020-09-09 17:57:48 device 1, unique id ''
2020-09-09 17:57:48 gfx906-1 107826457 FFT: 6M 1K:12:256 (17.14 bpw)
2020-09-09 17:57:48 gfx906-1 Expected maximum carry32: 28B00000
2020-09-09 17:57:49 gfx906-1 OpenCL args "-DEXP=107826457u -DWIDTH=1024u -DSMALL_HEIGHT=256u -DMIDDLE=12u -DPM1=0 -DAMDGPU=1 -DWEIGHT_STEP_MINUS_1=0xd.11da6d175f558p-4 -DIWEIGHT_STEP_MINUS_1=-0xe.631e6aa29fc1p-5 -cl-unsafe-math-optimizations -cl-std=CL2.0 -cl-finite-math-only "
2020-09-09 17:57:49 gfx906-1 ASM compilation failed, retrying compilation using NO_ASM
2020-09-09 17:57:53 gfx906-1 OpenCL compilation in 4.76 s
2020-09-09 17:57:54 gfx906-1 107826457 EE 101144000 loaded: blockSize 400, e2ec8057148fe5cb (expected a63990e20177b9c6)
2020-09-09 17:57:54 gfx906-1 Exiting because "error on load"
2020-09-09 17:57:54 gfx906-1 Bye[/CODE]
Is there something I can do about this? Other than restart the test?

[QUOTE=Viliam Furik;556559]Is there something I can do about this? Other than restart the test?[/QUOTE]
If it is a PRP test, there should be a 107826457-old.owl file in the directory of the exponent, For LL I don't know.

[QUOTE=Viliam Furik;556559][CODE]
2020-09-09 17:57:54 gfx906-1 Exiting because "error on load"
2020-09-09 17:57:54 gfx906-1 Bye[/CODE]Is there something I can do about this? Other than restart the test?[/QUOTE]
No. This is a long standing bug in gpuOwl. Mihai was kinda busy with switching to the new methods (certs) or he doesn't care :razz:
This is bothering, but harmless. I mean, not totally harmless, in the sense that if you don't spot it in time, your card(s) can stay idle for ages. For me it happens with the card that drives the display, mostly, regardless of which card I use for that, or in which slot I put it, while the other card(s) won't pop such errors, or would pop them more seldom. The solution I use to avoid continuously watching if the owl crashed or not, is along starting the owl from a batch, which also has the advantage that I don't need to remember the parameters and options all the time, something along the lines:
[CODE]:again
gpuowl -device 0 -nospin -log blahblahblah-other-parameters
goto again
pause
[/CODE]
This way, as long as there is work to do in the file, any "reload" will be handles by the endless loop in the batch.