Bitcoin Forum
December 11, 2016, 08:09:29 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 [72] 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 »
  Print  
Author Topic: Butterfly Labs - Bitforce Single and Mini Rig Box  (Read 176617 times)
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
June 06, 2012, 04:28:22 PM
 #1421

My BFL arrived with 814 firmware instead of 832. Should I be concerned? I've upgraded it and ran it all night at 832 and it seems to run fine. I wonder why it shipped out that way?

All 6 of mine came with 816 firmware

http://dl.dropbox.com/u/3201544/Single.png
Well that's lame. Another guarantee broken; that of the minimum advertised specs.  Roll Eyes
Here's a tip: If the specs aren't up to the minimums, DON'T SHIP IT, send one that actually works.

That being said, will they run the faster ones without issues, JWU42?

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
1481443769
Hero Member
*
Offline Offline

Posts: 1481443769

View Profile Personal Message (Offline)

Ignore
1481443769
Reply with quote  #2

1481443769
Report to moderator
1481443769
Hero Member
*
Offline Offline

Posts: 1481443769

View Profile Personal Message (Offline)

Ignore
1481443769
Reply with quote  #2

1481443769
Report to moderator
1481443769
Hero Member
*
Offline Offline

Posts: 1481443769

View Profile Personal Message (Offline)

Ignore
1481443769
Reply with quote  #2

1481443769
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481443769
Hero Member
*
Offline Offline

Posts: 1481443769

View Profile Personal Message (Offline)

Ignore
1481443769
Reply with quote  #2

1481443769
Report to moderator
1481443769
Hero Member
*
Offline Offline

Posts: 1481443769

View Profile Personal Message (Offline)

Ignore
1481443769
Reply with quote  #2

1481443769
Report to moderator
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
June 06, 2012, 05:03:39 PM
 #1422

My BFL arrived with 814 firmware instead of 832. Should I be concerned? I've upgraded it and ran it all night at 832 and it seems to run fine. I wonder why it shipped out that way?
All 6 of mine came with 816 firmware
Well that's lame. Another guarantee broken; that of the minimum advertised specs.  Roll Eyes
Here's a tip: If the specs aren't up to the minimums, DON'T SHIP IT, send one that actually works.

Not trying to nitpick here, but BFL advertises their specs as 832Mhps +/- 10% running variance. That's a range of 749 to 915 Mhps.

816Mhps is well within 10%. In fact, all of BFL's released firmware to date is within this range.

For my Singles, I have flashed them DOWN to an average of 808Mhps (some run 832 firmware, a few need 768, but most run 800-816 firmware). In my relatively hot environment (typically 27C or 81F), replacing the stock/loud fans with aftermarket/quiet fans, I have found that this is what I need to prevent throttling.

808 sounds like a big decrease from 832, but it is only 3%. Hardly noticeable. Yes I would prefer that they run at 832 ... or 896 for that matter ... but BFL has claimed nothing beyond 832 +/- 10%, so I'm quite satisfied running 808.

As a side-note, if your 832 Singles are throttling and you are considering to flash them down to 816, you should do it only if your unit throttles more than once every 13 minutes. In other words, if it throttles more often than once per 13 minutes, you should flash it down. If it throttles less often than this, you are better off leaving it at 832 if you want to maximize the overall mining rate.

The calculation goes something like this: The throttle cycle is 15 seconds long. During that time the Single is not calculating anything. So you are losing 15 seconds of mining. In 13 minutes, the non-throttling 816 firmware will calculate 816*13*60 megahashes (636M). The 832 firmware, throttling for 15 seconds during that time, will generate 832*12.75*60 megahashes (636M) which is the same amount.

The same calculation can be run for any of the firmware speeds, to determine exactly when a throttling Single should be flashed down to maximize overall speed. Sometimes you will find that it can make sense to let a Single throttle, as long as it doesn't happen too frequently.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Cablez
Legendary
*
Offline Offline

Activity: 1400


I owe my soul to the Bitcoin code...


View Profile
June 06, 2012, 05:11:20 PM
 #1423

