Hi,
this is the reading result with 64k blocks after rebooting:
# dd if=myfile of=/dev/null bs=64k
5636+0 records in
5636+0 records out
369360896 bytes transferred in 57.104 secs (6468214 bytes/sec)
The volume is RAID-1. I wonder why the NetBSD driver is not in sync
with the FreeBSD one as
On Mon, Nov 29, 2010 at 09:31:37AM +, Sad Clouds wrote:
Joerg I was specifically talking about particular sequences of numbers that
result in high collision rates, not random numbers. For example, if you take
the following:
4, 8, 12, 16, 20 ...
Every integer is a multiple of 4.
On Mon, Nov 29, 2010 at 09:31:37AM +, Sad Clouds wrote:
Joerg I was specifically talking about particular sequences of numbers
that result in high collision rates, not random numbers. For example,
if you take the following:
4, 8, 12, 16, 20 ...
Every integer is a multiple of 4. Can
On Mon, Nov 29, 2010 at 10:44:11AM +, Sad Clouds wrote:
As for calculating the hash, modern hardware has fast modulo
instructions. A very simple test on Intel Atom D510 processor, seems
to indicate a single 'interger % prime' is roughly equal to two
integer operations.
No, divisions and
On Mon, Nov 29, 2010 at 09:05:16AM +0100, Stephan wrote:
Hi,
this is the reading result with 64k blocks after rebooting:
# dd if=myfile of=/dev/null bs=64k
5636+0 records in
5636+0 records out
369360896 bytes transferred in 57.104 secs (6468214 bytes/sec)
The volume is RAID-1. I
On Mon, 29 Nov 2010 13:32:27 +0100
Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Mon, Nov 29, 2010 at 09:31:37AM +, Sad Clouds wrote:
Joerg I was specifically talking about particular sequences of numbers
that result in high collision rates, not random numbers. For example,
if
On Mon, Nov 29, 2010 at 01:12:47PM +, Sad Clouds wrote:
I've tried many different hash functions and from my experiments,
for hashing integers, it's very hard to beat 'number % prime'. There
is no magic number that you need to derive for every different set of
integers, it just works for
On Mon, 29 Nov 2010 13:41:38 +0100
Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Mon, Nov 29, 2010 at 10:44:11AM +, Sad Clouds wrote:
As for calculating the hash, modern hardware has fast modulo
instructions. A very simple test on Intel Atom D510 processor, seems
to indicate a
[...] but as I understand it, the [NFS] server implements its own
limits, not the client, which is as it should be.
The server should enforce limits if it is configured to have them, yes.
But the only reason I can see why the client shouldn't also be able to
put quotas on an NFS-mounted
On Mon, Nov 29, 2010 at 11:12:21AM -0500, der Mouse wrote:
If the keys are controlled by a third party, it is very easy to
degrade the performance to a linear list.
Sure, but that's not a useful remark. It's equally true of (n*K)32,
or for that matter any other easily invertible hash
On Mon, Nov 29, 2010 at 10:44:11AM +, Sad Clouds wrote:
If you are hashing integer values, you can tune the hash table so that every
bucket will have no more than 1 entry. Usually you simply make hash table
size a prime number.
I very much doubt that is possible in the general case.
Of
da...@l8s.co.uk said:
Integer divide (effectively) need a compare/subtract loop
Getting off-topic, but one can do a division by a table lookup for
an approximation of 1/divisor and about two iteration steps. Seen
that in some DSP where there was even a hardware asm instruction
for the initial
12 matches
Mail list logo
