[Sorry, beim Preis gewinnt tatsächlich der BFL.. hatte da was anderes im Kopf... BFL: 832Mh : $599 = 1.38Mh/$ ZTex : 860 : $859 = 1.00Mh/$ Beim Verbrauch jedoch.... BFL : 832Mh : 80W = 10,4Mh/W Ztex : 860Mh :39W = 22,0Mh/W Da ist ganz klar der Ztex überragend... Also.. gebe dir zum Teil Recht, aber was die Leistung angeht ist der ZTEX weiterhin performanter  Sorry Nachtwind, muss dich wieder enttäuschen! Ich habe 8 BFL-Singels und alle laufen zwischen 865 und 875 MH, je nachdem auf welchem Pool sie laufen!  Aber um das Thema gehts ja auch gar nicht in diesem Thread, oder? bin von den Werten im Wiki ausgegangen, habe selber keine BFLs hier.. aber stimmt, darum gehts nicht. |
|
|
|
Leider halten sich aber derartig falsche Werte in den Köpfen der Leute, weswegen viele immernoch glauben,dass BFL "besser" ist als andere Mit den FPGA´s sind sie´s aber. Oder zeig mir einen anderen Hersteller, der auf drei Jahr kalkuliert, ein besseres Ergebnis liefert.  Nein, mit den FPGAs sind sie es eben nicht. Dort sind sie nicht einmal halb so performant wie ZTEX FPGAs (oder jeder Spartan6-150 aufbau), wenn es um Mh/J /Mh/Eur angeht... Du behauptest also, die anderen Hersteller sind "besser" als die 1.75 Mh/Eur von BFL? Ist nun dein oder mein Rechner defekt? Sorry, beim Preis gewinnt tatsächlich der BFL.. hatte da was anderes im Kopf... BFL: 832Mh : $599 = 1.38Mh/$ ZTex : 860 : $859 = 1.00Mh/$ Beim Verbrauch jedoch.... BFL : 832Mh : 80W = 10,4Mh/W Ztex : 860Mh :39W = 22,0Mh/W Da ist ganz klar der Ztex überragend... Also.. gebe dir zum Teil Recht, aber was die Leistung angeht ist der ZTEX weiterhin performanter |
|
|
|
Kann mir bitte jemand bei der Quelle suchen helfen ,
bin mir ziemlich sicher das ich irgendwo gelesen habe das sich die Difficulty nur verdoppeln kann, anhand des momentanen Codes.
Kann mich jetzt komplett irren, aber ich meine im source gesehen zu haben, dass es keine Beschränkung nach oben hin gibt - das würde ja auch die Zeitspanne für das erreichen der 21mio coins verändern.. wäre also eigentlich gegensätzlich zur Idee des Diff Systems. Bei SolidCoin2 war es aber so, dass die diff maximal verdoppelt werden konnte, aber unbegrenzt abstürzen konnte - das hat sich damals das "Dick Botnet" zu nutze gemacht indem es die Diff manipuliert hat... |
|
|
|
Leider halten sich aber derartig falsche Werte in den Köpfen der Leute, weswegen viele immernoch glauben,dass BFL "besser" ist als andere Mit den FPGA´s sind sie´s aber. Oder zeig mir einen anderen Hersteller, der auf drei Jahr kalkuliert, ein besseres Ergebnis liefert. Nein, mit den FPGAs sind sie es eben nicht. Dort sind sie nicht einmal halb so performant wie ZTEX FPGAs (oder jeder Spartan6-150 aufbau), wenn es um Mh/J /Mh/Eur angeht... |
|
|
|
Nur mal an die vorrechner.. BFL hat sich in Vergangenheiut mit bekannter Hardware um knapp 400% in ihren Stromanforderungen vertan.. rechnet euch die Welt besser mal nicht zu rosarot..
Der Schneider von Ulm ist gestorben, Otto Lilienthal auch, das mit den Flugzeugen wird wohl nicht funktionieren ... aber ja, BFL hat sich gewaltig vertan beim Strombedarf ermitteln aber was soll das bitte heißen? Der Möglichkeiten gäbe es da viele: *Es wurde irgendein Maximalwert aus der Altera-Literatur genommen die von einer weitaus ineffizienteren Bausteinnutzung ausgeht, *die Tools waren fehlerhaft und BFL hat den falsch ermittelten Wert 'ohne Praxiswissen' so weitergegeben *die Simulation wurde nur oberflächlich mit einem viel zu geringen Anteil der jeweils schaltenden Transistoren ausgeführt *der Wert wurde anhand der Kühlleistung eines zu erwerbenden günstigen Leistungskühlkörper 'vorgegeben solange Du weder hier noch da über die Qualität der Computersimulationen eine Aussage machen kannst ist Deine Annahme 'die werden schon gehörig falsch liegen mindestens von der selben Qualität wie die berühmt-berüchtigte BFL-Simulation. Man könnte ja auch argumentieren, dass BFL schon in der Vergangenheit versucht hat mit schöngerechneten Werten mehr zu verkaufen.. aber das ist Spekulation. Leider halten sich aber derartig falsche Werte in den Köpfen der Leute, weswegen viele immernoch glauben,dass BFL "besser" ist als andere. Mein Argument oben war eher "Rechnet mal nicht mit den Werten einer Firma, die selbst bei bekannten Bauteilen 400% daneben lag, wer weis ob sie es diesmal genauer hinbekommen haben." |
|
|
|
|
Good luck..
If those ASICs ever come 60GH wont be worth anything. So go for a pool.
|
|
|
|
|
Nur mal an die vorrechner.. BFL hat sich in Vergangenheiut mit bekannter Hardware um knapp 400% in ihren Stromanforderungen vertan.. rechnet euch die Welt besser mal nicht zu rosarot..
|
|
|
|
|
dann geh mal mit der Geschwindigkeit runter..
|
|
|
|
Andererseits lässt sich die entwicklung bestimmt am PC Simulieren und dann mit sicherheit mit neuster Technik auch 1 zu 1 umsetzten in der Fabrik.
Das kann ich so nicht unterschreiben.. jedenfalls ist mir nichts derartiges geläufig, aber ich habe auch nur sehr wenig mit Chipherstellung zu tun. |
|
|
|
|
VIEL ist da auch nicht dran. Es geht eigentlich nur um das Kapital und ob hier jemand bereit ist mehrere Millionen in den Sand zu setzen glaube ich eher nicht.
Die günstigste Variante, die es zur zeit gäbe wäre Hardcopies herzustellen, also FPGAs bei entsprechenden Firmen festverdrahten zu lassen und so sehr effiziente Chips herzustellen (4-5GH pro Chip?) Aber auch das würde noch einige 100.000Eur kosten..
Ein kompletter ASIC mit allen Stufen der Qualitätssicherung kostet mehr als das 30x davon...
Das ist leider nichts, was man im Bastelkeller zusammenbaut. Hinzu kommt ja auch das testen. Mich stört es, dass keine "Firma" bisher irgendwas zur Qualität der Chips gesagt hat. Man gibt ja sicher nicht für einige hunder tausend Euro/Dollar Chips in Auftrag ohne vorher an einer (zugegeben teuren) kleineren Charge mal zu testen OB die Chips funktionieren.
Hätte DAS auch nur eine der "Firmen" getan, dann gäbe es verlässliche Specs und selbst die Fehlen.. Und an der Stelle braucht auhc keiner von Geheimhaltung reden: Fakt ist doch, dass die erste Firma die tatsächliche Werte angibt, die auch nachprüfbar und haltbar wären, die hätte einen riesen Vertrauensgewinn und damit Vorbestellungen zu erwarten..
Aber da es das gibt nehme ich persönlich nicht an, dass auch nru eine "Firma" irgendwas soweit fertig hat, dass es überhaupt zu testen ist... geschweigedenn lieferbar in 10 Tagen, denn wie wollen die zB Kühlung und Strombedarf feststellen? Lässt sich zwar errechnen.. aber bisher habe ich nie gesehen, dass berechnungen und realität zusammenpassten (egal wo)..
|
|
|
|
Avalon steht doch kurz vor der Lieferung von 30 Terrahash wenn ich das richtig gelesen habe ?
In wenigen Tagen erhalten Sie ihre Chips dazu ...
..aber es existiert auch hier weiterhin kein funktionierender Prototyp oder ein Demosystem. Auch glaube ich nicht, dass man in der Sekunde Anfängt auszuliefern, wenn die Chips kommen.. sowas wie ein "Zusammenbau" sollte ja auch noch passieren... |
|
|
|
|
Ich kann da nur vom ZTEX ausgehend sprechen:
Ja, die Takten sich von einem Basiswert hoch bis die Fehlerrate etwa so viel ausmacht wie ein weiteres Megaherz. Dort liegt dann in etwa die maximale Geschwindigkeit. Da die, wie auch bei GPUs mit der Temperatur zusammenhängt und FPGAs keine Temperatur messen wird immer wieder getestet und getaktet..
|
|
|
|
|
Welch Überraschung, dass da eine Seifenblase geplatzt ist.
Mal sehen, wann die Schmetterlinge auch endlich verschwinden....
|
|
|
|
|
1) Hast du einen Pool gewählt
2) Hast du die richtigen Angaben für den Pool genutzt?
3) Standardfrage: Hast du die richtige GPU auf dem Computer?
|
|
|
|
You could try and merge some of the changes upstream, but honestly, I'm not sure I care about litecoin. Is there some massively compelling reason you want to support that?
Yes, because i intended the client to work with bitcoin and litecoin and virtually every other *coin that is available atm - but only worked out BTC and LTC so far Keep in mind that all of the altcoins have their own little wallet quirks that are going to require maintenance. Reciever files in DevCoin, Pay Per Share mining in PPCoin, tec. Thats why i just included BTC and LTC so far.. i would like to tackle NMC next, but dont have the time right now. |
|
|
|
You could try and merge some of the changes upstream, but honestly, I'm not sure I care about litecoin. Is there some massively compelling reason you want to support that?
Yes, because i intended the client to work with bitcoin and litecoin and virtually every other *coin that is available atm - but only worked out BTC and LTC so far |
|
|
|
That's really cool but it might not be a good idea to get too far from bitcoinj base. Otherwise you'll find it difficult to rebase on top of newer versions that have many bugfixes, performance improvements and other useful things.
Thats a problem i see myself. Primarily my idea was to have a wallet with bitcoinj as backend but this grew impossible when adding litecoin to it. But at the moment the changes are rather small - the analog to the prodNet() function there is a custNet() function that takes the config file as parameter and fills the network parameters from there. Also there are numerous smaller "fixes" to other functions to work with custNet() parameters and scrypt in general. |
|
|
|
|
ok, to be honest i dont see the difference at the moment - could you explain this to me? THe way i handled it so far was to reproduce the same "answers" the original client gave me. Also i was testing all this all the time through a PHP RPC class and for the moment the client works without problems as substitute for my original client on two php projects.
|
|
|
|
|
Current Version: 0.1.0 -development haltet but source available-
Description and Background:
SLICk is an attempt to create a lightweight wallet for VPS Users like me.
For me it was a big problem that Bitcoind was taking just too much memory and CPU for everyday use. Bitcoind also took way too much Harddisk space so i looked for alternatives and didnt find much.
The BitcoinJ Project was a nice start to create my own client. Using JPosse as example on how to use Servlets for RPC i began writing a small application to serve Virtualminer as bitcoind replacement. As some time went by and everything went just too smooth (even though using JAVA) i decided to add the capability of running a Litecoin Wallet to Bitcoinj/SLICk which ended up in modifing a lot of the base BitcoinJ code but also resulted in a small java application that can handle Bitcoin and Litecoin by just using different configuration files.
Configuration files:
Configurations can be split into two major areas: User and Chain
The part for the user lists the filenames of the wallet and blockchain file and how often the client should update. Also users can set a fixed fee and setup the RPC information.
The other part is the area which the normal user shouldnt touch. It basically lists all the network parameters of a blockchain like Genesis Hash, TargetTimespan and so on.
(Will add an example later)
RPC calls:
I have implemented a few RPC calls that are useful for websites. I dont plan on introducing GetWork and similar stuff into SLICk since it is not meant to be a replacement for bitcoind. Also i didnt add any Account features as they are in the original client. First of all because i created the client for people who use a db to track accounts anyway and because i dont like the built in account system.
Native RPC Calls:
getbalance
getnewaddress
getreceivedbyaddress("Address")
sendtoaddress("Address,Coins)
validateaddress("Address")
getblockcount()
getinfo()
getdifficulty()
getconnectioncount()
getblocknumber()
listtransactions()
settxfee (0.005)
sendmany ("Address",Coins,"Address",Coins...)
stop()
Custom RPC Calls:
I also created a few RPC calls that i thought to be useful at my own projects and therefore introduced them into this client as well.
getKeyPoolsize() -- Returns the number of keys in the wallet
savewallet() -- Triggers the saving of the wallet
ListPubKeys() -- Returns a list of all public Keys
SetMaxConnection(num) -- Changes the maximum amount of connections on the fly and saves it to the config file
TempMaxConnection(num) -- Changes the maximum amount of connections on the fly. Setting is lost after restart
EchoToCli("Some Message") -- Show some text on the command line
getConfidence(TransactionID) -- Returns the confirmations of a given Transaction ID
Changelog:
0.1.0
- Internal testing phase began.
Performance:
It takes about 3 hours to download the full Bitcoin blockchain at my home computer, less than an hour for Litecoin. This looks different for my VPS but its a very slow one when it comes to writing to disk...... Memory usage is ok: The Bitcoin client is running for a few days straight now and takes 100MB mem, the litecoin client roughly 95MB.. so both look good.
Download Links:
Source "As is": virtualminer.eu/SlickSrc.7z
I will update this once i find some time to keep developing it again...
how to run: copy the contents from btc.config or ltc.config (those work..) into slick.config and run the following command:
java -cp [youjarfile] com.windwallet.Main slick.config
|
|
|
|
|
Show Posts