That is very good information Epoch, I had come up with something similar for one my throttling 864 units. It is better to leave it at the higher firmware.

I was curious though, what is the reason why the test rates (seen in easyminer) are never achieved when in real use (cgminer in this instance)?  Is this network related as in getting work efficiently?

Tired of substandard power distribution in your ASIC setup???   Chris' Custom Cablez will get you sorted out right!  No job too hard so PM me for a quote
Check my products or ask a question here: https://bitcointalk.org/index.php?topic=74397.0
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
June 06, 2012, 05:44:39 PM
 #1424

That is very good information Epoch, I had come up with something similar for one my throttling 864 units. It is better to leave it at the higher firmware.

I was curious though, what is the reason why the test rates (seen in easyminer) are never achieved when in real use (cgminer in this instance)?  Is this network related as in getting work efficiently?

I believe BFL addressed this question elsewhere. But basically when going through the full nonce range (2^32, of 4 billion hashes), a Single runs at its full speed of 832Mhps. It is able to do this in 5.16 seconds. After that it stops until the mining software give it another work unit. So the question is, how long does it take for the mining software (e.g. cgminer) to give it more work? Well, the miner needs to POLL the USB port to see when the Single is done, it needs to collect any difficulty-1 solutions found (typically 1), then it needs to send the next work. I believe the polling interval in cgminer is on the order of 100ms. The USB link to the Single seems to be only 9600 baud, which will add many more milliseconds to the sending of commands, collecting results, and feeding more work.

Let's assume the average delay between polls is 50ms (100ms polling interval means an average of 50ms delay); we'll assume the additional delay due to sending/receiving/processing commands is negligible. So the Single is running for 5.16 seconds at a speed of 832, then sitting 'idle' for 0.05 seconds. Another way of looking at this is that it takes (5.16+0.05) seconds to run through the entire nonce range. That would give it an effective speed of only 824Mhps, not 832.

This happens to be what cgminer reports for a full-bore 832-firmware Single (my 832-speed Singles are reported as 825 by cgminer). Perhaps my assumptions are a bit off, perhaps the polling interval is faster than 100ms ... maybe it is only 10ms. But then the overhead in transferring the serial commands becomes more significant and we're basically back to the same situation again.

You asked why EasyMiner reports a higher rate than cgminer. This is why. I think you already suspected as much. EasyMiner reports the raw rate only. That is, the rate at which a full 2^32 hash range is calculated at. It does NOT take into account the overhead of polling and command transfer over a longer period. cgminer does take this into account, which is why its reported rate will be lower.

It may be possible for BFL to tweak the firmware such that the next work could be queued in the device before it has completed its current work; that would essentially eliminate the polling delay and allow the device to operate at 100% efficiency. Currently that is not the case; we lose about 1% due to the polling and USB communication overhead.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Cablez
Legendary
*
Offline Offline

Activity: 1400


I owe my soul to the Bitcoin code...


View Profile
June 06, 2012, 06:55:50 PM
 #1425

Thanks Epoch, super succinct as always. Smiley  That was kind of what I had figured. 1% doesn't sound so bad until the timeline gets sufficiently long.

Tired of substandard power distribution in your ASIC setup???   Chris' Custom Cablez will get you sorted out right!  No job too hard so PM me for a quote
Check my products or ask a question here: https://bitcointalk.org/index.php?topic=74397.0
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
June 06, 2012, 07:18:01 PM
 #1426

I believe BFL addressed this question elsewhere. But basically when going through the full nonce range (2^32, of 4 billion hashes), a Single runs at its full speed of 832Mhps. It is able to do this in 5.16 seconds. After that it stops until the mining software give it another work unit. So the question is, how long does it take for the mining software (e.g. cgminer) to give it more work? Well, the miner needs to POLL the USB port to see when the Single is done, it needs to collect any difficulty-1 solutions found (typically 1), then it needs to send the next work. I believe the polling interval in cgminer is on the order of 100ms. The USB link to the Single seems to be only 9600 baud, which will add many more milliseconds to the sending of commands, collecting results, and feeding more work.

