Re: avoiding expiry before creation (Re: Re: 1.03pr6 fix for getopt & recent bugs)

> (List is being rather slow, Cc'ing on this one and retaining full text
> of previous in thread below).

Yes, I noticed that and sent a note to the freelists.org admins.  You 
should get my patch through the list fairly shortly, though - I sent it 
ages ago.

> Another issue which came up recently is Thomas Boschloo pointed out a
> problem with very large stamps -- they could take so long to compute
> they are expired by the time they are produced.
>
> This would have to be non-email application given short-times, but eg
> as expiry is configurable and resolution of creation time, one could
> have eg second resolution creation time, and expires in 10 mins.

Interesting...  though I can't offhand think of an application that 
would require such a short expiry.  Let's discuss this more when the 
list gets back up to speed, as I think it's a future issue rather than 
a critical one for now.

> To do this we also need something like the "do max 2^32 tries and give
> me control back" kind of API like find_collision has.

This is already present at the minter core level (and is used by the 
new quickbench code), so a future API expansion to expose it to client 
applications would not be terribly difficult.

>> I call it with 100 tries; but may be you'd want a bit more as the new
>> minters are faster. eg 256 or parameterizable maybe.

I've done it so that if a particular size doesn't take long enough, it 
resyncs to the clock, doubles the count, and tries again.  That way we 
virtually eliminate function-call overhead from the benchmark.  "Long 
enough" is defined as a decent number of real clock ticks, so there's 
also a loop beforehand to discover how long a tick is.

All this still takes quite a short time, especially under Carbon/OSX 
which seems to have a clock() resolution of a microsecond!

>>> (Question: does the Cyrix 5x86 support CPUID?  If not, it would make 
>>> a
>>> suitable test platform for this.  So would my old 486, but it's 
>>> taking
>>> it's sweet time over installing Linux, so may not be ready for 
>>> several
>>> more days.)
>>
>> I had a amd 486dx120 somewhere gathering dust (3 x 40Mhz clock
>> multiplier) but I am not sure I will be able to make it work, it had
>> several IO cards fail and I ran out of IO cards to replace them with.
>> That was a sweet machine in it's time.

Wow - the fastest stock 486 I'd heard of before was the DX4/100 (3x33). 
  I could take the chip and put it in my IBM PS/1 chassis, though it 
would only run at 3x25 in that case, unless someone found a decent 486 
board to go with it.

Of course, if the actual board is in working order, I could just take 
that and use the I/O cards I have lying around already.  I've got a 
spare ATX case which should also take an AT board, and a spare AT PSU 
which seems to have got slightly too worn out to drive my Pentium-MMX 
reliably, but should be fine for a 486.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     [email protected]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.