I could be wrong, but I had the impression that all the ports are fed directly from the powersupply and not individually through a usb hub chip. The total rated power is 40A which should be plenty, but I can see from the significant voltage drop that isn't optimal. I am not sure how the core voltage depends on the supply voltage and if it matters.

Well, the Eyeboot 19 port 40A is more or less mil-grade, made of sturdy metal, looks very nice, but as jstephanop wrote a while ago, he wasn't sooo enthusiastic having noticed problems with the pins and the power capability. This monster cost me a fortune because alternative hubs from Amazon didn't ship to my country. It is almost embarrassing to note how much I paid for the think when I finally had it (with shipping and taxes).

Yes I did all that, also core. I feel I have a good control in general. What I learned is that stability is way more important than a slightly higher hashrate. Nothing is as frustrating as that the MLDs have stopped hashing, or for some reason drop out. One MLD no problem, all 11, impossible, lately the 'best' 8 - also impossible. I am sure it is this hub. That's why it can't be stressed enough that if you're running more than 1-2 MLDs that you really really pay attention to what hub you are getting.

Nah, never really warm. maybe 100W, no problem. I would say not more than maybe 25degs (in room temp <15degs C).
Thanks for all the feedback!

Awesome.

My experience is slow but painfull deteroriation over the last 3 months. I have 11 units, and initially all worked well on my hub.
Now I have one that refuses to be recognised by the USB driver on the hub but works well on the PC
And I have one that generate some kind of memory write error (on the hub, I have not tested it on the PC)
Initially all remaining 9 worked well on the hub, but slowly but certainly more and more start hashing at reduced speed, like 2Mh/s. It was stable for weeks no problem, and then it starts and doesn't want to go away.

I use an eyeboot 19 port hub, I even dialed up the open port voltage to 5.2V, it drops down to 4.9V under load (earlier it went from 5.05 to 4.75V). It certainly did not make it better. I know I have one bad USB slot on the hub. JStephanop wrote earlier that "eyeboot hubs are known for bad usb contacts and performance issues".

I have no idea what the problem is with my setup. I have been all clockspeeds up from 600Mhz, adjusted pots up and down, so I feel I have reasonable control. Maybe the core voltage is drifting that is possible of course. No idea.

No I have switched all off, and will take a break to figure out how to proceed. Buying a new hub is not an option, the eyeboot already cost me too much. I give it a pause before I might just start the whole lot again from scratch.

Hehe, if it was that easy: I regularly have that bfgminer fails to recognise the type of device and thereby extract the serial number, BUT it still hashes away!
I also used the bfgminer debug mode to look in more detail and see it happens when the usb/com ports are pinged. It finds the port but not what is attached to it. Still it starts hashing, without knowing what is attached to it.

I have something weird: I have one MLD flashing red LED but it doesn't show up in bfgminer!! That means it kept hashing but probably got disconnected from bfgminer. It is not in bfgminer anymore, bfgminer is one MLD short. I don't know when it happened or how it happened. I am not sure exactly which physical device it is. Later today I will just restart bfgminer and it probably will get connected again.

I always thought it would be a nice little Arduino project to pwm control the fans and regulate them via a temp sensor glued onto each heatsink.

The fan should start working the second you plug it into ANY usb port, as the green led comes on. You don't have to run bfgminer. Note that in some circumstances the fan can be really quiet (I think especially if it is facing downwards). Make sure to double check (I sometimes touch the fan on the backside just to feel), Also check and press on the little white connector, just to make sure it is making proper contact (normally that should always be the case). Also, without power, make sure that the fan can spin freely, if necessary loosen the 2 screws that hold the fan onto the heatsink a little (just a little).

You can look at the mld-bfgminer source code to see the interface commands (so-called MLD driver), i.e. the commands that are used to talk to the MLD. That's effectively what makes the MLD run. Page 1 gives the link to the code including source.

That's not enough... See also page 1 of this thread. The problem you have is power related.


Also, and has been written in this thread numerous times, start easy and then increase speed/pot settings.
So, start with two units at say 600Mhz, and dial mem and core pots back to the minimum while it still keeps running good.
Then increase frequency one or a few steps, and IF NEEDED, increase pots. If not, don't do anything. Repeat this process until you get at the desired or max feasible frequency on your system.

Everything is answered in this thread Yes the printout is 63, it counts from 0. The normal hashrate = 5.66*clockspeed (page 1), meaning that 796Mhz gives ca 4.5Mh/s, which is what you get and there is no miracle in it. 

