d.net een beetje aan het uitsterven ?

[Ricoh]

Al tijden geen 32 sized packet gezien. En zelden èèn van 16.
Verrotte irritant werkt het met die kleine packets..
Je kunt geen grote buffers meer aanleggen voor je client..
bij een packetsize van max 8, is dat (500x8=4000)
Erg lastig als d'r een paar pc's vaak offline zijn.
Het resultaat is dat er meer randoms ontstaan, meer zeurende mensen om missende wu's.. etc
Bovendien is het ook erg lastig voor een proxy, helemaal als de proxy erg druk bezocht wordt, dat ding zit geen moment stil, en krijgt al snel last van backlog, of empty buffers

Wat zou de reden kunnen zijn dat die packets zo ontzettend schaars zijn ?

En waarom is d.net gestopt met het verbeteren cq optimaliseren van clients en proxy's ?
En ze hadden destijds toch ook een nieuw stats idee ?

Heeft iemand wat backdoor info?
Want het zelf aan d.net vragen, is vragen tot je een ons weegt Lijkt me stug dat ze het daar te druk voor hebben, want zo lijkt het namelijk niet

Dar was het voor deze keer...

Let wel: Dit mag niet de pret drukken, en dat doet het ook zeker niet

[squaddie]

Al tijden geen 32 sized packet gezien. En zelden èèn van 16. Verrotte irritant werkt het met die kleine packets.. Je kunt geen grote buffers meer aanleggen voor je client.. bij een packetsize van max 8, is dat (500x8=4000)
Erg lastig als d'r een paar pc's vaak offline zijn. Het resultaat is dat er meer randoms ontstaan, meer zeurende mensen om missende wu's.. etc. Bovendien is het ook erg lastig voor een proxy, helemaal als de proxy erg druk bezocht wordt, dat ding zit geen moment stil, en krijgt al snel last van backlog, of empty buffers

Ik denk dat ze een paar keyspaces hebben vrijgegeven voor recycling en met die meuk zitten we helaas opgescheept.

En waarom is d.net gestopt met het verbeteren cq optimaliseren van clients en proxy's ? En ze hadden destijds toch ook een nieuw stats idee ?

Ik vindt het zo-i-zo veeeel te bij D.net, vroeger toen ik startte met dit project (Hmmm klink weer verschikkelijk oud), een van de redenen was de "community" van D.net & DPC enz, maar nu is d.net alleen nog maar de naam van het project. (voor mijn gevoel), was er dagelijks nieuws op de D.net-site, maar nu je kan er een maand niet komen (uitgezonderd stats ) en dan mis je helemaal niets. Het lijkt er op dat sinds ze zijn samengegaan met UD, dat D.net de donor is geworden en langzaam leeg gehaald wordt.

Heeft iemand wat backdoor info? Want het zelf aan d.net vragen, is vragen tot je een ons weegt Lijkt me stug dat ze het daar te druk voor hebben, want zo lijkt het namelijk niet

Heb het idee dat je net zo goed tegen je monitor kan gaan lullen dat geeft het zelfde resultaat. Volgens mij is de enigste manier om nog contact met die lui te krijgen is een gigantische megaflush doen... Is bij nader inzien niet zo'n heel goed idee, geen stats meer voor DPC en dat kan mijn tere zieltje niet aan....

effe typos weggepoetst

[Verwijderd]

Ik heb verdorie hetzelfde probleem ...ben nu al 10 uur bezig om 200.000 blokkies op te halen voor een perproxy..een paar maanden geleden deed je easy binnen een uurtje..grumble..mijn koeien moeten grazen;)
Allemaal 1-6 grote packets.

[DSmarty]

Ook hier grote problemen met de kleine packetsizes.

Kon altijd keurig alle bakken op 1 buffer een week of meer laten draaien, nu check ik ze om de twee dagen en op mijn snellere bakken elke dag.
(dat zijn dus machines zonder internet-verbinding en zonder proxy).

[squaddie]

Ook mijn eigen proxy staat de hele avond te communiceren met een d.net server om genoeg packets binnen te halen om de enorm hongerige tbird 1200@1400 en de andere pcs van voldoende voer te voorzien.

