Topic: GekkoScience BM1384 Project Development Discussion - page 58. (Read 146725 times)

well you could go back to using a pot.

With enough burgers, you can do anything.

Yeah but now it's going to be really embarassing if we actually can't make per-board tuning work.

that works.  looking forward to it.

I was just calling attention to that I'd previously stated we'd try to make a per-board autotuning, so assuming it would not exist because nobody else had one and therefore we should make our firmware a lot more complex instead doesn't make a lot of sense.

Also, Phil, there will be no pot adjustment on the 18-chip board. Software adjustment only, but explicit manual control of that software setpoint will be included.

"You can't say cgminer will optimize all boards to the same point until you know what driver code we end up writing."
Absolutely correct, as I'm not privy to the "behind the scenes" thinking going on.

I can however make a reasonably correct statement based on the existing state of cgminer, et. al.
Which is what I think I did.

hand tweak of a pot is okay if you have 10 or less boards/sticks


10x 210gh if s-5 chips are used is a 2.1th setup

10x 280gh if s-7 chips are used is a 2.8th setup


to hand tune  more then 10 pots is a lot of work.

so an auto tune option is nice if possible.  and both pot  tune + auto tune  is best for a small setup or a big setup.

I am looking forward to development  of sticks and boards.  At least the summer months will have a thread to look at.

I have pretty much tested the single stick from freq100 to freq225

on the low end freq 125 or freq 150 work with out a fan at about .31 Watt/gh

on the high end freq 218.75 works well with a fan at about .34Watt/gh

I'm with Mikestang here even though I really love my early 1940's vintage Ford 9N for it's reliability, dependability, simplicity, and ease of maintenance.
My 3/4 ton GMC DuraMax crew cab long box w/ EFI live, an 8500 lb truck, will get 34 mpg on a flat road cruise set @ 55 in eco mode, but will turn a mid 11 second quarter mile in it's top setting (550+HP/1100+ft/lbs torque). And yeah I've seriously tweaked the fuel maps, boost maps, injection timing maps, shift points, etc. for each of the 5 available engine settings. Which can be changed on the fly, engine running, with the simple turn of a 5 position switch. I love blowing off kids in tuner cars leaving them in a black cloud of Prius repellent at the light. LOL.

My tools over the last 50 years have become more sophisticated (screw driver versus laptop) as technology has advanced.

No, because


You can't say cgminer will optimize all boards to the same point until you know what driver code we end up writing. If we can do per-board optimization, we will - and we probably can, because since we're using USB connection, each board should actually enumerate as a separate device. I seem to recall Habanero code could set each die's frequency and voltage differently. This should be no more difficult.

What I'd like to see is a cgminer command line that can set the clock and voltage per board (I really like the -S flag they used to have before hotplug support, where you explicitly stated what device was where) or a -autotune flag with parameters for voltage or clock (fix one, adjust the other) and an error threshold to shoot for.

Unfamiliar with the Avalon4, so I have no comment on it.