Much lower than expected hashrates, very often somewhere between 2-2.5Mh/s can in many cases be traced back to power-supply issues. jstephanop has some theories on exactly what happens in the ASIC (somewhere in this thread). Out of personal experience, I would say that from 800Mhz and up you just have to try and play play with the hub and pot settings and temperature to find a good and above all stable setup. As I wrote earlier, I have a whole bunch running at 924Mhz and some others at 856Mhz or something like it, but it took me while to get it exactly there. 796 was a piece of cake.   

far below?? well below?? Seriously, all that is given is that the chip hasn't fried itself, just yet. Good luck! You are operating at the edge of it's operating range, and while 153F is within limits by all accounts it is seriously hot. 176F is not a safe operating limit, but a potential fry and die limit. You also have to be aware of changes in ambient temperature, if the ambient rises, so goes the chip temp. In general, even if it runs, you will shorten lifespan if it gets that hot over long time.

When you are overclocking you are on your own, and you want to do everything reasonable to keep the babies alive. Alive==cool. 832 == overclocking. But yeah, it's not that you MUST have cooling. But you should! jstephanop wrote a good comment on this a few pages back, when one guy had 8 MLDs running at 5.5Mh/s or thereabout. You should read it. I run at 924Mhz with about 0.7%HW and ca 45C core. AND extra cooling (usb fans).  Some ppl remove the stock fans --> you are on your own, even at normal clockspeeds. 10% is way too high at normal clockspeeds. You should have less than 1% at 600Mhz.

Back in the old days people read the instructions first -- see page 1 of this thread:


Everyone using these beyond 800Mhz uses external cooling (fans). 162F = 72C which is getting borderline, 153F = 67C is really hot. I am running at around 35C = 95F.

I have 11 and use the Eyeboot 19 port hub. The reason I bought that one is because better hubs fram Amazon didn't ship to my country. While the hub looks great, and it probably is, I only have trouble with it.
1) I cannot run all 11 at full speed (924Mz), that doesn't work. So I have a mix of frequencies to make it just work. I can live with that
2) The USB ports are just a bit too close so in reality one can use only every other USB port, this seems to be a common issue with many USB hubs, but not all.
3) The USB connectors used on eyeboot hubs seem a bit weak, jstephanop also pointed this out. Because of the constant vibrations from the minifans eventually some may break down. I have at least one where both power pins and data pins suck and connection a/o power gets interrupted. In effect I am loosing more and more USB slots
4) It is hellish expensive

A few pages back someone showed a setup with smaller hubs with 2MLDs per hub and he had four of those hbs daisychained. That seems to me the best solution in terms of cost, reliability and performance.

Not sure what readme you are refereing to, this thread -- all the 50+ pages -- IS the readme!, and answers all your questions!! And yes it is all possible, very easily.

The first thing you have to realize is that the link between physical USB port, virtual COM port, and MLD # is not fixed.
You need to open your computers device manager, plug in the first MLD into some USB port, and see which COM port pops up on the virtual com ports in the device manager (usually COM3). Make note of it. Then do the same for the 2nd MLD etc (usually COM4). This is before you have started bfgminer.
Then, you can set different clockspeeds for different com ports in one startup script, or create two scripts, one for each of the two com ports, one script with one clockspeed/one pool/one coin, and the other for the other clockspeed etc. The latter approach is needed for different pools/coins anyway, but I also prefer it for different clockspeeds as it is then easier to see which MLD in bfgminer is actually supposed to run at the desired hashrate. You just start each startup script (bat file) as normal.

Now the magic that you have been waiting for: the -S MLD command?? To skip over 53 pages of support thread should really cost you 0.1LTC straight into my wallet, but I will help you for free : -S MLD:\\.\COM3 instead of -S MLD:all for the script that is to mine the MLD that appeared in virtual com port #3 (use the actual number that showed up in device manager). The other script would thus have -S MLD:\\.\COM4 for example. The two scripts can have different clockspeed settings and different pools as per normal.   

These are the cumulative rewards per worker (you have 5 workers) and the sum of this should appear under rewards summary (sum of paid/unpaid balance, but with these small rewards you have nothing paid). Since the numbers are so small, it means that whatever you use to mine has very little hashing power, maybe you are using a PC's CPU? Look at the speed on the left side of the same rows. Anything that is not at least some Mh/s is more or less useless. If you get zero you probably have your miner not configured properly.

Have you plugged the one device straight into a PC USB port and tried that? I have something similar, one MLD isn't recognised properly by my hub anymore, sometimes it doesn't show up in device manager, sometimes it does, but when it does bfgminer doesn't recognize the device (no device found). It happens on any usb port on the hub. Other MLDs on the same hub are fine. The malfunctioning device works fine when directly plugged into a PC USB port (using win10).

If possible you might give that a try. If that doesn't work either, there is little hope I guess. Since your device is recognized it suggest that the usb chip on the mld is just fine. If it doesn't work directly on the pc either, then I guess it is the asic itself... If it works on the PC but not a hub, then it's something with the hub, just as in my case.

