|
If anything (and it's propably too early to say) the update made my slow-cored unit worse. As I am typing this in CM0 has 44 shares and CM1 has 2, neither shows rejects. The core used to be able to push out roughly one tenth of the first cores shares. But like I said it's too early to say, I will fill in more credible numbers in some hours.
[edit]
453/16 shares 1/0 rejects, no hardware errors.
1000/35 shares 2/0 rejects, no harware errors.
So in my case this made no difference whatsoever.
[edit2]
2485/77 shares 4/0 rejects, no harware errors.
... and now on to the interesting part, I will now chuck all the boards to work in the same Cgminer instance, to demonstrate how the slow core will start producing more shares, or as I believe it to be CGminer reporting shares to wrong cores.
|
|
|
|
|
When trying everything I can think of to resolve the slow core issue I've been having it has become almost obvious that Im dealing with a defective unit. Board 62-0158 the second core works over 10x slower that the other one, not reported speed, but shares and rejects.
Things I have done to reach this conclusion are:
Reflashing the bitstream multiple times
Powering off the pc and/or unit
Running the board in a usb2 port, usb3 port and in both ports with an unpowered usb hub.
Setting up a different system for testing (win 7 x64 and windows 95 were used)
Run the boards in separate cgminer instances.
It would appear the problematic core gets more shares when more boards are plugged in, so this might suggest that the cgminer build is reporting shares to incorrect cores at times.. and if that is the case then I suppose a single core can function alone, like someone asked a few pages back.
|
|
|
|
One thing we have found is that a small percentage of the USB cables we supply have been faulty and may explain a few of the coms failures. We are changing our testing to include the cable that ships with the unit rather than assuming the externally supplied cable is ok. Some of you may have faulty USB cables and if possible you should try problem units with a different cable. On USB hubs we just got a few USB hubs for our test setup and also so that we can start to put together a recommended list. Some of the cheaper ones do have an inadequate power supply e.g. 1A for 10 ports. However one that we do have http://www.ebuyer.com/123772-d-link-dub-h7-usb2-0-7-port-hub-dub-h7-b looks very good on paper and I will update you on real use of this particular hub when we do some testing. Thank you on this bit, I will go trough any available cables I have and see if this could be the case for me and my slow-core issue. [edit] First results are inconsistent, I dubbed the cables 1,2&3. 1,2&3 plugged has a slow core. 1,2 plugged has a slow core. 1,3 plugged works fine. 2,3 plugged has a slow core. Adding a random similiar usb cable to the mix (4) 1,3,4 has a slow core. |
|
|
|
|
After a permanent flas of the twin_test bitstream and plugging all 3 of my boards in to separate usb 3 ports my. Last core on cgminer is slow problem still persists.
|
|
|
|
|
The problem with me having one core working much slower that the other ones is back.
I am running 3 boards with an unpowered usb-hub at an usb3 port (the boards do not even detect correctly in regular usb ports). Running the twin_test bitstream, with the correct dipswich positions used while flashing and operating, as indicated in your pdf. The miner I am using is yor cgminer_twintest.exe I am starting it with the command cgminer_twintest -o mint.bitminter.com:8332 -u USR -p PASS --disable-gpu -S noauto -S\\.\COM22 -S \\.\COM23 -S \\.\COM26 -S \\.\COM27 -S \\.\COM30 -S \\.\COM31
Any other relevant information that would help identifying this, just ask.
|
|
|
|
xc3sprog –c cm1 –p 0 –Ixc6lx150.bit twin_test.bit does not work, but this time it's complaning about a filename issue to me. My initial hunch is that since the board im punishing is #108 the firmware filename on it has changed along the way. I'll re-read up on this , of how I wsh the search function on this forum worked better  .. but for now Im going with the temporary flash. Strange... When you type a "ls -l" do you see the files in the directory? And make sure you use the correct filename, the filename in UPPERCASE is XC6LX150.bit, I did a typo the first times, so I used xc61 (number one here! but it is a small "L")... Here is my directory (ls -l) after copy the files from usb stick:  If you have the same, the commandline should work. good luck!
Recieved clarification on this, thank you Slipbye ...flashing in progress nowI decided to get back to permanently flashing my boards, my problem appears to be that the file xc6lx150.bit is not there, am I correct in assuming that copying it in there with the usb stick will result in success ? ...and does this mean that the virtual machine requires the bitstream that will be removed as a "reference point" so it can permanentley flash in a new one ? |
|
|
|
I am now testing the bitminter beta java client with all 3 of my boards, with the twin_test bitstream. I made a separate worker for it. Hopefully I'll hav something nice to report later on.
Tons of errors and the test ending in one board dissapearing and requiring a reflash, i dumped the log to drharibo, but I doubt it will be usefull to him before enterpoint rolls out a reliable bitstream. |
|
|
|
|
I am now testing the bitminter beta java client with all 3 of my boards, with the twin_test bitstream. I made a separate worker for it. Hopefully I'll hav something nice to report later on.
|
|
|
|
shares are 2^32 hashes
13154 shares in 14 hrs is 1121MH/s
However, 14 hours is not long enough to ensure the number of shares is exactly the same as the hash rate.
Maybe give it a few days at least if you want to use the number to be close to correct.
(also you need to measure the time accurately as I'm sure it wasn't exactly 14hrs, and even 1 minute is 0.12%)
My intention was to have a look at rough numbers at this point, thank you for the math. Im not that interested at getting an accurate performance figure, while the boards are at best crippled to less than half they should eventually be able to provide. |
|
|
|
Are you running the correct version of CGminer?
When you flashed the units dip you have the dip switches in the correct position for flashing and then afterwards set them to running position for the twin bitstream?
I tought I was, somewhere along the line I had for some reason started the wrong one... Im running the correct one now, I'll report in when I have enough data, I think around 1000shares per core should be definite ? And yes I have been playing with the dipswitches in accordance to your pictures. Ok after 14 hours (a bit less tbh, but it's like 10min) of running 3 boards in the correct cgminer, at a regular pool, with the twin_test bitstream: The pool side shows my current hashing speed to be: 1146Mhs (This is supposedly a 10 or so minute average), I have accumulated 13151 valid shares and 3 invalids. Cgminer shows: all cores running and hashing at roughly equal speeds (the slow core was caused by the incorrect miner version) 13300 shares 3 rejected shares. Could someone smarter than me do the math on 13154 shares in 14 hours: whats the average hashing speed ? |
|
|
|
I've got my board working for the most, the weird issue I'm having is that once each core has hashed about 1000-1100 shares, they will both display "OFF" in CGMiner 2.4.1 standard build. Windows doesn't see the Cairnsmore device anymore and I usually have to power cycle the unit and then restart the computer for it to redetect. Any idea what might be wrong?
Windows 7 x64
I've had this happen once, with 1/3 boards. Got no leads as in to what it's related. |
|
|
|
Are you running the correct version of CGminer?
When you flashed the units dip you have the dip switches in the correct position for flashing and then afterwards set them to running position for the twin bitstream?
I tought I was, somewhere along the line I had for some reason started the wrong one... Im running the correct one now, I'll report in when I have enough data, I think around 1000shares per core should be definite ? And yes I have been playing with the dipswitches in accordance to your pictures. |
|
|
|
|
62-0108, 62-0158 and 62-0159. Windows 7. But I believe I have hardware issues ruled out, because plugging in the 2 boards that function only yields the same problem.
|
|
|
|
|
This is the weirdest thing: When starting a cgminer copy with only two boards Im having the same issue, again it's the last core thats slacking off and the core that has been troublesome so far is not in there.
[edit]
I'd like to hear from user(s) running multiple boards on windows 7, do you have the same issue in cgminer, the last core is signifigantly slower that the others ?
|
|
|
|
Under Ubuntu im using different instances of cgminer, one for GPU and one for the cairnmore without problems.
Hpman
Thank you, proceeding to that.. the issue had nothing to do with the pool, same problems persist on P2pool. So I guess it could have something to do with getwork protocols. |
|
|
|
That thing is so sexy, you could still consider adding leds to the support structures, blinking at shares found so it'll cause epileptic seizures.
Did reprogramming p 0 or p 3 target solve the issue with your cairnsmore which hashs on different speed on the two serial ports ? If you can confirm this then it looks that the twin_test bitstreams doesn't need another core. Reflashing does not appear to of have worked, neither has moving the board to it's own usb3-port. Im starting to wonder if I have a defective one. it's pushing one tenth of the shares of the other cores atm. When tested individually at a regular pool after the re-flash it kept jammering about the pool not providing work fast enough (my gpu miners report nothing of such at the same time at the same pool). On p2pool it appeared to work for some reason, so Im guessing the rapid longpolls have something to do with this. The board reported in at 365MH/s on the 10 minute mark at p2pool. I am now going to double check this by pointing all 3 boards to p2pool in the same worker... and if that reveals nothing then Im propably going to see how they behave in induvidual cgminer instances, does anyone have experience of running multiple cgminer copy's on the same system ? |
|
|
|
|
That thing is so sexy, you could still consider adding leds to the support structures, blinking at shares found so it'll cause epileptic seizures.
|
|
|
|
|
I would start trying with the eldentyrell bitstream, but after 30 minutes of reading I still dont have a clue how to even start he's miner on a windows machine.
[edit]
After some more research it has become clear that the jtag cable is required.
And after messaging Yohan I now know that enterpoint wont bother looking at this bitstream for a couple of days. Also both Enterpoint and elldentyrell are saying they need information on oneandother and either is imo bothering to communicate with oneandother.
|
|
|
|
As an experiment try taking out one or two of the board returning good results and see if that changes anything. Unpowered hubs do have some problems as any current taken will multiply up with the number of boards. It doesn't take much to overload an unpowered hub. Powered hubs are definately better and I would suggest this as a good thing to use for the short term
One other general issue with USB is that the way it timeslots data can mean that the USB can run out bandwidth on relatively low bandwidth applications e.g. serial coms with a relatively small number of boards. I would be surprised if 5 boards caused this issue but I am not an expert in USB protocol so I can't be more specific. It can be worth spreading your boards aroung your PCs ports. This isn't always a solution as an occasional PC has an internal hub for multiple ports which only actually has one USB controller but for most PCs this is a good way forward. Once we get the up/down function sorted out these potential USB problems should more or less dissappear.
Ok, I will try this a bit later, once I figure out which board it is, Would you care to comment on why the boards only work in usb3 ports for me ? |
|
|
|
surely this core has frozen. if you quit cgminer and try to re-execute the same comand. You'll get a COM error in that port..
If any core gets frozen, accepts stop raising too (in that core) and average hasing speed decrease
please answer with your feedback
No, it's not frozen, it keeps on hashing, just at the very low rate. It's been like this since the beginning. |
|
|
|
|
Show Posts