My follow on comments apply to the BM1382 (S3's and C1's) as I haven't started my testing on the BM1384's (S5's) which I'm more than willing to share when completed, if desired.
S3 hash boards are usually always stable @ .65 CoreV but not at clock rates approaching 150MHz. The limiting of clock rate limits profitability.
S3's @ .68 CoreV and 150MHz +- one clock setting seems to be the "sweet spot" from a electrical cost versus revenue standpoint.
I'm guessing this is due to a number of factors:

• board manufacturing tolerances due to variances in discreet passive components, resistor/cap tolerances, circuit trace tolerances, intertrace variances in capacitance, ground plane capacitance, etc . . . . .
• the CoveV/hashrate is not, necessarily, a smooth linear or exponential curve
• and active component (hash chip, LDO, etc.) manufacturing tolerances due to variances in a plethora of things at the wafer level

Having said the above there can be anomalous CoreV/clock rate combinations that provide, on a hash board by hash board basis, above "normal" net profits due to "quirks" in board/chip combinations.
This is why I would favor the calculations happening at the board level versus the driver level, cuz' each board is different (as is every hash chip chain on a particular board for that matter).
I also lean towards doing this at the board level to obviate the need for a special or "one off" branch in the cgminer/bfgminer source.
I was thinking more of the ability to set a flag (autooptimize=1/0, true or false ?) at cgminer/bfgminer run time if the appropriate hardware was detected after hotplug detection.
Implementing this flag architecture would allow the user to let the board figure it out or let the user "force" settings per their whims.

I think that the majority of the time the "optimal operating point based on power efficiency will pretty much always end you up at the top stable clock of the bottom possible voltage" is a true statement at the machine level, but on a fairly frequent basis there will be odd anomalous and/or deviant CoreV/MHz combinations at the board level/chip chain level that provide more optimal profits/performance.

With multiple boards in a machine there is a high likelihood that some boards/chip chains are going to be high performers and some not so much. If CoveV/MHz optimization is done at the driver level then all the boards running off that instantiation of cgminer/bfgminer will run at the least common denominator. If one board in many deteriorates faster than the others the entire machine's performance will suffer needlessly.

Over time components (active and passive) will deteriorate/change values. By definition, the interaction of those component deteriorations will cause a shift in the optimal CoreV/MHz operating point. Because one does not know which components are deteriorating, at what rate, and their effects on circuit performance a "self-healing" design reduces human interaction and assures optimal device operation in real time.

Just thinking "out loud".

The stick has a small pot for manual voltage adjustment. Phil's got lots of pictures in his review thread. The TypeZero will be a software-controlled voltage, but we'll make sure to have command-line control well before we have an auto-tuning feature so you can put it wherever you want it.

Someday if I ever get money I need to find a 4-barrel for my truck. That, and recam the engine and find it a 5-speed and regear the rear end and replace the diff with a manual locker. If some of the stuff we have going on works out, I could look into it this winter but heck I probably won't have time. You know how it goes - when you have the time, you don't have the money and when you have the money you don't have the time.

3 screws, tweak them by half a turn, car is a different beast.. i have it atm, lean to the point of white spark-plugs with cruising, dumping the fuel when the secondries open up, beats a modern 3L V6, with a whezzy 1.3L.. getting around 30mpg city, or 8L/100KM

much more easer then trying to add 1000 odd points into a throttle/fuel/air map

do a few aero mods, cold air intake (just got a filter sitting on top of the motor), and add manual tans, i could pull 40, maybe 50mpg..

..anyway


going like the old block eruptor blade style? with its voltage control via small pot?

But I prefer ready maintainability over complexity. Complexity, especially digital complexity, adds a lot of failure points not manageable with ordinary tools - as well as cost, both in design and materials. I also don't like automatic transmissions, because it's less fun to spend extra money on extra weight and mechanical complexity to *remove* control from the driver.

http://gekkoscience.com/philosophy.html

I'm surprised, EFI is way more tunable and customizable than carbs, especially when you get into writing your own engine management programs like I have.  I've contributed much of the tune to my Mustang, including stuff other than the usual air/fuel and timing, such as the mass air meter tables and transmission shift graphs/algorithms.  Way more fun than turning screws on a carb! 

Yes, and I need food and sleep so I'm not addressing sales concerns until tomorrow.

It is less about bad design and more about closed design. Also, the custom Hashboard interface sucks. Sidehack is designing everything to work out of the box with USB interface.

Btw sidehack, check PM... needin' psus

has anyone looked into modifying the S5's to be more efficient? are they designed that bad that you have to design an all new miner and PCB?

The sticks will never have auto tuning (for voltage control). The required overhead is stupid for a one-stick miner.

The 18-board will not be strictly auto-tuning. There's no reason to cripple a thing in software when the option for "more control" is already there. The primary reason I got into bitcoin mining hardware to begin with was because I liked messing with the hardware, so why would I give you guys something you can't play with to the max?

I also prefer carburetors to EFI.

auto-tuning is nice and all, but i do like to muck around doing my own manual tuning.. but im the type to still run a carburettor over electric-injectors..
leave the little buggers for the manual tuning, the 18-chip boards with auto, it should satisfy most people

autotuning would be a cool feature i know the feature on minera had it on cpuminer where you could tune it per chip on the 5 chip miners