I have 11 mld2s, all on one hub. No problems, until yesterday. Now one MLD isn't well recognised by the hub anymore (irrespective of the USB port I put it on): sometimes it does not show up in windows COM drivers (and I get error message 'unrecognised device' or something like that), sometimes it does but it refuses to communicate (the yellow light maybe flashes once but that's it, and it does not show as a MLD device in bfgminer). First I thought the USB chip on the MLD was semi-fried for some strange reason.

Now, when I plug that same device in a USB port directly on my PC (same PC as the hub with the remaining 10 MLDs is connected to), it works fine, it is properly recognized by windows and hashes away just fine. I have tried powering my hub on/off etc, but didn't help. It drives me nuts. So I guess it is something in the hub, but it can then only the hub controller because the power and the individual usb ports are fine by themselves. It's a 19 port Eyeboot hub, I think jstephanop also said that eyeboot hubs are not the greatest (when stretched).

* Are you using external fans?? I could not see it so quickly from your picture. If not, have you measured your ASIC temperatur (small heatsink)?
* Why are you using 4 of these hubs with just 2 MLDs each if you had both a USB2 and a USB3 hub that (I understand from your message) could take all 8 in one go?? (where only the USB3 gives all units at full speed)?
* I have similar issues with running a certain number of MLDs just fine, and adding one or two more one or two units slowing down. It has been suggested it is an issue with USB hub getting 'stuck'. However, I am close to certain that on my hub it is a power issue and it could be that the powerlines in your USB 3 hub are either fatter or differently laid out on the PCB. It maybe takes a small additional voltage drop to cause problems. These babies draw a lot of current. That's my experience. But whatever the cause, I have seen similar things too.

Great stuff. I am running 6 at 924Mhz and another 5 at 832Mhz (for the above reasons; all on one USB3 hub). Getting about the same as you, slightly less. I also have slightly higher hw rates (but then I tuned core voltage down as much as possible to reduce power and heat).

Hey, @jstephanop, you made this awesome stuff! I am running 6 mlds at 924Hz (plus 5 at 824Mhz) all on the same hub, with the pots tweaked down as per your instructions, my HW rate is a little higher, at .9% and my hashrate it a bit lower, at 5.3Mhz/unit, instead of just over 5.4Mh/s as with @dem0nlord. Been running stable without restarts for weeks now. I got (borrowed) an IR temp meter, the 824Mhz MLDs I am running without stockfan and they are at ca 44degC, the 924Mhz I am running with stockfan, and they are about the same.

Fixing the enable/disable would be very useful since I have never been able to detect any logical binding between COM port and MLD#, it seems random.
Also, I have noted that not always is bfgminer able to pick up the MLD serialnumber, or even that it is a MLD connected to a serial port, all fields are empty (windows detects the MLD just fine and assigns a COM port to it, but when bfgminer tries to figure out what is connected to the com port it doesn't get the information that it needs, which is device type and serialnumber). But it will still start hashing it because that's just how the code works. Also that seems to be random, possibly something stuck in the USB hub.

Once one has done a bit of plugging in/out of MLDs into a hub and monitoring the COM ports its easy to follow how com ports are assigned to the USB ports, that helps. Certainly in my case where I have split my 11 MLDs on one hub into two groups (and hence two bfgminer instances). As long as I keep using the same USB ports I know exactly which USB port gets assigned which COM port.

Not sure what you mean by "won't budge past..."? What happens if you set both (or the 2nd only) at 924Mhz? It does not start at all. Have you increased the core voltage? The currentdraw can, when not tuned carefully, be humongeous at those clockspeeds, so the best advice is to increment one step at a time, and see what happens. E.g., both at 796, then both at 800 etc. It could be that your powersupply (in the usb hub) simply can't deliver the current needed.
Tweaking the pot meters to keep the units hashing at desired hashrate AND at the lowest power (=heat) is fun, but not trivial.

1) What happens if you put the 'bad' stick into the usb port where you otherwise have the good stick, and only run one stick. Do you then still see the same problem???
2) Run at the very lowest clock frequency, 384Mhz. Try again. Do you still get the problem?

If 1) solves the problem you have a powersupply issue. It is not always given that you can run 2 MLDs on one PC, it depends on how the ports are powered. (and in any case there is a limit to the powerdraw even on one port, depends on type of PC). Even powered hubs are not very reliable, unless you get the seriously heavy duty ones.

If 1) makes no difference, but 2) solves the problem, yes maybe something isn't right with the pots and you need to turn the one for the MLD with the higher hw rate a bit up (especially if not only the core potmeter).

Good luck!