Ask asked us to stop ... but what the heck ;-). Perhaps we should drop the list after this one though.
On Thu, 2007-08-30 at 14:19 -0400, Matt Sergeant wrote: > On 30-Aug-07, at 10:57 AM, Guy Hulbert wrote: > > > Nope. I reject this. The design ASSUMES that the clock has > > "sufficient > > resolution". It is the implementation which chooses Time::HiRes. > > Fine, so on Alpha, you have a qpsmtpd installation that is using First, what I'm saying, is that I don't think we should be particularly worried about an almost obsolete platform. Also, I am quite happy with whatever you decide as long as it reflects the requirements that everyone has requested (which it seems to do). > async and doing more than 1000 mails/second? And given that it has > rand(10000) in there, you also need a rand() collision in that However. Nope. The problem with random number generators is that their output is *random*. That means that you will occasionally get results very close together and when you quantize it (e.g. rand(100000)) it means you will get the same number consecutively. This is exactly what you do not want when your problem is insufficiently resolved times. You'd be better off using a block-cipher (e.g. DES) which scatters results *uniformly*. But either case is a hack so rand() will do since it's available. Actually, I think the right answer is just a sequence generator (mod 10000). That guarantees different consecutive results. In python you could just use an iterator ... I'm not sure about perl. Have you read Knuth on random number generators ? It's quite amusing. > > millisecond. You're reaching for a problem. > On "normal" platforms the minimum granularity is on the order of 1 > billion mails/sec. Let me know when you're building the single CPU > system that can do that, I'd like to buy one. > > Note that mod_unique_id is only designed for 64k hits/sec. -- --gh
