[RC5-72] Bandbreedte gebruik/grootte van een workunit?

Pagina: 1
Acties:

  • DieterVDW
  • Registratie: Juli 2002
  • Laatst online: 12-02-2017
Ik ben nu al een tijdje aan het zoeken, maar nergens vind ik concrete informatie omtrent het bandbreedte gebruik van de RC5-72 client.
Of omtrent de exacte grootte van een workunit.
Ik weet dat het in ieder geval niet veel is, maar kan er mij soms iemand concrete informatie geven?

Tnx!

  • YakuzA
  • Registratie: Maart 2001
  • Niet online

YakuzA

Wat denk je nou zelluf hey :X

50 WU's = 8,62 KB

hier in buffer :)

Death smiles at us all, all a man can do is smile back.
PSN


Verwijderd

1 Block = 172 bytes

Op dit moment is een block ook 1 WU, maar over een tijdje komen er grotere blocks die dan 2 of meer WU's bevatten. Desondanks blijft de grootte van een block 172 bytes.

Kwa netwerkverkeer durf ik het niet 100% te garanderen, maar voor ieder block wordt een acknowledge teruggestuurd. Stel dat die even groot is als het block zelf, dan is het 344 bytes dataverkeer voor het ophalen van het block, en weer 344 bytes voor het inleveren. Totaal dus 688 bytes per block (worst case).

Daarnaast zijn zowel de client als de proxy zo ontworpen dat ze niet je hele verbinding direct platgooien, dus als je het zo instelt dat je buffers altijd bijgewerkt worden op het moment dat je tóch al online bent, dan merk je er niets van.

[ Voor 22% gewijzigd door Verwijderd op 05-01-2004 07:02 ]


  • Mizitras
  • Registratie: September 2002
  • Niet online
500 blokjes, nog geen 25KB :D

Nieuwe 'types' blokjes Floppus? Gaat pc daar langer over doen om over deze 'nieuwe' blokjes?
(Ik zou mijn 'input' dagelijks niet met nog is x achteruit willen zien gaan omdat ze nu enkel wat zwaarder worden)

PS: Ook getest op een Pentium4 2,533Ghz 3,5mio/sec, dat normaal ? Vind nogal weinig. (NIet vergeleken met AMD, ik weet dat dat dan zeker bijna 2+ zo hoog ligt op gelijke klok)

"the fucking alpha cpp compiler seems to fuck up the goddam type "LPITEMIDLIST", so to work around the fucking peice of shit compiler we pass the last param as an void *instead of a LPITEMIDLIST"


  • NightBird
  • Registratie: Januari 2000
  • Laatst online: 10:29

NightBird

DPC-Crew Coding
Verwijderd schreef op 05 januari 2004 @ 07:00:
1 Block = 172 bytes

Op dit moment is een block ook 1 WU, maar over een tijdje komen er grotere blocks die dan 2 of meer WU's bevatten. Desondanks blijft de grootte van een block 172 bytes.

Kwa netwerkverkeer durf ik het niet 100% te garanderen, maar voor ieder block wordt een acknowledge teruggestuurd. Stel dat die even groot is als het block zelf, dan is het 344 bytes dataverkeer voor het ophalen van het block, en weer 344 bytes voor het inleveren. Totaal dus 688 bytes per block (worst case).

Daarnaast zijn zowel de client als de proxy zo ontworpen dat ze niet je hele verbinding direct platgooien, dus als je het zo instelt dat je buffers altijd bijgewerkt worden op het moment dat je tóch al online bent, dan merk je er niets van.
Je bedoelt packets. Blocks == workunits == statsunits. Nu bestaan packets uit 1 block/wu, maar in de toekomst komen er waarschijnlijk packets met meerdere wu's. Die doen er dan natuurlijk wel langer over, maar je krijgt er ook evenredig meer punten voor (want die gaan per wu). Dus een packet met 4 wu's/blocks duurt 4x zolang als een packet met 1 wu en levert dus ook 4 punten in de statistieken.

WatHoorJeWaar · Asobakken
Eerdere projecten: Leading Courses · Brandstof-zoeker.nl · Voertuig-zoeker.nl


Verwijderd

De benamingen lopen inderdaad wat door elkaar, maar het wordt beschreven in de proxy-manual zoals jij het zegt idd.

Bij dnet zelf hadden ze het over "naar een grotere blocksize" gaan; mogelijk wordt dit ook anders gezien sinds ze over zijn gestapt op het bijhouden van de hoeveelheid keys in de database, in plaats van de hoeveelheid WU's
Pagina: 1