Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 95. (Read 90841 times)
It is portable since it reads from a text file. For linux lm-sensors can create such a file. I am sure there are plenty windows applications aswell.
Hi all,
I'm now building 0.29d which will invalidate the 0.29c because the Haven was badly applied in some case, and Bixbite wallets conflict with IPBC. So i drop native support of bixbite (but it's still mineable with forced --variation 5 for Heavy) and rename IPBC into BitTube, its new name.
CPU temperature : it's pretty hard and not portable, dedicated software like HWInfo have lots of PLL and sensor database to read temp correctly, i don't have time enough to handle all of this, compared to what i still have to do about GPU. I'll add it for GPU, but not in early releases to save dev time.
Max hashrate is not useful for CPU since hashrate is ultra-stable on them (unless the PC is used for something else) but that's a great idea for GPU, i like it. In case of CPU+GPU mine, the total and max will be the ones of all cpu + all gpu.
I'm now building 0.29d which will invalidate the 0.29c because the Haven was badly applied in some case, and Bixbite wallets conflict with IPBC. So i drop native support of bixbite (but it's still mineable with forced --variation 5 for Heavy) and rename IPBC into BitTube, its new name.
CPU temperature : it's pretty hard and not portable, dedicated software like HWInfo have lots of PLL and sensor database to read temp correctly, i don't have time enough to handle all of this, compared to what i still have to do about GPU. I'll add it for GPU, but not in early releases to save dev time.
Max hashrate is not useful for CPU since hashrate is ultra-stable on them (unless the PC is used for something else) but that's a great idea for GPU, i like it. In case of CPU+GPU mine, the total and max will be the ones of all cpu + all gpu.
If you read CPU temperature via a text file, you will not write anything low level. Just a simple text file read. Lm-sensors take care of it. A simple cron jon, sensors output to text file and voila.
its linux only and thats exactly the definition of "not portable"
Hi all,
I'm now building 0.29d which will invalidate the 0.29c because the Haven was badly applied in some case, and Bixbite wallets conflict with IPBC. So i drop native support of bixbite (but it's still mineable with forced --variation 5 for Heavy) and rename IPBC into BitTube, its new name.
CPU temperature : it's pretty hard and not portable, dedicated software like HWInfo have lots of PLL and sensor database to read temp correctly, i don't have time enough to handle all of this, compared to what i still have to do about GPU. I'll add it for GPU, but not in early releases to save dev time.
Max hashrate is not useful for CPU since hashrate is ultra-stable on them (unless the PC is used for something else) but that's a great idea for GPU, i like it. In case of CPU+GPU mine, the total and max will be the ones of all cpu + all gpu.
I'm now building 0.29d which will invalidate the 0.29c because the Haven was badly applied in some case, and Bixbite wallets conflict with IPBC. So i drop native support of bixbite (but it's still mineable with forced --variation 5 for Heavy) and rename IPBC into BitTube, its new name.
CPU temperature : it's pretty hard and not portable, dedicated software like HWInfo have lots of PLL and sensor database to read temp correctly, i don't have time enough to handle all of this, compared to what i still have to do about GPU. I'll add it for GPU, but not in early releases to save dev time.
Max hashrate is not useful for CPU since hashrate is ultra-stable on them (unless the PC is used for something else) but that's a great idea for GPU, i like it. In case of CPU+GPU mine, the total and max will be the ones of all cpu + all gpu.
If you read CPU temperature via a text file, you will not write anything low level. Just a simple text file read. Lm-sensors take care of it. A simple cron jon, sensors output to text file and voila.
Hi all,
I'm now building 0.29d which will invalidate the 0.29c because the Haven was badly applied in some case, and Bixbite wallets conflict with IPBC. So i drop native support of bixbite (but it's still mineable with forced --variation 5 for Heavy) and rename IPBC into BitTube, its new name.
CPU temperature : it's pretty hard and not portable, dedicated software like HWInfo have lots of PLL and sensor database to read temp correctly, i don't have time enough to handle all of this, compared to what i still have to do about GPU. I'll add it for GPU, but not in early releases to save dev time.
Max hashrate is not useful for CPU since hashrate is ultra-stable on them (unless the PC is used for something else) but that's a great idea for GPU, i like it. In case of CPU+GPU mine, the total and max will be the ones of all cpu + all gpu.
said differently, once i release the gpu-capable versions, max hashrate will be displayed, even if you use zero GPU
I'm now building 0.29d which will invalidate the 0.29c because the Haven was badly applied in some case, and Bixbite wallets conflict with IPBC. So i drop native support of bixbite (but it's still mineable with forced --variation 5 for Heavy) and rename IPBC into BitTube, its new name.
CPU temperature : it's pretty hard and not portable, dedicated software like HWInfo have lots of PLL and sensor database to read temp correctly, i don't have time enough to handle all of this, compared to what i still have to do about GPU. I'll add it for GPU, but not in early releases to save dev time.
Max hashrate is not useful for CPU since hashrate is ultra-stable on them (unless the PC is used for something else) but that's a great idea for GPU, i like it. In case of CPU+GPU mine, the total and max will be the ones of all cpu + all gpu.
said differently, once i release the gpu-capable versions, max hashrate will be displayed, even if you use zero GPU
@JCE-Miner
Another great idea for you: Can you please make an option that can read CPU temperature via a file and report it? Something like that:
--tempFile=/home/rig3/cpuTemp.txt
contents of cpuTemp.txt (comma separated temperature of cores)
52,56,50,54
Thanks
Another great idea for you: Can you please make an option that can read CPU temperature via a file and report it? Something like that:
--tempFile=/home/rig3/cpuTemp.txt
contents of cpuTemp.txt (comma separated temperature of cores)
52,56,50,54
Thanks
Or even better - display it with hashrate.
@JCE-Miner
Another great idea for you: Can you please make an option that can read CPU temperature via a file and report it? Something like that:
--tempFile=/home/rig3/cpuTemp.txt
contents of cpuTemp.txt (comma separated temperature of cores)
52,56,50,54
Thanks
Another great idea for you: Can you please make an option that can read CPU temperature via a file and report it? Something like that:
--tempFile=/home/rig3/cpuTemp.txt
contents of cpuTemp.txt (comma separated temperature of cores)
52,56,50,54
Thanks
thanks for the test, it seems my autoconfig is bad on the A10, it allocates too many threads. I'll fix it, thanks.
The multihash (double hash is the 2-case, you can set from 1- to 6- ) is also called low-power in stak IIRC. It's about using, on one CPU core, twice the register and twice the cache to get sometimes twice the speed. The trick is that it let the other cores free, so it consume less power and allows the Turbo to enable, for CPU with turbo.
Technically, it's good, sure when you want to save power, but also when you run out of cores and not of cache. If you have a CPU with 2 cores but 8M cache, normal config would give only 2x2M = 4M cache used.
you may enable double-hash to use 2x2x2M cache = 8M of cache, and get some extra perf.
It works more or less depending on the CPU. It's very efficient on Ryzen, and not at all on Core2.
I looked closer at the A10, and yeah that's a little APU with little cache.
I give you an experimental config that could let you get some extra perf, but not sure, i cannot test, i've no A10.
"cpu_threads_conf" :
[
{ "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : false },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : false },
]
now finishing 0.29c, the last CPU-only version, with some updates.
The multihash (double hash is the 2-case, you can set from 1- to 6- ) is also called low-power in stak IIRC. It's about using, on one CPU core, twice the register and twice the cache to get sometimes twice the speed. The trick is that it let the other cores free, so it consume less power and allows the Turbo to enable, for CPU with turbo.
Technically, it's good, sure when you want to save power, but also when you run out of cores and not of cache. If you have a CPU with 2 cores but 8M cache, normal config would give only 2x2M = 4M cache used.
you may enable double-hash to use 2x2x2M cache = 8M of cache, and get some extra perf.
It works more or less depending on the CPU. It's very efficient on Ryzen, and not at all on Core2.
I looked closer at the A10, and yeah that's a little APU with little cache.
I give you an experimental config that could let you get some extra perf, but not sure, i cannot test, i've no A10.
"cpu_threads_conf" :
[
{ "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : false },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : false },
]
now finishing 0.29c, the last CPU-only version, with some updates.
12:52:22 | Hashrate Thread 0: 59.71 h/s
12:52:22 | Hashrate Thread 1: 2.57 h/s
12:52:22 | Hashrate Thread 2: 54.01 h/s
12:52:22 | Hashrate Thread 3: 2.44 h/s
12:52:22 | Total: 118.71 h/s
12:52:23 | Pool changes Difficulty to 2634.
limited to two threads with -t 2:
12:47:53 | Pool changes Difficulty to 2376.
12:47:59 | Hashrate Thread 0: 62.49 h/s
12:47:59 | Hashrate Thread 1: 60.26 h/s
12:47:59 | Total: 122.74 h/s
Try:
"cpu_threads_conf" :
[
{ "cpu_architecture" : "trinity", "affine_to_cpu" : 1, "use_cache" : true },
{ "cpu_architecture" : "trinity", "affine_to_cpu" : 3, "use_cache" : true },
]
sounds logical, jce api is either its own, or xmr-stak compatible, but not cpumineropt-compatible.
Maybe ask Awsomeminer to support jce, it should be simple since it has command line similar to cpuminerot (and to claymore) and api just like stak.
i got bad report about 0.29c algo selection, haven is broken, bixbite seems too, need to hot release a fix.
Done Maybe ask Awsomeminer to support jce, it should be simple since it has command line similar to cpuminerot (and to claymore) and api just like stak.
i got bad report about 0.29c algo selection, haven is broken, bixbite seems too, need to hot release a fix.
I suggested him to add JCE-Miner to Awesome too. Let's see what happens. I really love your miner.
JCE,
is it possible to add a max hashspeed storing for the current session and display this in the 'r' report and the light blue/cyan line that reports hash speeds every now and then?
it's easier to know the max speed this way.
is it possible to add a max hashspeed storing for the current session and display this in the 'r' report and the light blue/cyan line that reports hash speeds every now and then?
it's easier to know the max speed this way.
sounds logical, jce api is either its own, or xmr-stak compatible, but not cpumineropt-compatible.
Maybe ask Awsomeminer to support jce, it should be simple since it has command line similar to cpuminerot (and to claymore) and api just like stak.
i got bad report about 0.29c algo selection, haven is broken, bixbite seems too, need to hot release a fix.
Maybe ask Awsomeminer to support jce, it should be simple since it has command line similar to cpuminerot (and to claymore) and api just like stak.
i got bad report about 0.29c algo selection, haven is broken, bixbite seems too, need to hot release a fix.
so the no-cache is bad on the A10. It's very good on modern Intel, decent on Ryzen and bad on Core2. And so, bad on A10 too.
So keep the config you had found before, with two normal threads.
I won't have time to fix the A10 autoconfig in next version, will be for 0.30
edit: i'm polishing the GPU version.
I see very strange results on my Pitcairn rig (five different Pitcairns : 7870 and 7850, 1G and 2G...)
On my 2G, when I use all the memory available, I can reach 526h/s on my 7870 2G, and 495 on CN-v7 on my 7850 2G, which is far above what Claymore 9.7 gave on CN-Classic. It's even the best score ever I reached, period. Maybe i didn't configure SRB well, but so far i didn't reach such an hashrate.
But on my little 7850 1G, that's terrible, i peak at 343 where Claymore gave a whooping 450 !
It looks like my code is faster when using the double-memory, but a lot slower otherwise. And double-memory is barely possible on 1G cards. It works on Bonaire 1G because it has a little GPU that can be saturated with two threads using ~512M each, but my Pitcairn 1G are underused by an order of magniture...
The total hashrate of the rig, counting the 2G that mine faster and the 1G that mine slower, is 10% lower that claymore 11.3, but with 0 bad share, where Claymore, as I said previously, gives ~10% bad shares on old GPU when configured at max, or is stable at 10% lower hashrate.
0.29c online
I have to news, a good and a bad one:So keep the config you had found before, with two normal threads.
I won't have time to fix the A10 autoconfig in next version, will be for 0.30
edit: i'm polishing the GPU version.
I see very strange results on my Pitcairn rig (five different Pitcairns : 7870 and 7850, 1G and 2G...)
On my 2G, when I use all the memory available, I can reach 526h/s on my 7870 2G, and 495 on CN-v7 on my 7850 2G, which is far above what Claymore 9.7 gave on CN-Classic. It's even the best score ever I reached, period. Maybe i didn't configure SRB well, but so far i didn't reach such an hashrate.
But on my little 7850 1G, that's terrible, i peak at 343 where Claymore gave a whooping 450 !
It looks like my code is faster when using the double-memory, but a lot slower otherwise. And double-memory is barely possible on 1G cards. It works on Bonaire 1G because it has a little GPU that can be saturated with two threads using ~512M each, but my Pitcairn 1G are underused by an order of magniture...
The total hashrate of the rig, counting the 2G that mine faster and the 1G that mine slower, is 10% lower that claymore 11.3, but with 0 bad share, where Claymore, as I said previously, gives ~10% bad shares on old GPU when configured at max, or is stable at 10% lower hashrate.
0.29c online
Quote
Use of the GPU version frontend, but GPU disabled
Support of Masari fork --variation 11
Support of Haven fork --variation 12
Stellite defaults to XTL variation
ETN defaults to v7
other coins that have forked will default to their respective fork
Coin list in alphabetical order
new coin : BXB
new coin : WOWnero
-b parameter ignored for compatibility with AwsomeMiner
ditto with parameter --api-remote
Support of Masari fork --variation 11
Support of Haven fork --variation 12
Stellite defaults to XTL variation
ETN defaults to v7
other coins that have forked will default to their respective fork
Coin list in alphabetical order
new coin : BXB
new coin : WOWnero
-b parameter ignored for compatibility with AwsomeMiner
ditto with parameter --api-remote
The good: JCE is lauching normally by Awesome as CPUMiner-Opt.
The bad: API isn't working with Awesome:
Quote
18/06/2018 17:26:35.007 [022] [E]Failed to process API request (time: 1001 ms): summary
Nenhuma conexão pôde ser feita porque a máquina de destino as recusou ativamente 127.0.0.1:4034
18/06/2018 17:26:41.239 [023] [E]Failed to process API request (time: 1001 ms): summary
Nenhuma conexão pôde ser feita porque a máquina de destino as recusou ativamente 127.0.0.1:4034
18/06/2018 17:26:47.440 [027] [E]Failed to process API request (time: 1000 ms): summary
Nenhuma conexão pôde ser feita porque a máquina de destino as recusou ativamente 127.0.0.1:4034
18/06/2018 17:26:53.655 [041] [E]Failed to process API request (time: 1000 ms): summary
Nenhuma conexão pôde ser feita porque a máquina de destino as recusou ativamente 127.0.0.1:4034
Nenhuma conexão pôde ser feita porque a máquina de destino as recusou ativamente 127.0.0.1:4034
18/06/2018 17:26:41.239 [023] [E]Failed to process API request (time: 1001 ms): summary
Nenhuma conexão pôde ser feita porque a máquina de destino as recusou ativamente 127.0.0.1:4034
18/06/2018 17:26:47.440 [027] [E]Failed to process API request (time: 1000 ms): summary
Nenhuma conexão pôde ser feita porque a máquina de destino as recusou ativamente 127.0.0.1:4034
18/06/2018 17:26:53.655 [041] [E]Failed to process API request (time: 1000 ms): summary
Nenhuma conexão pôde ser feita porque a máquina de destino as recusou ativamente 127.0.0.1:4034
In most case such an error comes from a fork I enabled in advance, like XTL but here that's a real bug, Heavy algorithm is used in place of Haven when multihash is used. gracefully multihash is rarely used with Heavy/Haven. a hotfix will come soon.
It means Haven has not forked yet.
of course it is forked, the new algo is CN Haven, asic&NH proof
thanks for the work on this.
I just notice one problem on the machine I'm currently using.
It only uses 3 of the 4 cores.
Adding the -t 4 right behind the --auto parameter in the start batch file seems to solve the 'problem'.
CPU is an Intel i5-4590 3.3GHz
I just notice one problem on the machine I'm currently using.
It only uses 3 of the 4 cores.
Adding the -t 4 right behind the --auto parameter in the start batch file seems to solve the 'problem'.
CPU is an Intel i5-4590 3.3GHz
it should have forked already, and Masari should fork in a few hours.
probably my code is broken in multihash, i've so many assemblies now that it's almost impossible to test all in decent time.
i'll release an emergency fix asap, thanks for the report !
probably my code is broken in multihash, i've so many assemblies now that it's almost impossible to test all in decent time.
i'll release an emergency fix asap, thanks for the report !
It means Haven has not forked yet.
--variation 12
returns bad shares with multi_hash higher than 2
while --variation 5 works fine
tested on Core i5 7600k (6MB cache)
returns bad shares with multi_hash higher than 2
while --variation 5 works fine
tested on Core i5 7600k (6MB cache)
so the no-cache is bad on the A10. It's very good on modern Intel, decent on Ryzen and bad on Core2. And so, bad on A10 too.
So keep the config you had found before, with two normal threads.
I won't have time to fix the A10 autoconfig in next version, will be for 0.30
edit: i'm polishing the GPU version.
I see very strange results on my Pitcairn rig (five different Pitcairns : 7870 and 7850, 1G and 2G...)
On my 2G, when I use all the memory available, I can reach 526h/s on my 7870 2G, and 495 on CN-v7 on my 7850 2G, which is far above what Claymore 9.7 gave on CN-Classic. It's even the best score ever I reached, period. Maybe i didn't configure SRB well, but so far i didn't reach such an hashrate.
But on my little 7850 1G, that's terrible, i peak at 343 where Claymore gave a whooping 450 !
It looks like my code is faster when using the double-memory, but a lot slower otherwise. And double-memory is barely possible on 1G cards. It works on Bonaire 1G because it has a little GPU that can be saturated with two threads using ~512M each, but my Pitcairn 1G are underused by an order of magniture...
The total hashrate of the rig, counting the 2G that mine faster and the 1G that mine slower, is 10% lower that claymore 11.3, but with 0 bad share, where Claymore, as I said previously, gives ~10% bad shares on old GPU when configured at max, or is stable at 10% lower hashrate.
0.29c online
So keep the config you had found before, with two normal threads.
I won't have time to fix the A10 autoconfig in next version, will be for 0.30
edit: i'm polishing the GPU version.
I see very strange results on my Pitcairn rig (five different Pitcairns : 7870 and 7850, 1G and 2G...)
On my 2G, when I use all the memory available, I can reach 526h/s on my 7870 2G, and 495 on CN-v7 on my 7850 2G, which is far above what Claymore 9.7 gave on CN-Classic. It's even the best score ever I reached, period. Maybe i didn't configure SRB well, but so far i didn't reach such an hashrate.
But on my little 7850 1G, that's terrible, i peak at 343 where Claymore gave a whooping 450 !
It looks like my code is faster when using the double-memory, but a lot slower otherwise. And double-memory is barely possible on 1G cards. It works on Bonaire 1G because it has a little GPU that can be saturated with two threads using ~512M each, but my Pitcairn 1G are underused by an order of magniture...
The total hashrate of the rig, counting the 2G that mine faster and the 1G that mine slower, is 10% lower that claymore 11.3, but with 0 bad share, where Claymore, as I said previously, gives ~10% bad shares on old GPU when configured at max, or is stable at 10% lower hashrate.
0.29c online
Quote
Use of the GPU version frontend, but GPU disabled
Support of Masari fork --variation 11
Support of Haven fork --variation 12
Stellite defaults to XTL variation
ETN defaults to v7
other coins that have forked will default to their respective fork
Coin list in alphabetical order
new coin : BXB
new coin : WOWnero
-b parameter ignored for compatibility with AwsomeMiner
ditto with parameter --api-remote
Support of Masari fork --variation 11
Support of Haven fork --variation 12
Stellite defaults to XTL variation
ETN defaults to v7
other coins that have forked will default to their respective fork
Coin list in alphabetical order
new coin : BXB
new coin : WOWnero
-b parameter ignored for compatibility with AwsomeMiner
ditto with parameter --api-remote
thanks for the test, it seems my autoconfig is bad on the A10, it allocates too many threads. I'll fix it, thanks.
The multihash (double hash is the 2-case, you can set from 1- to 6- ) is also called low-power in stak IIRC. It's about using, on one CPU core, twice the register and twice the cache to get sometimes twice the speed. The trick is that it let the other cores free, so it consume less power and allows the Turbo to enable, for CPU with turbo.
Technically, it's good, sure when you want to save power, but also when you run out of cores and not of cache. If you have a CPU with 2 cores but 8M cache, normal config would give only 2x2M = 4M cache used.
you may enable double-hash to use 2x2x2M cache = 8M of cache, and get some extra perf.
It works more or less depending on the CPU. It's very efficient on Ryzen, and not at all on Core2.
I looked closer at the A10, and yeah that's a little APU with little cache.
I give you an experimental config that could let you get some extra perf, but not sure, i cannot test, i've no A10.
"cpu_threads_conf" :
[
{ "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : false },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : false },
]
now finishing 0.29c, the last CPU-only version, with some updates.
The multihash (double hash is the 2-case, you can set from 1- to 6- ) is also called low-power in stak IIRC. It's about using, on one CPU core, twice the register and twice the cache to get sometimes twice the speed. The trick is that it let the other cores free, so it consume less power and allows the Turbo to enable, for CPU with turbo.
Technically, it's good, sure when you want to save power, but also when you run out of cores and not of cache. If you have a CPU with 2 cores but 8M cache, normal config would give only 2x2M = 4M cache used.
you may enable double-hash to use 2x2x2M cache = 8M of cache, and get some extra perf.
It works more or less depending on the CPU. It's very efficient on Ryzen, and not at all on Core2.
I looked closer at the A10, and yeah that's a little APU with little cache.
I give you an experimental config that could let you get some extra perf, but not sure, i cannot test, i've no A10.
"cpu_threads_conf" :
[
{ "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : false },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : false },
]
now finishing 0.29c, the last CPU-only version, with some updates.
12:52:22 | Hashrate Thread 0: 59.71 h/s
12:52:22 | Hashrate Thread 1: 2.57 h/s
12:52:22 | Hashrate Thread 2: 54.01 h/s
12:52:22 | Hashrate Thread 3: 2.44 h/s
12:52:22 | Total: 118.71 h/s
12:52:23 | Pool changes Difficulty to 2634.
limited to two threads with -t 2:
12:47:53 | Pool changes Difficulty to 2376.
12:47:59 | Hashrate Thread 0: 62.49 h/s
12:47:59 | Hashrate Thread 1: 60.26 h/s
12:47:59 | Total: 122.74 h/s
good idea. It won't be possible in the earlier versions, but i love the idea.
0.29c updates :
0.29c updates :
Quote
Use of the GPU version frontend, but GPU disabled
Support of Masari fork --variation 11
Support of Haven fork --variation 12
Stellite defaults to XTL variation
ETN defaults to v7
other coins that have forked will default to their respective fork
Coin list in alphabetical order
new coin : BXB
new coin : WOWnero
-b parameter ignored for compatibility with AwsomeMiner
ditto with parameter --api-remote
Support of Masari fork --variation 11
Support of Haven fork --variation 12
Stellite defaults to XTL variation
ETN defaults to v7
other coins that have forked will default to their respective fork
Coin list in alphabetical order
new coin : BXB
new coin : WOWnero
-b parameter ignored for compatibility with AwsomeMiner
ditto with parameter --api-remote
Jump to: