DNet's explanation for the backlog

[Viztech]

Read it in Ivo's finger gateway.

That does explain some things, but I wonder just how many days it takes for a block to get 'old' enough to start causing this problem. I routinely have work out in the sneaker herd that is 2-3 or 4 weeks old before it gets returned.

viz

 

[kranky]

The way I read it, I'm not sure there is a connection between the "old" blocks, and what dnet is saying about the subspaces. I suspect that the 1 or 2 subspaces that are open (where the optimized processing occurs) is a smaller number of keys than what would be considered "old". If blocks old enough to be reissued=the optimized subspaces, then people would be noticing that they aren't getting credit for all the work they do (because some of the blocks they cracked were reissued, then flushed by someone else first), in which case I would presume people would start flushing more often instead of putting up with uncredited work.

So I'm guessing it's possible that blocks that aren't so old as to have been reissued could still be outside the open subspaces, causing performance problems when flushed. It sure sounds from dnet's description that a lot of people must hold onto blocks for a while.

 

[Choralone]

Thanks for the info Viz! At least d.net is giving us a better idea of what's going on instead of keeping us in the dark. I was a little worried when I saw their keyservers hadn't reported back in 3+ hours!

 

[Bleep]

I am leaving for Vegas for 8 days I guess this means that I will not leave my machines running if 5 out of 8 blocks are going to be rejected, sounds like a crock to me.
Bellp

 

[redwing]

Don't worry, all blocks cracked will be counted. Only when a lot of blocks from 'old' keyspaces are sent to d.net, ,the server get's more blocks than it can handle at that time, and will put them in hold. This creates a back-log. These blocks will be handled later, but it is possible that blocks sent on e.g. monday will be handled on friday. But they are counted, only a few days later ! So just leave your cows running !

 

[Kilowatt]

You know Dnet could help this situation out by making the pproxy's use FIFO logic.
The pproxys will not necessarily send out the older blocks it's holding, until the buffers are down to being empty.

People are using the pproxys to hold enough WUs to feed their herds incase there is an outage of some sort.
I'll almost bet there are many different subspace blocks still left laying around in some of the larger buffered pproxys.

Right now, the only way to insure that all the blocks are used up, is to only refill the pproxy after all the blocks are issued.
Then what happens if you can't connect to Dnet to get more?
Your herd starts doing randoms. NOT Good.

You would almost have to run 2 -3 different local pproxys, each buffering the same amount, and not refilling until the last block is gone.

Now, if they (Dnet) can make the client use FIFO, why can't they make the pproxy's use it also?
Moose, are you listening?

 

[Ken g6]

FIFO won't be the ideal algorithm. If, for example, a user is directly connected to the network and running an old block set, they will flush an old block regularly. Then the proxy will thrash between that old block and newer blocks. It gets worse the more people are doing this.

The best way I can see to do this is to make a tree of the block spaces currently in use, and connect a linked list to each node. Then, go through the spaces in FIFO, but don't look at new blocks being added back in the older spaces until you've done a complete pass.

Basically, then, you need to let blocks grow on trees! 😉 Then just go through from oldest to newest spaces, and pick the block "fruit". 🙂

Now that I think about it, a heap would be more efficient, and you could make a new heap with each pass. But I don't want to think of blocks growing in a heap like fungi. 😛