Topic: [ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 123. (Read 409571 times)

When setting a clock value in MPBM above roughly ~62MHz MPBM reports "Setting clock speed failed!", and from that point on reports a wildy inaccurate hashrate under "Current Hashrate" and "Average Hashrate". More sane values are shown under "Effective Hashrate" though. However, the device continues to operate and submit valid shares. The more I increase the clock past 62, the higher the effective hashrate becomes.

Thank you for your work on these devices kramble. I am in no rush for faster bitstreams, I was happy at ~400MHs.

I added BlueDragons ny1.blakecoin.com pool to MPBM and it reports my current hashrate at ~550MHs. I will update later.

Good, so it is working then. What was confusing me was the log (code block) from a couple of posts up where it failed to set it above 64. I'm still a little confused by this as you're now setting it to 115 and it is working, but 64 was not? Is there some window of values where it is broken? EDIT, no, I'm definitely not thinking straight, the StaticClock version has a fixed 125MHz clock speed, it won't overclock or underclock, it just runs at that speed, which should be exactly 500MHash/sec.

What's even more confusing is that the "Setting clock speed failed!" message is the result of just reading back the configuration register from the FPGA, which is just dependent on the jtag clock and should not break even if the DCM failed to program.

I'll get on with trying for a faster build, but this can take a while (like days sometimes). EDIT. Well I just kicked it off looking for FMAX=130, but I'm not so sure that this is worthwhile now. It'll probably fail PAR anyway, so the next try will be for a 150MHz StaticClock I think.

No, I'm sorry, mis-communication. Setting the clock to ~62 in MPBM results in the correct hashrate and clock speeds being shown in MPBM, but the hashrate is very low. It is around the speed one would expect if the chips were actually clocked at ~62MHz.

I am currently running X6500-StaticClock-v01-2core-125MHz.bit in MPBM, min clock set to 115, max clock set to 135. Effective hashrate 474MHs. I would need to leave things running for far longer to get more accurate numbers of avg hashrate.

EDIT: Effective hashrate settling above 580MHs. I will let it run on these settings for a while and try to grab a more accurate average MHs value.

Ah, (crosspost, see my edit above), thanks for that, so 62 is effectively giving 500MHash/sec? If so then that's useful to know as I can just try rebuilding the original bitstream for a faster FMAX.

You would know better than I, but I do not believe the clock problem is an issue with *2 somewhere. Despite the hashrate being reported incorrectly in the gui the device seems to operate correctly, not overheating, and at a hashrate pool side closer to that which is reported by mpbm as "effective hashrate". When using the x6500s with mpbm for BTC mining the clock values are given as actual values, not /2. When set at a clock speed which does not result in incorrect reporting of hashrate (~62) the device hashes at a correspondingly low rate.

I am trying the 125MHz.bit, I just had the 100MHz.bit up over 500MHs.

OK, it looks like the overclock is broken (I vaguely remember being suspicious of it).

I've just checked the build logs for X6500-Robust-v04-2core-fmax-100MHz.bit and what it ought to be doing is initializing the DCM to 100MHz clock then immediately reprogramming to 50MHz (BOOTUP_FREQUENCY). What I suspect is happening is that the reprogramming fails and the FPGA runs at 100MHz which corresponds to 400MHash/sec (2 FPGA with 2 cores each).

The overclock parameter ought to be reprogramming the clock speed each time mine.py is run, but you should be able to get it significantly above that initial 100MHz. It is possible there is a factor of 2 in there somewhere, and 64MHz corresponds to an actual clock speed of 128MHz (which would be reasonable given fmax=100MHz), but I can't see it in the code.

To confirm this, it would be useful to see if overclock is having any effect at all, both on the reported hash rate and that at the pool. If it is actually changing the clock speed then we can make some use of it (even if I don't understand where the factor of 2 is coming in), otherwise I could just get rid of it entirely and do a fixed clock speed build. I've found a 125MHz version I did earlier that you may want to try https://www.dropbox.com/s/g7iqzfl4yzmsnk2/X6500-StaticClock-v01-2core-125MHz.bit

EDIT: I see that "Setting clock speed failed!" comes from MPBM rather than mine.py (no matter, I assume it works pretty much the same way, its just that MPBM is a lot more complex to understand what's happening). If you were using mine.py you would probably need to manually increase the getwork rate as it defaults to 20sec which is OK for bitcoin but not for the blake bitstreams since only half of the nonce space is scanned (this was to support up to 4 cores, though I could drop this requirement now). I run my lancelot at 2 seconds for 800MH/s.

Ah, (crosspost), thanks for that, so 62 is effectively giving 500MHash/sec? If so then that's useful to know as I can just try rebuilding the original bitstream for a faster FMAX.

Ever since I uncommented line 104 of mine.py the hashrate is reported as 0 but things still work and shares are submitted. I have not tried modifying the clock settings, I have just left things at the default so far. IIRC mine.py reported ~400MHs. Currently MPBM reports ~600MHs effective against the blake getwork source and 402MHs effective for the x6500 device itself.  I am trying to mess with the clock speeds now in MPBM but it seems once I set them to go above 80 mpbm starts reporting drastically incorrect hashrates.

I will try to think of things to add to the readme. I am not sure which mining software should be recommended, mine.py or mpbm. It seems like personal preference to me, I like mine.py. I left MPBM running and attempted to work in TheSevens fixes for the stratum divide by zero issue with eloi pool, but have not succeeded yet. Still going fine via getwork though.


EDIT: When the clocks step above ~62 strange things start to happen.

Then the reported hashrate is ~4.2 THs, this causes the job interval to be decreased drastically, so I changed the hardcoded "max" value of 0.5 to 2.5. It still manages to submit valid shares.

Thanks. I've updated the github with this change (ideally the validation job would be changed instead but this will do for now I guess). I've also changed the default branch from testing to master in the repo (the testing branch does not include my blake mods).

I need to update the README with some guidelines for driver installation and miner instructions, so let me know what you think I should add.

Should I recommend using MPBM or the X6500 python miner?

Also with the python miner, what overclock setting did you use to achieve 400MH/s? Looking at the verilog code, it defaults to 50MHz which seems a bit slow compared with the 200MHz we're getting on the ztex port, but there may be a scaling factor to confuse matters, which is why I'd like to know the actual hash rate achieved and clock setting. If its just 400MH/s for the entire board (dual fpgas) it should be possible to roughly double this with some tuning of the bitstream (not that I enjoy this task, Xilinx ISE is a right PITA).

Your modified MPBM worked for me with a couple changes.

I overwrote my last working copy of mpbm with your updated files.
I added a blakecoin getwork source. (stratum doesn't work, old divide by zero bug between mpbm <-> eloi)
I had to copy the blake8.py file found in the /mpbm/core/ directory to the /mpbm/ directory. (The directory which contains mpbm.exe, run-mpbm.py) The need for this may be a simple path typo, I haven't checked the code yet.
I changed line 431 of /mpbm/modules/fpgamining/x6500/x6500worker.py from:
self.checksuccess = False
to:
self.checksuccess = True

With just these modifications the x6500 successfully submits shares to a pool. The hashrate is reported incorrectly. Just a quick and dirty copy pasta to get mpbm going in windows with blakecoin firmware from kramble and an x6500. Thanks for all your efforts kramble.

Windows 8.1

Krambles X6500 stuff, with the line 436 commented out in FPGA.py.

Also had to remove http:// from the address.

And I also had to pull the usb on the x6500 after programming to get miner to connect.

Win32? linux? or what?

I guess that means your not selling x6500's now? 

Guess who's mining BLC?

ME!

Haha, thanks Ignatius, Mogrith, Kramble, and BlueDragon for being very supportive!

Thanks! I'll update the github version with those two changes (it'll be tomorrow as I'm a bit tired tonight so I don't want to risk messing it up).

I have always had to use Chrome to get MPBM to display properly. If I get time I will try the modified mpbm.

NOTE: This works!

Commenting out line 436 of fpga.py allows me to connect and mine against ny1.blakecoin.com, whereas I previously could not do so.

I did a quick hack of MPBM to support Blakecoin way back (link), NB it's the master branch, not the default testing. I don't know if it works though (it probably needs some tweaking to work on pool rather than solo). I couldn't even get the original bitcoin version to work nicely with my browsers (firefox, IE).

I think we almost got there a couple of weeks back ...


The driver problem needs to be sorted out first though. It's getting a little late here though, so I'm not going to be online very much longer tonight.

I used MPBM.

Perhaps I will load the bitstream with MPBM like you did and try running miner.py.

I had it running at one point on my Windows 8.1 machine but every time it would submit a block it would get rejected, and it would not get shares from a pool either.

Nor could I, so I tried a 32b Windows XP virtual machine, and it worked. What mining software did you previously use with x6500's? I used MPBM, and could even write the blake bitstream to the x6500 via MPBM...it just wouldn't mine after(obviously, mpbm being unmodified for blake).

Same issue I had on win7 64.