I just have a brilliant idea... How about an old washing machine, top loader ?  |
|
|
|
Not sure why Mt Gox is redirecting from mtgox.com to mtgox.net with a picture of the page.... Not sure why that makes you think this is a scam, as that's just stupid design on Mt Gox's part.
What ?! mtgox.com redirects to https://mtgox.com and not mtgox.net ! |
|
|
|
|
This is what is happening:
You have a few receiving transactions in April, amongst them, one for 3.9995
Then you starting spending in May and June. I'll get to the two in July in a moment.
Look closely at your spending transactions. Do you notice that some of them go to two addresses ?
One of the two addresses is the destination address, the other is an alias for YOUR wallet !
When you spent BTC, your wallet software uses an algoritm to find an incoming transaction result that matches the amount you are spending. If it can't find one, it will use a higher amount transaction result and returns the change back to you via that alias address.
Now look at your last transaction. You spent 1 BTC, and got 2.9995 returned to your wallet !
So your main wallet address shows 0.00 BTC, but if you add up all your alias addresses amounts, you'll get to 3.9995 BTC and that's what is showing on bitcoin-qt.
So, all is good, no worries, your BTC are still yours.
If you want to know more about this, there is plenty of explanation on the net.
|
|
|
|
Yes it was up to date last night when I checked it was up to date and showing I still had 3.995 bitcoins in my wallet. I checked block chain out of curiosity and then saw this now I am panicking  Ok, like I said, relax! Next message ... |
|
|
|
|
Is your Bitcoin-QT up-to-date with downloading information from the network ? In other words, Is there a green check marker (V shape) in the lower right ?
Yes? Then relax, confirm and I'll explain in the next message.
|
|
|
|
|
Are you calculating your HW% with diff1shares or with the number of shares you have with difficulty 8 ?
The correct formula to calculate HW% (with cgminer fieldnames) is: 100 * HW / (diff1shares + HW)
|
|
|
|
You can put it onto --avalon-auto and it will sort out the freq automagicly by looking at the % of hardware errors. Air cooled systems run at 365 MHz here, water cooled should go up to 400+ (450 MHz max)
Would it be enough to enter that into the "More Options(Default: --quiet)" field in the GUI? Yes. |
|
|
|
Still having problems on one of my Avalon boxes. I've updated the firmware, disabled Wi-Fi, fuse is not present, ran at minimum 256 MHz, checked cables, and it still stops after mining for just a couple of minutes. Hash rate goes all over the place too. It eventually drops to zero and the LED stays yellow.
Any suggestions?
Try with only wifi, I had similar issue with one box, till I changed it to wifi with manual ip address and deleted lan. But be careful, delete your lan after you're sure that wifi works flawless. |
|
|
|
Regarding interrupts, GIE isn't disabled when handling an interrupt, so interrupts can be interrupted. But if I do set GIE=0 then that causes enough disruption to the USB stack in terms of timing delays while waiting for the servicing that is chokes and disconnects. I'm not worried now as I have solved that sufficiently that it no longer disconnects and the result capture hasn't so far had overruns related to not being service quickly enough.
Great! |
|
|
|
Originally I had disabled the USB interrupts during result capture (32 bits, 4 bytes, 8uS/byte) as I wanted to ensure that nothing disturbed that. That was unacceptable to the USB stack as presumably it has to react to bus hardware conditions. After I removed that code the disconnects stopped but I feared the results would overrun if the USB stack took too much time. That doesn't appear to be an issue. I had the UART interrupt handling one byte but now have modified it to handle both bytes the PIC could have in it's FIFO before letting go. So as long as the USB doesn't take >16uS right in the middle of a result nonce it won't overrun, and if it does then it gets detected and counted. So far I've not seen any counted overruns so it seems to not be the reason for HW errors, which do occur still sometimes.
Looking at a screen shot on the forums for a USB Erupter running under cgminer it indicated around 10% HW errors, so I wonder if higher HW errors is normal compared to GPU mining where I can go for weeks with no HW errors. If Avalons typically run with HW errors then I'm maybe wasting my time trying to get it down to GPU levels? Any input from Avalon owners about typical HW error counts?
My 3 module Avalons vary between 1.1% and 2.2% HW according to formula of CK: 100 * HW / (diff1shares + HW) I am not trying to be smart, just trying to help with my common sense (and a long gone history of assembly hacking)  I had a quick look at the PIC16(L)F1454/5/9 preliminary data sheet, focussing on interrupts. If I understand correctly, an interrupt occurs, it does automatic context saving, it jumps to the interrupt service routine(ISR) and there you need to determine the source of the interrupt by polling the interrupt flag bits, handle the interrupt, reset the global interrupt enable bit(GIE) and return from interrupt(RETFIE) which restores the context. If a new interrupt is pending, it will be handled after one instruction has been executed after returning from the interrupt. Maybe your 'unacceptable to the USB stack' was caused by the fact that a second interrupt became pending while you were still handling the first interrupt ? |
|
|
|
Is there anyone, anything, human or not that can tell me how this suspected miner works? Is there built in Ethernet? USB? These are lots of normal questions even BFL was able to answer without a prototype. I want to be able to manage my fathers miner remotely and have yet to find out what kind of connections are on them.
Teamviewer to the PC of your father, from there connect to the miner over ethernet. Can also be done directly, but KISS. |
|
|
|
It was an issue with interrupt handling in the PIC. But the solution creates a timing sensitive condition where I've had to make the USB have priority and this could cause result bytes to be misread. I'm looking for a way to handle this now. Result bytes need to be handled in < 8uS and originally I had this block all interrupts to catch them (32uS blackout), but this is enough to throw the USB into fits, so I need a way they can co-operate but guarantee the result bytes get moved.
I guess your problem is blocking of interrupts while handling an interrupt. Are you taking too much time to handle an interrupt ? Can you create a low-level assembly interrupt routine that only gets one byte of data, stores it in a circular buffer and returns again ? This low level routine can then handle both usb and result bytes input. Higher level routines can then poll for data in the circular buffer. |
|
|
|
I received my Avalon boxes today, but one of them has severe problems:
All of them hash just fine at 300 MHz, but one of them only works if I set it to 256 (but still problems).
When it starts hashing, it will climb to about 66 GH, but then resets every 1-5 minutes, sometimes resets even quicker.
This box had an older firmware on it than my other ones. It had 3.1.1 instead of 3.2.1 (I think).
The temperatures seem to be pretty normal. But it just resets a lot. Sometimes it will not start again even if I stop and start the service, and I have to power off and on again.
What are some things I can do to troubleshoot the issues with this box?
Read this thread from begin to end, it has plenty of suggestions. |
|
|
|
Heb zojuist een transactie gedaan.
Eerst uiteraard BTC -> FBTC. Na drie confirmations stond het op FBTC.
Vervolgens BTC verkocht tegen hoogste bod. Ging allemaal prima.
Nu € opname ingegeven, eens kijken hoe lang dat duurt.
Nog een suggestie: Ik zou graag emails ontvangen van alle gebeurtenissen op mijn account, ook uit oogpunt van veiligheid.
Wellicht kan dit als optie toegevoegd worden, ik vermoed namelijk dat niet iedereen dit wil ?
Even een aanvulling: Om 15:30u ontving ik het mailtje dat mijn verzoek tot overboeken van de € opbrengst van de verkoop naar bankrekening was uitgevoerd. Ik kan niet zien hoe laat het geld op mijn rekening stond, maar het was in ieder geval dezelfde valutadatum. Eindoordeel: OK. FBTC doet wat het beloofd en doet het binnen een (werk?)dag. Uiteraard zijn ze afhankelijk van de snelheid jouw bank, maar dat is logisch. |
|
|
|
Hardware error percentage is:
100 * HW / (diff1shares + HW)
Friendly suggestion: Is it possible to add this percentage to the cgminer web page to make it easier for us ? |
|
|
|
however, initially it was streaming thru pages of hashes w/o problem but now has slowed to a crawl. some memory buffer or something must be filling up.
Is it possible that your disk is near its capacity because of the huge logfile ? |
|
|
|
|
Firmware 20130702-1
Strange effect on a silver Avalon. I noticed that fan3 is running at 1200 rpm, while the others are well over 3000.
Frequency:299 Fan1:3360 fan2:3600 fan3:1200 temp1:30 temp2:-1 temp3:49
I guess fan3 is weaker than the other two.
So I did a little experiment and partly covered the intake of fan3.
Result ? Better cooling and higher Mhz!
Frequency:299 Fan1:3360 Fan2:3600 Fan3:2280 temp1:29 temp2:-1 temp3:47
and later:
Frequency:317 Fan1:3360 Fan2:3600 Fan3:2280 Temp1:29 Temp2:-1 Temp3:48
Ambient also went down 1 degree. Seems odd that partly blocking intake of Fan3 lowers the ambient temp.
Probably due to location of sensor.
Food for thought: Monitor fan speeds and maybe lower speed of fan1 & 2 when fan3 starts slowing down ?
|
|
|
|
Yeah, I saw that too, that's why I am wondering whether or not we need a heatsink. |
|
|
|
|
Show Posts