Let's assume the average delay between polls is 50ms (100ms polling interval means an average of 50ms delay); we'll assume the additional delay due to sending/receiving/processing commands is negligible. So the Single is running for 5.16 seconds at a speed of 832, then sitting 'idle' for 0.05 seconds. Another way of looking at this is that it takes (5.16+0.05) seconds to run through the entire nonce range. That would give it an effective speed of only 824Mhps, not 832.

This happens to be what cgminer reports for a full-bore 832-firmware Single (my 832-speed Singles are reported as 825 by cgminer). Perhaps my assumptions are a bit off, perhaps the polling interval is faster than 100ms ... maybe it is only 10ms. But then the overhead in transferring the serial commands becomes more significant and we're basically back to the same situation again.

You asked why EasyMiner reports a higher rate than cgminer. This is why. I think you already suspected as much. EasyMiner reports the raw rate only. That is, the rate at which a full 2^32 hash range is calculated at. It does NOT take into account the overhead of polling and command transfer over a longer period. cgminer does take this into account, which is why its reported rate will be lower.

It may be possible for BFL to tweak the firmware such that the next work could be queued in the device before it has completed its current work; that would essentially eliminate the polling delay and allow the device to operate at 100% efficiency. Currently that is not the case; we lose about 1% due to the polling and USB communication overhead.

Hi Epoch,

I had similar estimates in a different thread and did some further digging to get a more solid understanding.

