Most pool can queried for 120 getworks at a time, noticeably the ecoinpool variant. With other new systems like Stratum with aims to solve any other potential problem and future proofing the network.
In addition, like I have previously stated, Avalon will be releasing our image.iso for the controller sometime in December this will include documentation on how our ASIC will communicate with mining softwares and pools. we will also be providing patches to opensource miners like CGminer.
With that said, we are aware of this bandwidth concern and do not deem it to be a problem at the moment.
Regarding cgminer ...
Well firstly, to use the correct term - we accept git pull requests - just like bitcoin
Secondly, cgminer already supports roll-ntime, vardiff shares and Stratum.
GBT is in development and already working. It will probably be in the next release.
Getwork with roll-ntime can still support over 500GH/s in cgminer per single getwork for 2 minutes.
Higher diff shares is dependent on the pool - all 3 protocols (Getwork, Stratum and GBT) allow it.
GBT currently requires more bandwidth than Getwork and will well beyond 500GH/s
Anyway, those are really pool issues, not miner issues (since cgminer already supports 2 and will support all 3 of them shortly)
From a hardware point of view (as I've mentioned before) as long as it doesn't require polling, first generation ASIC shouldn't present a problem.
At 60GH/s it will be returning ~14 shares a second which of course should be fine over Serial/USB.
10 such devices should easily be OK also.
Feel free to work out how many you can go with Serial on USB
As mentioned above, as long as the pool supports high difficulty shares, that wont be an issue since the pool should be targeting getting a share every few seconds (or less) with it's difficulty adjustment.
Icarus didn't have polling so I don't expect Avalon to have it either.
The only mandatory thing required for ASIC missing from Icarus was a completion message
Temperature reporting is really a must and clock control is definitely an advantage, if available, since people use their devices in many different conditions and catering to the worst is bad for those who have the best environments.
Thirdly, hardware is required for proper support.
If you are going to support all the cgminer requests regarding your changes then that covers one part of it, but if we start getting support requests regarding the software and have no hardware to run it on, then at least some of those support requests are just going to be sent to you.
Every time changes go into cgminer, if we have no hardware to test the changes we can of course not be sure of the effect of those changes on different hardware.
Rarely will it be an issue, but when it is an issue, if we have no hardware, the answer is: well that's unfortunate.
I am stating the obvious, but I thought I better say it here anyway.
Now as most people already know: both BFL and bASIC are sending devs (us and others) hardware to get it working in time for release
(BFL has also stated they are flying me to the USA and
yochdog across the USA to see their manufacturing and report to the community)
You seem to want to do the software yourself, but just realise that you may also end up being the ones to support it if only you have the hardware ...
--
And aside to others ... regarding chip count, ngzhang said here 15~30
https://bitcointalk.org/index.php?topic=110090.msg1198669#msg1198669--
EMS has been excellent sending to me in Australia from central China, Hong Kong and the USA.
