SxC
|
|
March 10, 2014, 08:59:10 PM |
|
Out of interest isn't ultracoin identical to QQ coin and velocitycoin? What makes ultracoin more likely to succeed?
There is fastcoin as well so I am confused as to what makes ultracoin stand out compared to the other coins. It seems velocitycoin is very fast as well using scrypt-jane with n-factor implementation
Ultracoin has Bumface a BTC-e mod u know where it's going ......... Sorry for my ignorance but what makes bumface a better developer than other people? Also, how does having a BTC-e mod influence the coin itself? UTC doesn't seem to be listed on btc-e either ? It has the potential to be listed tho and the devs at BTC-e are considering it If it goes on btc-e it will become massive,already can go big without BTC-e but that will push it so high it could leave LTC in its wake I thought cryptsy would be bigger than BTC-e since everyone seems to rave about it? I personally use BTer to trade but I wonder when UTC will get listed there Crapsty was a flop for UTC tbh cause we got crypto-trade back sametime
|
|
|
|
KingCole
|
|
March 10, 2014, 09:03:12 PM |
|
I would like to know why does n-factor not affect cpu's. yeah yeah memory intensive, multiple threads, ram. i got all that, but if hashrate halves for cpu's as well, which I don't know if it halves, then wouldn't cpu mining still get harder over time as n-factors increase?
Can someone who has been cpu-mining AND experienced any n-factor change answer?
Been wondering this since day 1. Defo needs an answer. bump I don't know the answer per se, but my assumption is that as the N-Factor increases you need more memory for a given hash-rate, you reach a point where the GPU is memory bound not processing bound. The GPU consumes pretty high levels of power so equilibrium is reached sooner. That is the cost of electricity is the same as the value of coins mined. At that point a CPU which consumes less power and can use memory more efficiently (this doesn't mean greater hashing), remains profitable KC
|
|
|
|
Halofire
|
|
March 10, 2014, 09:08:06 PM |
|
I would like to know why does n-factor not affect cpu's. yeah yeah memory intensive, multiple threads, ram. i got all that, but if hashrate halves for cpu's as well, which I don't know if it halves, then wouldn't cpu mining still get harder over time as n-factors increase?
Can someone who has been cpu-mining AND experienced any n-factor change answer?
Been wondering this since day 1. Defo needs an answer. bump I don't know the answer per se, but my assumption is that as the N-Factor increases you need more memory for a given hash-rate, you reach a point where the GPU is memory bound not processing bound. The GPU consumes pretty high levels of power so equilibrium is reached sooner. That is the cost of electricity is the same as the value of coins mined. At that point a CPU which consumes less power and can use memory more efficiently (this doesn't mean greater hashing), remains profitable KC the thing is that jane coins are marketed as gpus will not be able to mine. Is this because of the power efficiency you stated, or because the gpu isn't capable of hashing? We need to know how n-factor affected cpu miners, if hashes halved. Is anyone even cpu mining?
|
OC Development - oZwWbQwz6LAkDLa2pHsEH8WSD2Y3LsTgFt SMC Development - SgpYdoVz946nLBF2hF3PYCVQYnuYDeQTGu Friendly reminder: Back up your wallet.dat files!!
|
|
|
pieterjanvh
|
|
March 10, 2014, 09:24:49 PM |
|
Bumface, is ziggy doing anything at all about the CPU mining problem?
what problem? There's no CPU miner for UTC... And the question have been asked many, many times. U can't advertise a coin for being GPU and CPU friendly after a while and not have a CPU miner
|
|
|
|
Puycheval
Member
Offline
Activity: 95
Merit: 10
|
|
March 10, 2014, 09:47:07 PM |
|
We need to know how n-factor affected cpu miners, if hashes halved. Is anyone even cpu mining?
I don't know for ultracoin but this is what was tested for Yacoin when it was cpu only. You can see hashrate is roughly halved with each N increase as long as it doesn't change of memory type. For example, the change 13->14 shows a big loss because dataset doesn't fit in L2 cache anymore. Nfactor N Memory UNIX Time Date/Time in GMT Hashrate for 2x Xeon E5450 13 16384 2MB 1380574112 Mon - 30 Sep 2013 - 20:48:32 GMT 2,276 14 32768 4MB 1384768416 Mon - 18 Nov 2013 - 09:53:36 GMT 606
|
|
|
|
Rabbit80
|
|
March 10, 2014, 09:50:10 PM |
|
Bumface, is ziggy doing anything at all about the CPU mining problem?
what problem? There's no CPU miner for UTC... And the question have been asked many, many times. U can't advertise a coin for being GPU and CPU friendly after a while and not have a CPU miner The velocitycoin miner from http://velocitycoin.com/forum/index.php?topic=102.0 works.. I have just tried it with my i7
|
|
|
|
Protagonus
|
|
March 10, 2014, 09:57:55 PM |
|
I see there are some questions that keep popping up again and again. Might as well pop in to see if I can help in some way. At what point does it become pointless to use our GPUs?
If the current n-factor gives me 120/150 KH/s for my 280Xs/290, the next will be be 60/75 and then 30/38. I will still be able to mine the same number of coins with these hash rates? Just trying to figure out how long my 4 280Xs and one 290 have got with this coin/scrypt.
N = 14 07 / 12 / 14 @ 04:20:16am UTC At this N and beyond it will be more cost effective to mine with CPU. I would like to know why does n-factor not affect cpu's. yeah yeah memory intensive, multiple threads, ram. i got all that, but if hashrate halves for cpu's as well, which I don't know if it halves, then wouldn't cpu mining still get harder over time as n-factors increase?
Can someone who has been cpu-mining AND experienced any n-factor change answer?
Been wondering this since day 1. Defo needs an answer. bump Both CPU and GPU are affected similar, in terms of dropping hash rate each N increase. However, the gap in actual hashrate gets smaller with higher N. As well, CPU's actually "fall-off" slower in hash slightly than gpu / perform better later. For example 600khs GPU with N increase may be similar to; 600>290>130>60>25>10>5. Comparing this to a CPU over same N increases; 125> 65> 35> 20> 10>5>2.5 Part of this reason was described best and quoted here; "CPU's still have a number of advantages over GPU's and ASIC's. They come with double precision floating point hardware, employ very advanced branch prediction mechanisms, incorporate at least 2MB of on chip L2/L3 cache, and are able to speculate through 4-6 branches even in ten year old machines. GPU's can manage 2-5x better double precision floating point performance than a typical CPU, but in some benchmarks, they cannot even manage even speed. The problem is worse for ASIC's, which must be custom designed around a specialized pipeline. "
Again quoting another location; here is a representation of hash rate on a CPU vs increasing N values. Running 1500 scrypt hashes with N=2048 - 0.00109417 avg. sec per hash Running 1500 scrypt hashes with N=4096 - 0.00216536 avg. sec per hash Running 1500 scrypt hashes with N=8192 - 0.00450547 avg. sec per hash Running 1500 scrypt hashes with N=16384 - 0.00928228 avg. sec per hash Running 1500 scrypt hashes with N=32768 - 0.01895874 avg. sec per hash Running 1500 scrypt hashes with N=65536 - 0.04028997 avg. sec per hash Running 1500 scrypt hashes with N=131072 - 0.08082690 avg. sec per hash
test written in python on an i5-4250U CPU @ 1.30GHz,
In the end it's not that CPU's hash way faster than GPU's at high N's; specifically, it's that CPU's cost less Watts per Kh/s to mine at higher N's. Some examples of hash rates and setups with CPU's and GPUs @ N = 14; can be seen here - http://yacoinwiki.tk/index.php/Mining_Hardware_ComparisonYou can see, as an example here @ N14 2x E5645 Procesors 2x 80W -- 1.53Kh/s 7950 GPU (250w) 1.3-1.5 Kh/s As shown above. the Processors will give approximately the same Kh/s for 160w versus 250w of a 7950. Bumface, is ziggy doing anything at all about the CPU mining problem?
what problem? There's no CPU miner for UTC... And the question have been asked many, many times. U can't advertise a coin for being GPU and CPU friendly after a while and not have a CPU miner There are a few CPU miners. One is listed on the Ultracoin forum too. However, there is one specific miner that is best and most up to date. -Manual N parameters for multiple coins -X86 and 64bit formats -Stratum pool capable -Scrypt optimizations for Scrypt-Jane https://github.com/thirtybird/cpuminer/releases/This is the absolute best CPU miner out there currently. I believe it has all the needs being asked for. Even though I'm not actively posting here; I still hate to not help if I can. Thanks Prot UftrEhcPx5hTY4YJvSziPi13dfZT9nXSqw
|
|
|
|
Halofire
|
|
March 10, 2014, 10:08:48 PM |
|
We need to know how n-factor affected cpu miners, if hashes halved. Is anyone even cpu mining?
I don't know for ultracoin but this is what was tested for Yacoin when it was cpu only. You can see hashrate is roughly halved with each N increase as long as it doesn't change of memory type. For example, the change 13->14 shows a big loss because dataset doesn't fit in L2 cache anymore. Nfactor N Memory UNIX Time Date/Time in GMT Hashrate for 2x Xeon E5450 13 16384 2MB 1380574112 Mon - 30 Sep 2013 - 20:48:32 GMT 2,276 14 32768 4MB 1384768416 Mon - 18 Nov 2013 - 09:53:36 GMT 606 I see there are some questions that keep popping up again and again. Might as well pop in to see if I can help in some way. At what point does it become pointless to use our GPUs?
If the current n-factor gives me 120/150 KH/s for my 280Xs/290, the next will be be 60/75 and then 30/38. I will still be able to mine the same number of coins with these hash rates? Just trying to figure out how long my 4 280Xs and one 290 have got with this coin/scrypt.
N = 14 07 / 12 / 14 @ 04:20:16am UTC At this N and beyond it will be more cost effective to mine with CPU. I would like to know why does n-factor not affect cpu's. yeah yeah memory intensive, multiple threads, ram. i got all that, but if hashrate halves for cpu's as well, which I don't know if it halves, then wouldn't cpu mining still get harder over time as n-factors increase?
Can someone who has been cpu-mining AND experienced any n-factor change answer?
Been wondering this since day 1. Defo needs an answer. bump Both CPU and GPU are affected similar, in terms of dropping hash rate each N increase. However, the gap in actual hashrate gets smaller with higher N. As well, CPU's actually "fall-off" slower in hash slightly than gpu / perform better later. For example 600khs GPU with N increase may be similar to; 600>290>130>60>25>10>5. Comparing this to a CPU over same N increases; 125> 65> 35> 20> 10>5>2.5 Part of this reason was described best and quoted here; "CPU's still have a number of advantages over GPU's and ASIC's. They come with double precision floating point hardware, employ very advanced branch prediction mechanisms, incorporate at least 2MB of on chip L2/L3 cache, and are able to speculate through 4-6 branches even in ten year old machines. GPU's can manage 2-5x better double precision floating point performance than a typical CPU, but in some benchmarks, they cannot even manage even speed. The problem is worse for ASIC's, which must be custom designed around a specialized pipeline. "
Again quoting another location; here is a representation of hash rate on a CPU vs increasing N values. Running 1500 scrypt hashes with N=2048 - 0.00109417 avg. sec per hash Running 1500 scrypt hashes with N=4096 - 0.00216536 avg. sec per hash Running 1500 scrypt hashes with N=8192 - 0.00450547 avg. sec per hash Running 1500 scrypt hashes with N=16384 - 0.00928228 avg. sec per hash Running 1500 scrypt hashes with N=32768 - 0.01895874 avg. sec per hash Running 1500 scrypt hashes with N=65536 - 0.04028997 avg. sec per hash Running 1500 scrypt hashes with N=131072 - 0.08082690 avg. sec per hash
test written in python on an i5-4250U CPU @ 1.30GHz,
In the end it's not that CPU's hash way faster than GPU's at high N's; specifically, it's that CPU's cost less Watts per Kh/s to mine at higher N's. Some examples of hash rates and setups with CPU's and GPUs @ N = 14; can be seen here - http://yacoinwiki.tk/index.php/Mining_Hardware_ComparisonYou can see, as an example here @ N14 2x E5645 Procesors 2x 80W -- 1.53Kh/s 7950 GPU (250w) 1.3-1.5 Kh/s As shown above. the Processors will give approximately the same Kh/s for 160w versus 250w of a 7950. Bumface, is ziggy doing anything at all about the CPU mining problem?
what problem? There's no CPU miner for UTC... And the question have been asked many, many times. U can't advertise a coin for being GPU and CPU friendly after a while and not have a CPU miner There are a few CPU miners. One is listed on the Ultracoin forum too. However, there is one specific miner that is best and most up to date. -Manual N parameters for multiple coins -X86 and 64bit formats -Stratum pool capable -Scrypt optimizations for Scrypt-Jane https://github.com/thirtybird/cpuminer/releases/This is the absolute best CPU miner out there currently. I believe it has all the needs being asked for. Even though I'm not actively posting here; I still hate to not help if I can. Thanks Prot UftrEhcPx5hTY4YJvSziPi13dfZT9nXSqw So the coin is, in essence, ''miner resistant'' no matter what device mines it. pfft, advertise asic resistant when asics won't be mainstream for another few months. This changes everything and once again, hidden and tweaked info. utc seeming more and more like a sophisticated pump and dump since all ''miner-attainable coins'' will have been mined in 1 month with millions of coin inaccessible, in the blockchain. Diff will drop dramatically when gpu's no longer able to mine, so its good for the cpu's until the next nfactor after this next nfactor in april. Then pointless to mine completely.
|
OC Development - oZwWbQwz6LAkDLa2pHsEH8WSD2Y3LsTgFt SMC Development - SgpYdoVz946nLBF2hF3PYCVQYnuYDeQTGu Friendly reminder: Back up your wallet.dat files!!
|
|
|
Puycheval
Member
Offline
Activity: 95
Merit: 10
|
|
March 10, 2014, 10:13:21 PM Last edit: March 10, 2014, 10:29:45 PM by Puycheval |
|
In the end it's not that CPU's hash way faster than GPU's at high N's; specifically, it's that CPU's cost less Watts per Kh/s to mine at higher N's. Some examples of hash rates and setups with CPU's and GPUs @ N = 14; can be seen here - http://yacoinwiki.tk/index.php/Mining_Hardware_ComparisonYou can see, as an example here @ N14 2x E5645 Procesors 2x 80W -- 1.53Kh/s 7950 GPU (250w) 1.3-1.5 Kh/s Question is when is "the end" ? For N=14 from your link : R7 250 2 GB 32W 2.47 kH/s Previous 7950 test was run with an old cgminer and/or unoptimized settings (lookup gap = 2 ...) N=15 is nearly 10 months from here so the end will wait
|
|
|
|
Halofire
|
|
March 10, 2014, 10:21:34 PM |
|
coin output remains the same whether there's cpu's or gpu's, n-factor or not, so...... why would there be a price change based on asic/gpu mining resistance?
|
OC Development - oZwWbQwz6LAkDLa2pHsEH8WSD2Y3LsTgFt SMC Development - SgpYdoVz946nLBF2hF3PYCVQYnuYDeQTGu Friendly reminder: Back up your wallet.dat files!!
|
|
|
Puycheval
Member
Offline
Activity: 95
Merit: 10
|
|
March 10, 2014, 10:23:44 PM |
|
So the coin is, in essence, ''miner resistant'' no matter what device mines it. pfft, advertise asic resistant when asics won't be mainstream for another few months. This changes everything and once again, hidden and tweaked info. utc seeming more and more like a sophisticated pump and dump since all ''miner-attainable coins'' will have been mined in 1 month with millions of coin inaccessible, in the blockchain. Diff will drop dramatically when gpu's no longer able to mine, so its good for the cpu's until the next nfactor after this next nfactor in april. Then pointless to mine completely.
I don't get it. Everybody will suffer the same drop in hashrate for each N increase so diff coin output will stay the same unless people stop mining. And I think GPU are still ahead of CPU for 10 months+. Anyway I prefer utc not being cpu efficiently minable else it'll mean botnets, aws instances ...
|
|
|
|
LHM
Newbie
Offline
Activity: 26
Merit: 0
|
|
March 10, 2014, 10:38:07 PM |
|
--snip-- There are a few CPU miners. One is listed on the Ultracoin forum too. However, there is one specific miner that is best and most up to date. -Manual N parameters for multiple coins -X86 and 64bit formats -Stratum pool capable -Scrypt optimizations for Scrypt-Jane https://github.com/thirtybird/cpuminer/releases/This is the absolute best CPU miner out there currently. I believe it has all the needs being asked for. Even though I'm not actively posting here; I still hate to not help if I can. Thanks Prot UftrEhcPx5hTY4YJvSziPi13dfZT9nXSqw good find, looks like they just recently added the min/max and starttime parameters. +1 internets to you sir
|
|
|
|
mattbigblue
|
|
March 10, 2014, 10:41:21 PM |
|
lately I have tried to mine ybcoin but I couldn't find any working settings for it (n-factor is very high)..I have r9 290 and with ultracoin I'm getting 185kh/s...with ybcoin that is on higher n-factor, I was getting either 18kh/s!! with 100% hw errors, or 1,8kh/s stable so, unless we fine tune it.even the 18kh/s with 0% hw would be nice..utc and all other coins will be pointless to mine on higher n-factors.
|
|
|
|
cointradero
|
|
March 10, 2014, 11:38:56 PM |
|
Protagonus -- Good explanation above. More in detail than I was willing (and able in some cases) to go. Everything you posted is correct. Though, there was no discussion of how system RAM in multiple GPU machines will be affected by N-factor changes at 12 and above. I haven't found much information about it either, but the trend isn't looking good. I don't know if this is truly a system limitation or just an issue with how cgminer and it's derivatives allocate system RAM. Either way, the hashrates are likely going to go down even more on multi-GPU systems.
The problem is this eventually leads to botnet mining taking over. If they care to mine it at all. It also alienates most people that are in it to mine with GPUs. It's a bad case all around and completely unnecessary to be ASIC resistant.
edit: If someone could hardcode the N-factor to 12, or 13 and recompile it, could we not test out how it would hash on a testnet?
|
|
|
|
flobdeth
Member
Offline
Activity: 82
Merit: 10
|
|
March 11, 2014, 12:15:43 AM |
|
There are a few CPU miners. One is listed on the Ultracoin forum too. However, there is one specific miner that is best and most up to date. -Manual N parameters for multiple coins -X86 and 64bit formats -Stratum pool capable -Scrypt optimizations for Scrypt-Jane https://github.com/thirtybird/cpuminer/releases/This is the absolute best CPU miner out there currently. I believe it has all the needs being asked for. Get it repacked under a nice shiny UTC logo and get it on the webby
|
FTC 71Vkbk3UwbfGP3NDRbAWJwWDNRfaKKSfgE
|
|
|
AceCobra1
|
|
March 11, 2014, 12:37:06 AM |
|
I have been mining with my 1.2MH/s rig... But after leaving it for a day or so, the found shares drops down to almost 0... it still accepts fine... After I reboot the computer, the found shares speed goes back to "normal".... is there something wrong with my graphics card or is it just the way ultracoin works? It never did this when I was mining dogecoin
|
|
|
|
nanoprobe
Legendary
Offline
Activity: 980
Merit: 1000
Traveling in subspace
|
|
March 11, 2014, 12:41:53 AM |
|
I'm having a weird problem with CGwatcher and UTC. When I start the miner with CGWatcher it doesn't seem to read the conf file properly. I don't get anywhere near the hash rate I should be getting and it throws out HW errors. If I start mining by double clicking the miner.exe it runs perfect. It's seems like something happens when I add the miner exe to CGWatcher. I get the exact same problem on all my miners. Am I missing something?
|
You'll never know what you're living for until you know what you're willing to die for. Never look back, something might be gaining on you.
|
|
|
Thirtybird
|
|
March 11, 2014, 01:00:40 AM |
|
I see there are some questions that keep popping up again and again. Might as well pop in to see if I can help in some way. At what point does it become pointless to use our GPUs?
If the current n-factor gives me 120/150 KH/s for my 280Xs/290, the next will be be 60/75 and then 30/38. I will still be able to mine the same number of coins with these hash rates? Just trying to figure out how long my 4 280Xs and one 290 have got with this coin/scrypt.
N = 14 07 / 12 / 14 @ 04:20:16am UTC At this N and beyond it will be more cost effective to mine with CPU. Absolutely incorrect. I have done extensive work with YACoin, which is currently at N=14. If you know what to look for in a card and how to work with it, the GPU is extremely more efficient. My findings are out there if you do your research. If you can't find it, the summary is : 2.9 KH/sec with a GPU consuming 25watts - compare that to any cpu and it favors pretty well. I would like to know why does n-factor not affect cpu's. yeah yeah memory intensive, multiple threads, ram. i got all that, but if hashrate halves for cpu's as well, which I don't know if it halves, then wouldn't cpu mining still get harder over time as n-factors increase?
Can someone who has been cpu-mining AND experienced any n-factor change answer?
Been wondering this since day 1. Defo needs an answer. bump Both CPU and GPU are affected similar, in terms of dropping hash rate each N increase. However, the gap in actual hashrate gets smaller with higher N. As well, CPU's actually "fall-off" slower in hash slightly than gpu / perform better later. For example 600khs GPU with N increase may be similar to; 600>290>130>60>25>10>5. Comparing this to a CPU over same N increases; 125> 65> 35> 20> 10>5>2.5 Not bad, but what it actually boils down to is that the GPU runs out of memory to provide enough of a scratchpad to fully utilize all the shaders on the card without increasing the lookup gap, which in itself slows the hashing down. In the end it's not that CPU's hash way faster than GPU's at high N's; specifically, it's that CPU's cost less Watts per Kh/s to mine at higher N's. Some examples of hash rates and setups with CPU's and GPUs @ N = 14; can be seen here - http://yacoinwiki.tk/index.php/Mining_Hardware_ComparisonYou can see, as an example here @ N14 2x E5645 Procesors 2x 80W -- 1.53Kh/s 7950 GPU (250w) 1.3-1.5 Kh/s That's a poor comparison from the page. What is unfortunately missing from that page is the amount of memory the card has - this is the most important aspect of how the card will perform at N=14. I've put that info into many of the entries I've posted, but I'm not the only contributor. The Xeon you quoted is actually mine, and it is horribly inefficient! To get that, the server is running at over 400 watts, and I get a whole 1.53KH/sec (at idle it's over 260Watts), but I only get 1 miner out of it! With a GPU mining machine, I can run 4 cards giving 10+ KH/sec for 200 Watts. Actually, if you following cudaminer, the nvidia 750ti has come along and is now getting over 3 KH/sec for < 60Watts too. There are a few CPU miners. One is listed on the Ultracoin forum too. However, there is one specific miner that is best and most up to date. -Manual N parameters for multiple coins -X86 and 64bit formats -Stratum pool capable -Scrypt optimizations for Scrypt-Jane https://github.com/thirtybird/cpuminer/releases/This is the absolute best CPU miner out there currently. I believe it has all the needs being asked for. Even though I'm not actively posting here; I still hate to not help if I can. Thanks Prot UftrEhcPx5hTY4YJvSziPi13dfZT9nXSqw Finally, something I agree with
|
|
|
|
sakr
|
|
March 11, 2014, 01:03:35 AM |
|
New pool up and kicking at: http://thepool.pw/ultracoin/First blocks found, and payouts sent, looking forward to be accepted by this great community! Also, 50% of pool fees will be paid back to help community ongoing or new projects on a weekly basis.
|
|
|
|
Thirtybird
|
|
March 11, 2014, 01:07:34 AM |
|
Protagonus -- Good explanation above. More in detail than I was willing (and able in some cases) to go. Everything you posted is correct. Though, there was no discussion of how system RAM in multiple GPU machines will be affected by N-factor changes at 12 and above. I haven't found much information about it either, but the trend isn't looking good. I don't know if this is truly a system limitation or just an issue with how cgminer and it's derivatives allocate system RAM. Either way, the hashrates are likely going to go down even more on multi-GPU systems.
You need quite a bit of system RAM as the miner builds the OpenCL in system memory before passing it off to the GPU. If you have a 4GB GPU, you will want 8 GB of system memory, or run the cards with 2 threads (-g 2) and half the memory. This actually applies as you go up in number of cards as well. My baseline is that the machine has to have at least half of the ram of the SUM of all the GPU's in the machine. My miner with 4GB does okay with 2 4G cards, but even adding an additional 2GB card gets funny (I've found some workarounds, but it's a kludge). One other miner has 4x 2GB cards and works great with just 4 GB system memory. edit: If someone could hardcode the N-factor to 12, or 13 and recompile it, could we not test out how it would hash on a testnet?
I've found you can fake this by either setting the --minf and --maxnf to the value you want to test, or, you know, mine a coin that is on that NFactor... I maintain a list here if you want to test on a different coin: [url]https://docs.google.com/spreadsheet/ccc?key=0Aj3vcsuY-JFNdC1ITWJrSG9VeWp6QXppbVgxcm0tbGc&usp=drive_web#gid=0[/ulr]
|
|
|
|
|