At the end of the day it's just your paranoid (delusional?) opinon that they took your code, changed it then submitted it themselves.

Since all this code is GPL, would the easier solution for them not simply be submit your commit, which would involve almost zero effort, rather then re-arrange your code? What is to gain? What's their motive?

A bit like taking some header files and removing the author/copywrite info?

Maybe Kano is just better than you then?

There were a number of bug reports posted here in this thread pointing to libcurl being the source of locking up. Shortly after that, the fix was made. It's not a giant leap to assume that, in fact, they solved the problem.

Get over it Luke.

Simple problems are going be solved in the same simple way. There's nothing novel or unique about the code you write. It's all straight forward and intuitive.

Neither of these two examples have the same, copied solution. They were both solved independently in similar ways as they are both soving the same problem. It's no suprise the timing is also similar as these issue are being found at the same time.

You are not a coding god. Anyone can come up with the same ideas as you.

I don't recall every seeing a 'busy', but then I've not looked for it.
I'll have another poke around...

15.3355, in fact

Also, I started adding the temp to the log when a unit throttles...
I'm thinking about adding code with slows the unit a bit as it reaches it's individual throttle temp. Like waiting 500ms before sending new work or something. Maybe. Dunno.

I've done that, get the following:

ID: BFL0   Dev Max: 0.024049   Dev Min: 0.000366   Dev Av: 0.009301
ID: BFL1   Dev Max: 15.335547   Dev Min: 0.000389   Dev Av: 0.012155
ID: BFL2   Dev Max: 15.335506   Dev Min: 3.8E-5   Dev Av: 0.011484
ID: BFL3   Dev Max: 15.33545   Dev Min: 0.00036   Dev Av: 0.027547
ID: BFL4   Dev Max: 0.02345   Dev Min: 0.00036   Dev Av: 0.009153
ID: BFL5   Dev Max: 0.023163   Dev Min: 0.000404   Dev Av: 0.008941

So I put get times immedately before and after the serial port read function inside BFgets.
Dev max is (surpisingly) the max time a read took
Dev min is (surpisingly) the min time a read took
Dev av is (surpisingly) the overall average, that is all the read times summed, then divided my the read count.

So it's pretty apparent that when the single throttles, comms just stop.

It was a withdrawal.
I'm just using Dwollar now. Only used the bankwire as my gox account han't been verified yet.

Sumitomo Bank took $40 off a $400 transfer :/
It was to a US HSBC account too.
And it took nearly 3 weeks.

If I had the time/could be bothered I'd put timers around each of the send/receive and find the max/min/avg values. But that ain't gonna happen in the next week or so.
3s is arbitary. So is 3s for the watchdog, 5s for the stats interval, and any number of other time selections cgminer is littered with. Where did your 100ms come from? Careful analysis?
3s was just a suggestion, and no it won't catch everything. No value apart from infinite will, then we run into other troubles. But we can try mitigating problems, no?

Anway, 2.5.0 is running rock solid for me, so I'm sticking to that for now.

In that case cgminer needed to wait 1s for the temp result to return.
Instead it timed out, leaving the 'get temp' command in the BFL input buffer
Next the get results command was sent to the BFL and the repsonse read... which was from the previous 'get temp' command.
From then on all the responses were out of sync until the read buffer was cleared.

I'd suggest 2 things:
1) Increase the timeout to, say, 3s.
2) Have command re-read the port if they get an unxpected reply. Maybe re-read up to 3 times before giving up.

I got one. I use it

Sooooooooooo behind the times...

I am Sparti... Atlas.

Giga's jelly

Nice one dude

Maybe has an 8-phase PSU.

When you generate an address, how long is it valid for?
I notice it disappears after it's used, but can it still be funded?