D-net wil grotere packets forceren...

[blimmel]

http://n0cgi.distributed.net/cgi/dnet-finger.cgi?user=bovine

[Onno]

Lijkt me een prima plan.

If your machine completes a 2^28 sized block in less than 45 minutes, than your computer is fast enough that it really should be processing larger blocks.

Dat is dus eigenlijk elke (pentium-class) pc.
(is maar 99kkeys/s voor nodig)

[Vleermuis]

Is een goed iets:

De bestandsgrootte van een packet met 1 blokje (2^28 keys) is volgens mij nauwelijks kleiner dan een packet met 32 blokjes (2^33 keys), tenminste, hier bij mij is een packet van 32 blokjes net zo snel weggestuurd dan een packet met 1 blokje.

/me heeft hier 2^30 als instelling staan: 10 minuten voor 4 blokjes.

[Mobster]

OK. Ik heb nu dit gedaan.

10) Preferred packet size (2^X keys/packet) ==> RC5=31,DES=-1,CSC=-1

Is dit een beetje ok? Ik heb dnetc v2.8007-458-CTR-00021307 for Win32 (Windows 4.10).

[Anoniem: 4629]

Wel GVD!

Daarom krijg ik elke keer grotere packets.

Ik wil die GVD helemaal niet! Mijn bak is zo onstabiel dat ik die grotere packets helemaal nooit afkrijg.

Met packets van 1 blokje lukt het af en toe tenminste nog ..

[blimmel]

bij mij thuis heb ik 'm op 4x2^28 staan...
mijn compu crashed nog wel eens... (ben er nog niet achter waarom )

en hier op 't werk draait een Quadra 700 die bijna 7 dagen over 32wu's doet!
1x2^28 is dan toch fijner...

[Anoniem: 4629]

The ability to request small blocks should really be reserved for unstable,
slower machines that might have greater potential of crashing before
completing an entire packet. Additionally, those slower machines should
definitely consider enabling checkpointing, to allow blocks that are lost
in the middle of processing to be resumed. Note that clients that use
network shared ini's and buffers need to use distinct checkpoint files,
so you should use caution if you administer machines in that manner.

Dat is dus precies wat ik heb. Maar daar heb ik GVD wat aan als ik ze geforceerd toegestuurd krijg!

[DSmarty]

Grotere packets hebben IMHO alleen maar voordelen, ze zijn kleiner, sneller te fetchen/flushen en het kraken gaat ook ietsjes harder.
Mijn packetsize: rc5=33

[Anoniem: 4681]

Hummmmmmmm, ik heb sinds gisteren mijn packetsize naar rc5=33 gezet, en voor mij maakt het niet uit, pc thuis en op mijn werk chrashen gewoon niet!

Mo-Bees voor team GRAASLAND

[IceStorm]

Ik heb mijn koetje gewoon lekker op de standaard staan... meeste pakketjes zijn dus 4 wus... soms 3, 2 of 1 wu. Ach zolang het grootste standaard pakketje voor mij binnen 1 uur te kraken is ben ik tevreden...
33 is me iets te groot eigenlijk

[ragger78]

als je last hebt van instabiele computers, dan moet je in de client even een checkpoint file aangeven.
Daar slaat hij tussenstanden in op, zodat ie na een crash weer verder gaat waar hij ongeveer gebleven was.
Exacte plaats in config weet ik zo niet, heet iets van 'checkpoint-filename' ofzo

[Floor-is]

Bjorge: Dat zei HLPDSK ook al, maar even voor de duidelijkheid:

Onder buffer en buffer update options (#2)
Checkpoint filename (#4).
De filename mag je helemaal zelf kiezen ook de extensie. (Bijvoorbeeld: ik.rc5)

Nog meer vragen?

[Crack]

Bij mij staat de grootte op 32, maar ik grijg packages van 1*2^28 tot 7*2^28.
Het is wel zo, dat get flushen van een grote package even veel tijd in beslag neemt als een kleine.
Ook is de input-buffer kleiner (minder RC-pakketjes) en dat komt goed uit, aangezien ik op m'n werk achter een onbekende proxy zit. Ik mail de pakketjes nu van en naar m'n huis. 500 RC5-pakktjes per keer is ca. 6500 wu's.

[DSmarty]

Ik gebruik over als packetsize instelling: RC5=33

500 packets is voor mij 16000 WU's

[StarLite]

Als ze bij de nieuwste client nou STANDAARD de packet size op 33 zetten, kunnen oude pc's 'm weer op 28 zetten.
Aangzien 95% [of meer] van de mensen toch nooit naar die optie kijkt...

[Anoniem: 5896]

Hoe zit het eigenlijk met clients die de packets van een perproxy krijgen?

Moet dan de perproxy op 33 worden ingesteld of de clients,.... of allebij???