[RC5] OGR motivations/achievements in general
andy at edespot.com
Sun Oct 6 12:43:10 EDT 2002
I hate to think I'd be joining a flame war, but...
+++ Jack Beglinger [dnet] [Sat, Oct 05, 2002 at 12:58:48PM -0500]:
> The increasing the size of the blocks is because of their server issues. Not
> for the good of project. Maybe by using a little different methods you get
> a better system? We are a distributed system -- so may be distribute the
> work load.
I don't see how increasing the block size hurts anybody or anything, execpt
perhaps you. What special circumstances are you under where a larger block
size would be detrimental? Checkpointing takes care of 'unstable'
machines, you do the same amount of work whether it be lots of little
packets, or one large packet.
What problem are you solving exactly? Your solution, though it seem as it
would work, will add a fair about of complexity to the perproxys. But what
is the 'need' to do this?
> > You may want to remember dnet is a volunteer organization. If your
> ideas are
> > well suited to dnet, and logical, feasible, and reasonable, why not join up
> > and help implement them?
> Once the drop they NDA requirement.
You could donate code, if you have some working. I don't know if the dnet
team would reject it... Besides, when was the last job you had where there
was no NDA?
> I read even one. It been the same reply for two multiple years. Tech has
> changed, system have changed but DNET can't for the same reasons I get
> from local programmers that are entrenched with their past or sys admins
> who keep fixing the problem over and over but never fix the issue.
dnet has fixed the issue IMHO. They realized that how 'big' a block size
is changes over time. 2^24 was big when P120's and 68040's were cracking
RC5-64. Now they are 'tiny' on Athlon's and G4's.
Nothing is *broken*. The only issue is that bandwidth is being used at a
much larger rate. Larger block sizes clearly fix this. It also sounds
like code has been changed to keep fragmentation down such that block sizes
can grow more easily.
The thing I like about this solution is that the complexity is on the
server. Should there (and there probably will) be bugs, they will be fixed
in one spot rather than asking X amount of people who probably don't pay
all that close attention to either this list or the dnet web site to please
upgrade their software, as it has a bug.
Jack, your proposed solution seems to be a decent one, but just not as
feasible in the eyes of the dnet staff (or me) as their solution. As I see
it, the problem is less 'technical' than it is 'logistical'. How many
clients are still working on DES?
// Andrew MacKenzie | http://www.edespot.com
// Also, the Scots are said to have invented golf. Then they had
// to invent Scotch whiskey to take away the pain and frustration.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.distributed.net/pipermail/rc5/attachments/20021006/69a1e973/attachment-0001.bin
More information about the rc5