Bottom line is, if the BFLS is not throttling, you will get some long term hash rate of (system clock - 14) MH/s, that is a device with 864MHz firmware will deliver 850MH/s at most. The loss is taken for the communication to/from device. Converting it down based on a nonce time of ~5.2s, the idle time is around 80ms per cycle. That matches the real numbers for cgminer operation, that are:
  • baudrate of 9600 => ~1ms (937.5 us exactly) to read/write a single character
  • submitting work: write ">>>>>>>>[32 bytes midstate][last 12 bytes of block header]>>>>>>>>" => 56ms
  • polling for shares: after work submission, first wait 4.5 seconds, then poll every 10ms by writing "ZFX" => 8ms average delay
  • reading shares: read "NONCE-FOUND:1234ABCD,2468EFAB,1111BBBB" => (11 + #nonces * 9) ms => 18.7ms average

One could maybe implement some pre-fetching of work and caching of nonces functionality to add the potential 12MH/s - but at the same time maybe the FPGAs need this small idle time to cool down a little bit.

despoiler
Member
**
Offline Offline

Activity: 94


View Profile
June 06, 2012, 07:22:51 PM
 #1427

I believe BFL addressed this question elsewhere. But basically when going through the full nonce range (2^32, of 4 billion hashes), a Single runs at its full speed of 832Mhps. It is able to do this in 5.16 seconds. After that it stops until the mining software give it another work unit. So the question is, how long does it take for the mining software (e.g. cgminer) to give it more work? Well, the miner needs to POLL the USB port to see when the Single is done, it needs to collect any difficulty-1 solutions found (typically 1), then it needs to send the next work. I believe the polling interval in cgminer is on the order of 100ms. The USB link to the Single seems to be only 9600 baud, which will add many more milliseconds to the sending of commands, collecting results, and feeding more work.

Let's assume the average delay between polls is 50ms (100ms polling interval means an average of 50ms delay); we'll assume the additional delay due to sending/receiving/processing commands is negligible. So the Single is running for 5.16 seconds at a speed of 832, then sitting 'idle' for 0.05 seconds. Another way of looking at this is that it takes (5.16+0.05) seconds to run through the entire nonce range. That would give it an effective speed of only 824Mhps, not 832.

This happens to be what cgminer reports for a full-bore 832-firmware Single (my 832-speed Singles are reported as 825 by cgminer). Perhaps my assumptions are a bit off, perhaps the polling interval is faster than 100ms ... maybe it is only 10ms. But then the overhead in transferring the serial commands becomes more significant and we're basically back to the same situation again.

You asked why EasyMiner reports a higher rate than cgminer. This is why. I think you already suspected as much. EasyMiner reports the raw rate only. That is, the rate at which a full 2^32 hash range is calculated at. It does NOT take into account the overhead of polling and command transfer over a longer period. cgminer does take this into account, which is why its reported rate will be lower.

It may be possible for BFL to tweak the firmware such that the next work could be queued in the device before it has completed its current work; that would essentially eliminate the polling delay and allow the device to operate at 100% efficiency. Currently that is not the case; we lose about 1% due to the polling and USB communication overhead.

Hi Epoch,

I had similar estimates in a different thread and did some further digging to get a more solid understanding.

Bottom line is, if the BFLS is not throttling, you will get some long term hash rate of (system clock - 14) MH/s, that is a device with 864MHz firmware will deliver 850MH/s at most. The loss is taken for the communication to/from device. Converting it down based on a nonce time of ~5.2s, the idle time is around 80ms per cycle. That matches the real numbers for cgminer operation, that are:
  • baudrate of 9600 => ~1ms (937.5 us exactly) to read/write a single character
  • submitting work: write ">>>>>>>>[32 bytes midstate][last 12 bytes of block header]>>>>>>>>" => 56ms
  • polling for shares: after work submission, first wait 4.5 seconds, then poll every 10ms by writing "ZFX" => 8ms average delay
  • reading shares: read "NONCE-FOUND:1234ABCD,2468EFAB,1111BBBB" => (11 + #nonces * 9) ms => 18.7ms average

One could maybe implement some pre-fetching of work and caching of nonces functionality to add the potential 12MH/s - but at the same time maybe the FPGAs need this small idle time to cool down a little bit.


I get 857 and some change mh/s with the 864 firmware.
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
June 06, 2012, 07:35:28 PM
 #1428

Hi Epoch,

I had similar estimates in a different thread and did some further digging to get a more solid understanding.

Bottom line is, if the BFLS is not throttling, you will get some long term hash rate of (system clock - 14) MH/s, that is a device with 864MHz firmware will deliver 850MH/s at most. The loss is taken for the communication to/from device. Converting it down based on a nonce time of ~5.2s, the idle time is around 80ms per cycle. That matches the real numbers for cgminer operation, that are:
  • baudrate of 9600 => ~1ms (937.5 us exactly) to read/write a single character
  • submitting work: write ">>>>>>>>[32 bytes midstate][last 12 bytes of block header]>>>>>>>>" => 56ms
  • polling for shares: after work submission, first wait 4.5 seconds, then poll every 10ms by writing "ZFX" => 8ms average delay
  • reading shares: read "NONCE-FOUND:1234ABCD,2468EFAB,1111BBBB" => (11 + #nonces * 9) ms => 18.7ms average

One could maybe implement some pre-fetching of work and caching of nonces functionality to add the potential 12MH/s - but at the same time maybe the FPGAs need this small idle time to cool down a little bit.

This is excellent information; thanks, zefir. I see that the actual polling interval is 10ms, but the other overheads brings it up to 80ms. An 80ms overhead per nonce cycle is closer to a 1.5%-2% overhead.

Yes, I also wouldn't worry too much about tweaking this inefficiency out. If a non-throttling 816 unit throttles with 832 firmware (a 2% increase), then that same 816 unit would likely throttle if the 80ms idle time was eliminated.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
BTCurious
Hero Member
*****
Offline Offline

Activity: 714


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
June 06, 2012, 07:45:37 PM
 #1429

One could maybe implement some pre-fetching of work and caching of nonces functionality to add the potential 12MH/s - but at the same time maybe the FPGAs need this small idle time to cool down a little bit.
Yes, I also wouldn't worry too much about tweaking this inefficiency out. If a non-throttling 816 unit throttles with 832 firmware (a 2% increase), then that same 816 unit would likely throttle if the 80ms idle time was eliminated.
On the other hand, there's a number of us who are running 896 in cool environments are getting 883 MHash/sec without throttling. Until BFL releases even faster firmwares, we could benefit from this improvement.

zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
June 06, 2012, 07:52:00 PM
 #1430

I get 857 and some change mh/s with the 864 firmware.

But not long term, or? The values averaged over the last 5s might fluctuate (I even see higher values than clock rate now and then), but if you let the device run for a day or so, the hash rate should settle to the values I gave - at least that's what I see with my Linux driven BFLS.

despoiler
Member
**
Offline Offline

Activity: 94


View Profile
June 06, 2012, 07:53:21 PM
 #1431

I get 857 and some change mh/s with the 864 firmware.

But not long term, or? The values averaged over the last 5s might fluctuate (I even see higher values than clock rate now and then), but if you let the device run for a day or so, the hash rate should settle to the values I gave - at least that's what I see with my Linux driven BFLS.

That is the average over a day +.  The only time the thing comes off of 857 is when the long poll hits from the pool. 
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
June 06, 2012, 08:05:02 PM
 #1432

One could maybe implement some pre-fetching of work and caching of nonces functionality to add the potential 12MH/s - but at the same time maybe the FPGAs need this small idle time to cool down a little bit.
Yes, I also wouldn't worry too much about tweaking this inefficiency out. If a non-throttling 816 unit throttles with 832 firmware (a 2% increase), then that same 816 unit would likely throttle if the 80ms idle time was eliminated.
On the other hand, there's a number of us who are running 896 in cool environments are getting 883 MHash/sec without throttling. Until BFL releases even faster firmwares, we could benefit from this improvement.

The pre-fetch and caching mechanisms has to be implemented by BFL. What can be tweaked SW wise is to reduce the polling time, but this might potentially save only some milliseconds per cycle.

What I am more curious about is the unusually low baud rate used for communication. 9600 Bd was used two decades ago, if we could use today's common rates of 115.2 kBd, that would be a huge improvement potential.

To you Windows folks: could you maybe check if it is possible to change the related COM port settings before you run EasyMiner to e.g. 38.4 kBd 8N1 and check whether they change during and after EasyMiner accessing the BFLS? Thanks.

zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
June 06, 2012, 08:07:25 PM
 #1433

I get 857 and some change mh/s with the 864 firmware.

But not long term, or? The values averaged over the last 5s might fluctuate (I even see higher values than clock rate now and then), but if you let the device run for a day or so, the hash rate should settle to the values I gave - at least that's what I see with my Linux driven BFLS.

That is the average over a day +.  The only time the thing comes off of 857 is when the long poll hits from the pool. 

Are you really sure you flashed the 864 FW? 857 MH/s would otherwise perfectly match 872 MHz. If you're sure, what OS and miner SW are you using?

despoiler
Member
**
Offline Offline

Activity: 94


View Profile
June 06, 2012, 08:13:02 PM
 #1434

I get 857 and some change mh/s with the 864 firmware.

But not long term, or? The values averaged over the last 5s might fluctuate (I even see higher values than clock rate now and then), but if you let the device run for a day or so, the hash rate should settle to the values I gave - at least that's what I see with my Linux driven BFLS.

That is the average over a day +.  The only time the thing comes off of 857 is when the long poll hits from the pool. 

Are you really sure you flashed the 864 FW? 857 MH/s would otherwise perfectly match 872 MHz. If you're sure, what OS and miner SW are you using?

Ill double check when I get home.  I tested all of the faster firmwares that were out at the time my single arrived.  I see they have added even faster ones since I last checked.  I'll post some screen shots if my memory has served me well. 
Cablez
Legendary
*
Offline Offline

Activity: 1400


I owe my soul to the Bitcoin code...


View Profile
June 06, 2012, 08:23:54 PM
 #1435

The pre-fetch and caching mechanisms has to be implemented by BFL. What can be tweaked SW wise is to reduce the polling time, but this might potentially save only some milliseconds per cycle.

What I am more curious about is the unusually low baud rate used for communication. 9600 Bd was used two decades ago, if we could use today's common rates of 115.2 kBd, that would be a huge improvement potential.

To you Windows folks: could you maybe check if it is possible to change the related COM port settings before you run EasyMiner to e.g. 38.4 kBd 8N1 and check whether they change during and after EasyMiner accessing the BFLS? Thanks.

I am able to change the b/s rate in windows to what you specified (38.4 8N1). Started up easyminer and compared the modified one vs a default one and I see no changes.  Is there something else I should check for?

Tired of substandard power distribution in your ASIC setup???   Chris' Custom Cablez will get you sorted out right!  No job too hard so PM me for a quote
Check my products or ask a question here: https://bitcointalk.org/index.php?topic=74397.0
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
June 06, 2012, 08:38:23 PM
 #1436

The pre-fetch and caching mechanisms has to be implemented by BFL. What can be tweaked SW wise is to reduce the polling time, but this might potentially save only some milliseconds per cycle.

What I am more curious about is the unusually low baud rate used for communication. 9600 Bd was used two decades ago, if we could use today's common rates of 115.2 kBd, that would be a huge improvement potential.

To you Windows folks: could you maybe check if it is possible to change the related COM port settings before you run EasyMiner to e.g. 38.4 kBd 8N1 and check whether they change during and after EasyMiner accessing the BFLS? Thanks.

I am able to change the b/s rate in windows to what you specified (38.4 8N1). Started up easyminer and compared the modified one vs a default one and I see no changes.  Is there something else I should check for?
My understanding is that EasyMiner only measures the raw calculation rate (i.e. without any overhead effect), but you might see an increase in cgminer's reported rate if the USB speed has truly increased. Are you able to check that, Cablez?

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Cablez
Legendary
*
Offline Offline

Activity: 1400


I owe my soul to the Bitcoin code...


View Profile
June 06, 2012, 09:07:31 PM
 #1437

Ok, let me change the rate across the board and I will let you know if there is any subtle difference.

Tired of substandard power distribution in your ASIC setup???   Chris' Custom Cablez will get you sorted out right!  No job too hard so PM me for a quote
Check my products or ask a question here: https://bitcointalk.org/index.php?topic=74397.0
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
June 06, 2012, 09:16:12 PM
 #1438

Ok, let me change the rate across the board and I will let you know if there is any subtle difference.
Subtle, yes.  Wink

Let's see ... if the USB rate was increased from 9600 baud to 38400, that would reduce the USB overhead to 1/4 of what it was before. And according to zefir, at 9600 baud it was about 80ms (polling is done at 10ms, which is independent of USB baud rate). So you *should* see an overhead of only ~20ms-25ms now.

That translates to an extra 10Mhps or so (about 1%-1.5%). Not sure if that would be detectable over the typical short-term variance we see reported in cgminer.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
BTCurious
Hero Member
*****
Offline Offline

Activity: 714


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
June 06, 2012, 09:25:44 PM
 #1439

Ok, let me change the rate across the board and I will let you know if there is any subtle difference.
Subtle, yes.  Wink

Let's see ... if the USB rate was increased from 9600 baud to 38400, that would reduce the USB overhead to 1/4 of what it was before. And according to zefir, at 9600 baud it was about 80ms (polling is done at 10ms, which is independent of USB baud rate). So you *should* see an overhead of only ~20ms-25ms now.

That translates to an extra 10Mhps or so (about 1%-1.5%). Not sure if that would be detectable over the typical short-term variance we see reported in cgminer.
It should be very easily detectable on a single that doesn't throttle. Your U value would jump up 0.14/m.

Edit: Of course the difference won't happen on a throttling single; it will just throttle more often now.

Cablez
Legendary
*
Offline Offline

Activity: 1400


I owe my soul to the Bitcoin code...


View Profile
June 06, 2012, 09:35:30 PM
 #1440

To tell the truth it is still to early to be definitive but so far I do see some better than average U values now.  Time will tell if its real.

Tired of substandard power distribution in your ASIC setup???   Chris' Custom Cablez will get you sorted out right!  No job too hard so PM me for a quote
Check my products or ask a question here: https://bitcointalk.org/index.php?topic=74397.0
Pages: « 1 ... 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 [72] 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!