Topic: GekkoScience 2Pac/Compac BM1384 Stickminer Official Support Thread - page 83. (Read 177410 times)

Yes, and only SHA256 coins. ASICs are hardware implementations of particular algorithms and therefore can only do one thing.

I did read the spec sheet for the BM1384 chip and I see where you pointed that it is specific for bitcoin mining.  Is it still possible to mine other SHA-256 coins?


Thanks

spiritminer

 Here's a copy of the BM1384 spec sheet:



 The BM1384 is the ASIC (Application-Specific Integrated Circuit) chip used in the production of the GekkoScience 2Pac BM1384 Stickminer

 By the way, that's the end of section 1.2 and there are no other applications listed.

Can you mine Scrypt with the Gekko Science 2pac or just SHA-256?


Any info would be great.



Spiritminer

A company I was doing business with wanted me to go into this new space they bought and assess the power situation for a small server room we wanted to put in there  (nothing to do with bitcoin). It looks like the previous tenant of the space had at least some mining stuff in there because there were two busted bitmain power supply's, and these 2pacs just laying there on a table. I dunno why.  There was also this awesome old Fellows small office shredder. That thing is sweet, no cheap office depot crap there, that shredder will take 20 pages and credit cards and staples and CD's without hesitation.
COmpany didn't want them, they just want to get the space up and going for their business needs, so they're mine now!

2pacs already saturating office spaces? Wow.
What could happen with the next gen (no apparent need to rush it)?

These sticks are awesome, I don't care what anyone says.

When you can make a chart that says freq 250, v 1.4 = 27.5gh/s and have the hardware supporting that work spot on.... that's nothing short of..... good math and a dedication to making it work right.
I came across 2 of these things from an abandon office we had came into, I recognized them straight away.

Had them running for two days now... superppag hub 1.4v exactly and mounted behind another server of mines exhaust fan asic backs at 60c ... and 2 days running rate:
 0: GSD 10012270: COMPAC-2 250.00MHz HW:0 | 37.49G / 27.52Gh/s WU:384.4/m
 1: GSD 10012287: COMPAC-2 250.00MHz HW:0 | 28.17G / 27.49Gh/s WU:384.0/m

I don't think you can get closer to the charts predicated 27.5 rate. I almost want to turn the voltage down, no HW errros.  

Good work sidehack. Spot on hardware is no small achievement.

look in the 1st post here for the answer to almost any questions you have...
That said, the adj. is hardware Voltage adjustment picture

The OP includes a chart showing amps and watts for different frequencies. The other axis in the chart is "Vcore", showing various voltages effect on the power draw.
Does anyone know how to adjust the vcore value? Is it a hardware adjustment or software setting?

Im  able to run a single 2Pac directly on a Pi 3b @ 50MHz. Other than the pook setting really high diff it's been working fine.
Ive been trying to find an appropriate powered hub, but may end up modding an existing powered hub with an external switching 5V psu.

i use at the moment one gekko i have a simple power usb hub 1,5 A
its running on 200 mhz with a fan. diff set of 16.
its working fine for me.
using a power hub was for me really needed even on 50 mhz the miner direct in my laptop pc or raspberry was not working for me.

It means your pool ignored your request and that is the new instructed difficulty to mine with. Some pools will only change from their user interface, while some require the first share to meet a preset min before completing a connection, some will slowly ramp you down over a period of time. Most pools are looking for a certain number of submits over a particular amount of time. This prevents a high hashing machine from dominating the connecting bandwidth while also preventing a network of low hashing machines from doing the same ie...a bot net.

What is the recomended diff? Im using :
--suggest-diff 128 --gekko-2pac-freq 50
but not getting any accepted shares...


Im seeing lines like this:
Does this mean I should be using 32768 instead of 128?

LOGGING

cgminer will log to stderr if it detects stderr is being redirected to a file.
To enable logging simply add 2>logfile.txt to your command line and logfile.txt
will contain the logged output at the log level you specify (normal, verbose,
debug etc.)

In other words if you would normally use:
./cgminer -o xxx -u yyy -p zzz
if you use
./cgminer -o xxx -u yyy -p zzz 2>logfile.txt
it will log to a file called logfile.txt and otherwise work the same.

There is also the -m option on linux which will spawn a command of your choice
and pipe the output directly to that command.

The WorkTime details 'debug' option adds details on the end of each line
displayed for Accepted or Rejected work done. An example would be:

 <-00000059.ed4834a3 M:X D:1.0 G:17:02:38:0.405 C:1.855 (2.995) W:3.440 (0.000) S:0.461 R:17:02:47

The first 2 hex codes are the previous block hash, the rest are reported in
seconds unless stated otherwise:
The previous hash is followed by the getwork mode used M:X where X is one of
P:Pool, T:Test Pool, L:LP or B:Benchmark,
then D:d.ddd is the difficulty required to get a share from the work,
then G:hh:mm:ss:n.nnn, which is when the getwork or LP was sent to the pool and
the n.nnn is how long it took to reply,
followed by 'O' on it's own if it is an original getwork, or 'C:n.nnn' if it was
a clone with n.nnn stating how long after the work was recieved that it was cloned,
(m.mmm) is how long from when the original work was received until work started,
W:n.nnn is how long the work took to process until it was ready to submit,
(m.mmm) is how long from ready to submit to actually doing the submit, this is
usually 0.000 unless there was a problem with submitting the work,
S:n.nnn is how long it took to submit the completed work and await the reply,
R:hh:mm:ss is the actual time the work submit reply was received

If you start cgminer with the --sharelog option, you can get detailed
information for each share found. The argument to the option may be "-" for
standard output (not advisable with the ncurses UI), any valid positive number
for that file descriptor, or a filename.

To log share data to a file named "share.log", you can use either:
./cgminer --sharelog 50 -o xxx -u yyy -p zzz 50>share.log
./cgminer --sharelog share.log -o xxx -u yyy -p zzz

For every share found, data will be logged in a CSV (Comma Separated Value)
format:
    timestamp,disposition,target,pool,dev,thr,sharehash,sharedata
For example (this is wrapped, but it's all on one line for real):
    1335313090,reject,
    ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000,
    http://localhost:8337,ASC0,0,
    6f983c918f3299b58febf95ec4d0c7094ed634bc13754553ec34fc3800000000,
    00000001a0980aff4ce4a96d53f4b89a2d5f0e765c978640fe24372a000001c5
    000000004a4366808f81d44f26df3d69d7dc4b3473385930462d9ab707b50498
    f681634a4f1f63d01a0cd43fb338000000000080000000000000000000000000
    0000000000000000000000000000000000000000000000000000000080020000

I may have passed this but where are the log files located? When i was running the 2pac i did not see any hw errors on the screen but when i exit it out the summery said ~8k.

Is CGMiner 4.10 still the latest program able to run the 2Pacs? My 2 is tricking along, still working to pay themselves off.

I believe the minimum frequency step is 6.25MHz; the chips' PLL doesn't really go more granular than that. --suggest-diff is all positive integers.

The config issue is a bug in stock cgminer 4.10 as was mentioned here a couple months ago.

I did not know you could 12.5 increments

Also, what are the increments/values for --suggest-diff?

If I leave it to a varying diff, sometimes I see some odd numbers  (22, 30, 61).  the 22 is what throws me off.  and I think I saw a 404 once.

Anyone having trouble saving a cgminer config? Everytime I try to save one it segfaults. I'm running cgminer from a raspberry pi.

Replace X with values like 32 / 64 / 128 and see where you're comfortable.