taai blokje - bug - winnend blokje tijd nodig ?

[Verwijderd]

Mij compu deed er vandaag ruim 3,5 uur over om 1 blokje te berekenen (ong. 425Kkeys/s)
Normaal gebeurt dit in een half uurtje.





Na het opnieuw opstarten deed zich de situatie voor zoals in het plaatje. Er kwam een R te staan. (na nu een keer gekeken te hebben is ie er over heen gegaan en is bij 40%.
Is dit een bug, een corrupt blokje of moet het winnende blokje gewoon lang berekend worden?
Tanks

[Ricoh]

nix verkeerds aan, 1 packet is bij jou waarschijnlijk 24 wu's dus dan doet ie daar simpelweg 3,5 uur over

[Verwijderd]

dat klopt,( zie ik ook nu) maar vanwaar die ommezwaai, voorheen duurde het maar een halfuurtje. Kunnen er opeens in een rc5 packet meer WU's zitten? En vanwaar die R?

[Verwijderd]

Het kan zijn dat je een grotere packet had, ik weet niet wat d.net ons tegenwoordig toestuurd...
En die "R" betekend Resume, is dus nix aan de hand, hij gaat daar gewoon verder

[redwing]

Ze waren nu toch bij distributed bezig om standaard grotere packets te sturen, aangezien dat voor hun een stuk minder data-verkeer betekend. Zolang de rate in kkeys/sec gelijk blijft is er niets aan de hand. Pas als deze omlaag gaat moet je eens goed zoeken waardoor dat komt. Voorheen kreeg je waarschijnlijk packets van 2 wu's (+/- 21 min), maar nu heb je er eentje van 32. Deze doet er bij 425 kkeys/sec ongeveer 5 1/2 uur over. Maar aangezien distributed de wu's telt maakt het niets uit hoe lang je PC over een packet doet.

[Verwijderd]

klopt waarschijnlijk helemaal, ik heb nu 3 packets met daarin 94 WU en de rate is hetzelfde.

[DaZZle]

kleine pakketjes zijn wel fijner, heb je het idee dat ie meer doet

Wat betreft OGR. Daarbij weet je pas je packetgrote achteraf. Dan zit hij 4 uur te herkouwen op de eerste 10% en de rest doet ie in een minuut of omgekeerd. Ik heb pakketten van 0.4GN tot 40GN gehad. Zit er nog een leuk verassingseffectje in.

I like OGR