Heb de config van enkele langzame pcs gewijzigd om de allerkleinste blokkies weg te houden van de tbird...

[Ricoh]

hmmz, tis dus een bekend probleem...

Zwaar irritant als je een halve dag over doet om 100k op te halen, en dat je als je die wil verslepen naar een andere locatie je nu 5 diskette's nodig hebt, ipv 1
(buffer wordt groter naarmate er meer packets in zitten, terwijl het unit aantal hetzelfde blijft)

[squaddie]

Het is super irri, als je tbird aan een 1 workunit gaat werken, je hebt ongeveer meer overhead dan werkelijke data/rekenkracht.

Helaas werkt het filter niet helemaal goed, aangezien de tbird veeeeeel harder gaat dan de rest van de pcs.

Hoef gelukkig het buffer niet te verplaatsen maar dat is het enigste. In de goede oude tijd kon je de isdn verbinding 15 min openzetten en dan kon je voor een maand vooruit nu heb je voor een uur werk. D.net zou aandelen KPN moeten kopen met alle telefoontikken die nu gegenereerd worden.

[Verwijderd]

De laatste tijd komen er weer grotere packets . Ik heb nou 400 packets en 8000 blocks eerst had ik 500 packets en 7500 blocks

[Mar]

Rico-burn:

* Mar heeft zelfde probleem, moet ook met 5 diksette's gaan klooien :(

[CBA]

Hmm de laatste dagen krijg ik weer mooie volledige pakketjes van 32

[Mobster]

Op vrijdag 12 oktober 2001 10:50 schreef CBA het volgende:
Hmm de laatste dagen krijg ik weer mooie volledige pakketjes van 32

Ik niet Fetch je van een public proxy of rechtstreeks bij dnet?
In dat geval: Dutchman, even verse buffer-in maken

[RobzQ]

Op vrijdag 12 oktober 2001 11:35 schreef Mobster het volgende:

[..]
In dat geval: Dutchman, even verse buffer-in maken

Dan krijg je dezelfde blokjes over een paar maanden nog een keer. Eens moeten ze toch berekend worden.

[Verwijderd]

misschien, als het kan, 2 clients naast elkaar zetten, die allebei een buffer ophalen, weet niet of je 2 naast elkaar kan draaien, dat scheelt je alweer iets.

en als je een buffer zipt(misschien heb je dat al gedaan??)??

thuis heb ik ook wel last van 500 packets= 1800 wu's, maar ik heb kabel, dus zo erg is het ook niet

[Mobster]

Op vrijdag 12 oktober 2001 12:00 schreef RobzQ het volgende:

[..]

Dan krijg je dezelfde blokjes over een paar maanden nog een keer. Eens moeten ze toch berekend worden.

De buffer-in van zijn proxy is relatief klein. De kans dat diezelfde blokjes weer bij hem terecht komen lijkt me vrij klein. Toch

[hessel|IA]

Kan het ook zijn dat we weer aan het begin van het volgende door dnetc beschikbaar gesteld blok(keyspace) zijn geraakt. Waar door random werkende clienten al grote gaten in zijn geslagen.(Random keys word nl. uit nog te berekenen keyspace gehaald)

[MM]

Op vrijdag 12 oktober 2001 14:04 schreef hessel het volgende:
Kan het ook zijn dat we weer aan het begin van het volgende door dnetc beschikbaar gesteld blok(keyspace) zijn geraakt. Waar door random werkende clienten al grote gaten in zijn geslagen.(Random keys word nl. uit nog te berekenen keyspace gehaald)

Ik dacht dat er speciaal een paar keyspaces zijn die opengesteld zijn voor random blocks, of heb ik het nou mis?

[Mobster]

Het blijft in ieder geval niet opschieten.

Net 2000 packets binnengehaald en iets meer als 5800wu's

[squaddie]

Hiero begint het een klein beetje beter te worden... ipv van alleen maar 1 t/m 4 nu ook heel af en toe een uitschieter naar de 20+ Of wel nog effe door grazen en het is op.