* changed "random" patch for higher precision
@ 2006-04-30 4:00 George P Nychis
2006-05-02 4:35 ` Vincent
2006-05-02 13:56 ` Patrick McHardy
0 siblings, 2 replies; 4+ messages in thread
From: George P Nychis @ 2006-04-30 4:00 UTC (permalink / raw)
To: netfilter-devel
Hi,
I modified the "random" patch to support high precision averages ... the original random only supports 1-99% in integer intervals
The original patch did this by having an 8 bit integer, reading random bytes from the kernel into an 8 bit integer, and testing between 2 and 252 (1*2.55 and 99*2.55 ... 2.55 coming from 255/100).
Regardless of how the original patch worked, I use a 32 bit integer to support extremely high precision probabilities and changed the ranges to UINT_MAX instead of 255, plus other changes.
I tested it pretty rigurously on the 2.4 kernel because i'm working on a project right now which required high precision drop probabilities
My main question is, should i request changes to the random patch, or completely create a new patch and argument?
Thanks!
George
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: changed "random" patch for higher precision
2006-04-30 4:00 changed "random" patch for higher precision George P Nychis
@ 2006-05-02 4:35 ` Vincent
2006-05-02 13:56 ` Patrick McHardy
1 sibling, 0 replies; 4+ messages in thread
From: Vincent @ 2006-05-02 4:35 UTC (permalink / raw)
To: 'George P Nychis', netfilter-devel
Can you post the patch to the mail-list ?
Vincent
>-----Original Message-----
>From: netfilter-devel-bounces@lists.netfilter.org
>[mailto:netfilter-devel-bounces@lists.netfilter.org] On Behalf
>Of George P Nychis
>Sent: Sunday, April 30, 2006 12:01 PM
>To: netfilter-devel@lists.netfilter.org
>Subject: changed "random" patch for higher precision
>
>
>Hi,
>
>I modified the "random" patch to support high precision
>averages ... the original random only supports 1-99% in
>integer intervals
>
>The original patch did this by having an 8 bit integer,
>reading random bytes from the kernel into an 8 bit integer,
>and testing between 2 and 252 (1*2.55 and 99*2.55 ... 2.55
>coming from 255/100).
>
>Regardless of how the original patch worked, I use a 32 bit
>integer to support extremely high precision probabilities and
>changed the ranges to UINT_MAX instead of 255, plus other changes.
>
>I tested it pretty rigurously on the 2.4 kernel because i'm
>working on a project right now which required high precision
>drop probabilities
>
>My main question is, should i request changes to the random
>patch, or completely create a new patch and argument?
>
>Thanks!
>George
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: changed "random" patch for higher precision
2006-04-30 4:00 changed "random" patch for higher precision George P Nychis
2006-05-02 4:35 ` Vincent
@ 2006-05-02 13:56 ` Patrick McHardy
2006-05-02 16:05 ` changed 'random' " George P Nychis
1 sibling, 1 reply; 4+ messages in thread
From: Patrick McHardy @ 2006-05-02 13:56 UTC (permalink / raw)
To: George P Nychis; +Cc: netfilter-devel
George P Nychis wrote:
> Hi,
>
> I modified the "random" patch to support high precision averages ... the original random only supports 1-99% in integer intervals
>
> The original patch did this by having an 8 bit integer, reading random bytes from the kernel into an 8 bit integer, and testing between 2 and 252 (1*2.55 and 99*2.55 ... 2.55 coming from 255/100).
>
> Regardless of how the original patch worked, I use a 32 bit integer to support extremely high precision probabilities and changed the ranges to UINT_MAX instead of 255, plus other changes.
>
> I tested it pretty rigurously on the 2.4 kernel because i'm working on a project right now which required high precision drop probabilities
>
> My main question is, should i request changes to the random patch, or completely create a new patch and argument?
I already have a version of random with higher precision queued
for 2.6.18. You say you're using UINT_MAX .. can you represent a
probability of both 0 and 1? :)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: changed 'random' patch for higher precision
2006-05-02 13:56 ` Patrick McHardy
@ 2006-05-02 16:05 ` George P Nychis
0 siblings, 0 replies; 4+ messages in thread
From: George P Nychis @ 2006-05-02 16:05 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel
> George P Nychis wrote:
>> Hi,
>>
>> I modified the "random" patch to support high precision averages ...
>> the original random only supports 1-99% in integer intervals
>>
>> The original patch did this by having an 8 bit integer, reading random
>> bytes from the kernel into an 8 bit integer, and testing between 2 and
>> 252 (1*2.55 and 99*2.55 ... 2.55 coming from 255/100).
>>
>> Regardless of how the original patch worked, I use a 32 bit integer to
>> support extremely high precision probabilities and changed the ranges
>> to UINT_MAX instead of 255, plus other changes.
>>
>> I tested it pretty rigurously on the 2.4 kernel because i'm working on
>> a project right now which required high precision drop probabilities
>>
>> My main question is, should i request changes to the random patch, or
>> completely create a new patch and argument?
>
> I already have a version of random with higher precision queued for
> 2.6.18. You say you're using UINT_MAX .. can you represent a probability
> of both 0 and 1? :)
>
>
>
Hey Patrick,
Well then this is perfect, because my implementation is for 2.4.32 ... i didn't touch the 2.6 stuff since my project is based on 2.4 kernel.
I can represent a probability of both 0 and 1, as soon as I finish up some work for the day, i'll send out my changes and patch and explain everything
- George
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-05-02 16:05 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-30 4:00 changed "random" patch for higher precision George P Nychis
2006-05-02 4:35 ` Vincent
2006-05-02 13:56 ` Patrick McHardy
2006-05-02 16:05 ` changed 'random' " George P Nychis
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.